Improve DAT: Random namespace to avoid namespace collision. #29652
Conversation
|
/legacy-test connector=destination-snowflake |
|
looks like the slash command isn't working so I manually kicked off a run which passed: https://github.com/airbytehq/airbyte/actions/runs/5920524608 |
| @@ -1805,7 +1805,8 @@ public Stream<? extends Arguments> provideArguments(final ExtensionContext conte | |||
| .filter(testCase -> testCase.get("enabled").asBoolean()) | |||
| .map(testCase -> Arguments.of( | |||
| testCase.get("id").asText(), | |||
| testCase.get("namespace").asText(), | |||
| // Randomise namespace to avoid collisions between tests. | |||
| Strings.addRandomSuffix(testCase.get("namespace").asText(), "", 5), | |||
There was a problem hiding this comment.
Will this leave any randomly names schemas or tables in the database at the end of the test? I don't think so...
There was a problem hiding this comment.
Good question - I actually think we already do so today.. it doesn't look like the Redshift Acceptance Test cleans up after itself for this particular case.
There was a problem hiding this comment.
Looks like Snowflake and Redshift are set up to erase entries in the TEST_SCHEMA.
There was a problem hiding this comment.
Ah looks like you added this: https://github.com/airbytehq/airbyte/pull/29312/files
|
I'm kicking off one more test before merging in: https://github.com/airbytehq/airbyte/actions/runs/5932710869 |
|
Test passed! Merging! |
…q#29652) By writing to the same namespace, multiple tests running at the same time for a single destination can cause overwrites and incorrectly failed tests. Minimise test flakiness by randomising the namespace in the TestNamespace test case. Co-authored-by: davinchia <[email protected]>
What
Minimise test flakiness by randomising the namespace in the TestNamespace test case.
How
By writing to the same namespace, multiple tests running at the same time for a single destination can cause overwrites and incorrectly failed tests.
Recommended reading order
The one class.
🚨 User Impact 🚨
Are there any breaking changes? What is the end result perceived by the user?
For connector PRs, use this section to explain which type of semantic versioning bump occurs as a result of the changes. Refer to our Semantic Versioning for Connectors guidelines for more information. Breaking changes to connectors must be documented by an Airbyte engineer (PR author, or reviewer for community PRs) by using the Breaking Change Release Playbook.
If there are breaking changes, please merge this PR with the 🚨🚨 emoji so changelog authors can further highlight this if needed.
Pre-merge Actions
Expand the relevant checklist and delete the others.
New Connector
Community member or Airbyter
./gradlew :airbyte-integrations:connectors:<name>:integrationTest.0.0.1Dockerfilehas version0.0.1README.mdbootstrap.md. See description and examplesdocs/integrations/<source or destination>/<name>.mdincluding changelog with an entry for the initial version. See changelog exampledocs/integrations/README.mdAirbyter
If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.
Updating a connector
Community member or Airbyter
Airbyter
If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.
Connector Generator
-scaffoldin their name) have been updated with the latest scaffold by running./gradlew :airbyte-integrations:connector-templates:generator:testScaffoldTemplatesthen checking in your changes