settings.gradleto separate them. This is not a best practice. Ultimately, we want these two builds to be totally separate. We do not know what that will look like yet.
:testtask). It does not include integration tests (anything called in the
format. It is not called as part of
build. If the command is called on a subset of the project, it will (mostly) target just the included modules. The exception is that
spotless(a gradle formatter) will always format any file types that it is configured to manage regardless of which sub build is run.
spotlessis relatively fast, so this should not be too much of an annoyance. It can lead to formatting changes in unexpected parts of the code base.
:testtask on any submodule. These test class-level behavior. They should avoid using external resources (e.g. calling staging services or pulling resources from the internet). We do allow these tests to spin up local resources (usually in docker containers). For example, we use test containers frequently to spin up test postgres databases.
SUB_BUILD=PLATFORM ./gradlew :airbyte-tests:acceptanceTests. These tests expect to find a local version of Airbyte running. For testing the docker version start Airbyte locally. For an example, see the script that is used by the CI. For Kubernetes, see the script that is used by the CI.
SUB_BUILD=PLATFORM ./gradlew :airbyte-tests:automaticMigrationAcceptanceTest --scan. These tests do not expect there to be a separate deployment of Airbyte running.
SUB_BUILD=PLATFORM ./gradlew --no-daemon :airbyte-webapp-e2e-tests:e2etest. Like the Platform Acceptance Tests, they expect Airbyte to be running locally. See the script that is used by the CI.
./gradlew :airbyte-integrations:connectors:<name>:buildRun integration tests: