It's difficult today to parse all the logs from tests. Engineers waste time scrolling through the log outputs and looking for the relevant stack trace.
This PR adds an action to generate a JUnit report so devs can understand test results at a glance. This generates 3 reports for each of the main build jobs when the build completes. We leave the frontend build out since this is aggregated by cypress.
See https://github.com/airbytehq/airbyte/pull/15271/checks?check_run_id=7683783016 for an example of how this works.
Use the https://github.com/dorny/test-reporter action and configure this to look at the Jacoco test report output for top level and second level builds. Note that most of the parameters into the action don't work.
Comment out the trap commands to output logs. Though this can be useful for debugging, there is little practical use in the day-to-day, and results in extremely noisy logs.
* set per stream feature flag to true for testing
* add a second table to cdc acceptance tests
* add partial reset test
* format
* add partial reset cdc tests
* test incremental after partial reset
* remove dev image from acceptance test
* fix flag and add comment
* Revert "set per stream feature flag to true for testing"
This reverts commit 164d7da05990268b09e315eb88ff297d3a9f52f4.
* set USE_STREAM_CAPABLE_STATE flag to true in acceptance test script
* call new update endpoint
* use methods in test harness instead
* remove comment
* format
* fix state check in basic acceptance test
* use test info for test name logging
* kill containers using volumes on shutdown in acceptance test scripts
* apply change to octavia integration tests as well
* escape inner command to make it be executed at the right time
- Add the CONFIGS_DATABASE_MINIMUM_FLYWAY_MIGRATION_VERSION and JOBS_DATABASE_MINIMUM_FLYWAY_MIGRATION_VERSION. These are env vars that will determine if the database is ready for an application to start.
- Add the CONFIGS_DATABASE_INITIALIZATION_TIMEOUT_MS and the JOBS_DATABASE_INITIALIZATION_TIMEOUT_MS env vars to determine how long an application should wait for the DB before giving up.
- Create the MinimumFlywayMigrationVersionCheck class. This class contains all the assertions to check if 1) a database is initialised. 2) a database meets the minimum migration version.
- Remove all set up operations from the ServerApp. Use MinimumFlywayMigrationVersionCheck operations instead.
- I also had to modify the Databases and BaseDatabaseInstance classes to support connecting to a database with timeouts. We would previously try forever.
- Add Bootloader to the relevant docker files and Kube files.
- Clean up the migration acceptance tests so it's clear what is happening.
* Refactor jobs and configs database initialization
* Add unit tests
* Format code
* Refactor code
* Update document
* Fix tests
* Add back init script to create db and user permission
* Remove old schema files
* Dry database instance implementations
* Revert unnecessary changes
* Rename resource directories
* Format code
* Add readme
* Move and rename database schema to jobs database schema
* Introduce table schema interface
* Rearrange packages
* Format code
* Address review comments
* Show more logs for acceptance test
* Do not depend on service uuid for db readiness
