Development on GCP Connectors for Apache Flink

Testing

Mon, 01 Jan 0001 00:00:00 +0000

Testing#

The suites fall into three kinds, split by what they need to run: nothing beyond Docker, real Google Cloud credentials, or wall clock. just verify runs the first kind and excludes the other two, so an ordinary build is credential-free and its duration is bounded.

Unit and integration tests#

Name a unit test *Test and an integration test *ITCase. The build selects by the first suffix alone: a class ending in Test runs in the unit execution, and every other test class lands in the integration execution — an unconventional name does not escape the build, it runs in the wrong lane. Both kinds run in just verify. The integration tests talk to Docker-backed service emulators, so Docker must be running, but no Google Cloud project is touched. An emulator is a convenience rather than an authority: the deviations that have been measured are recorded on the connector pages, and the real service is exercised by the gated suites below.

Checks

Mon, 01 Jan 0001 00:00:00 +0000

Checks#

Beyond the Maven build, CI runs a suite of repository-specific checkers — scripts under scripts/ (mostly Python, some shell), most behind a just check-* recipe. Several are deliberately two-way: they hold the documentation to the source and the source to the documentation, so an option that loses its table row fails the same check as a table row that loses its option. A contributor meeting one for the first time should know that its failure message names the repair, and that it is cheaper to run the relevant checker locally than to discover it on the pull request.

Contributing

Mon, 01 Jan 0001 00:00:00 +0000

Contributing#

Contributions are welcome, and they start with an issue rather than a pull request — the same consensus-first shape as Apache Flink’s contribution process. Agreeing on the problem and the approach before code exists is what keeps a pull request reviewable and keeps effort from being spent on a change that would not be accepted.

Before writing code#

Open an issue describing the problem or the proposal, or comment on an existing one, and reach agreement on the approach there. For a typo-level fix a pull request alone is fine; for anything that changes behavior, a public API, or a settled design, the discussion comes first.