## What
Currently the connector image publishing flow use project name/connector
directory to construct the repo name in dockerhub and ignoring the repo
defined in metadata.yml file. It creates inconsistency between
publishing the pulling image flow. This PR is to fix the issue
## How
<!--
* Describe how code changes achieve the solution.
-->
## Review guide
<!--
1. `x.py`
2. `y.py`
-->
## User Impact
<!--
* What is the end result perceived by the user?
* If there are negative side effects, please list them.
-->
## Can this PR be safely reverted and rolled back?
<!--
* If unsure, leave it blank.
-->
- [ ] YES 💚
- [ ] NO ❌
## What
Correctly ignore previous failed test attempts if we eventually
succeeded. See e.g.
https://github.com/airbytehq/airbyte/runs/52648135211 for an example
incorrect failure - the test ran twice and succeeded on the second
attempt, but the overall PR check was still marked as failed.
## How
Enable the flag to tell gradle to do a smarter thing.
## Can this PR be safely reverted and rolled back?
<!--
* If unsure, leave it blank.
-->
- [x] YES 💚
- [ ] NO ❌
- the bulk connector plugin hardcodes integration tests set up today instead of inheriting the same properties from the general test set up. Remove this.
- the Dest MSSQL uses a custom network to spin up test containers that is no longer required since we are no longer in Dagger. Remove this. This also simplifies things.
Introduce the airbyte gradle docker plugin to build JVM connectors.
Add logic to allow us to slowly migrate from one build set up to the other.
The majority of the work is taking in the metadata.yaml file, and converting that to buildArgs to be injected into the airbyte gradle docker plugin.
In particular, we extract the base image from the metadata file. We also add the connector name by referencing the module. This outputs a file buildArgs.properties into the build folder. This is done by the DockerGenerateConnectorBuildArgs task.
The AirbyteDockerConventionPlugin then takes in the generated buildArgs.properties file and feeds it into the Platform Docker plugin. It also feeds in the top-level Dockerfile, so the Docker plugin can copy it into the build folder.
I tried to migrate this to Kotlin, however the repo needs to be upgraded to the same Kotlin and KSP version as the gradle plugin repos for this to be worth while. Otherwise we end up writing kotlin plugins with reflection, which is worse than the current groovy plugins.
these tasks were only checking within the cdk directory, so they didn't actually accomplish anything. Fix them to walk the entire tree.
... afaict we don't actually use these tasks for anything, but might as well make them work?
