Get default configured catalog from discover command

[augan-rymkhan]

What

By default SAT should take configured catalog from discovery command and use the default configuration.

How

1. if configured_catalog_path is not provided then generate ConfiguredAirbyteCatalog from discovered_catalog fixture (result of discover command) in configured_catalog_fixture.

2. Remove default value from configured_catalog_path in config.py

Recommended reading order

1. x.java
2. y.python

🚨 User Impact 🚨

Are there any breaking changes? If yes, please make sure to include it here and in any changelogs with the 🚨🚨 emoji
What is the end result perceived by the user?

Pre-merge Checklist

Expand the relevant checklist and delete the others.

New Connector

Community member or Airbyter

• Community member? Grant edit access to maintainers (instructions)
• Secrets in the connector's spec are annotated with airbyte_secret
• Unit & integration tests added and passing. Community members, please provide proof of success locally e.g: screenshot or copy-paste unit, integration, and acceptance test output. To run acceptance tests for a Python connector, follow instructions in the README. For java connectors run ./gradlew :airbyte-integrations:connectors:<name>:integrationTest.
• Code reviews completed
• Documentation updated
  • Connector's README.md
  • Connector's bootstrap.md. See description and examples
  • docs/SUMMARY.md
  • docs/integrations/<source or destination>/<name>.md including changelog. See changelog example
  • docs/integrations/README.md
  • airbyte-integrations/builds.md
• PR name follows PR naming conventions

Airbyter

If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.

• Create a non-forked branch based on this PR and test the below items on it
• Build is successful
• Credentials added to Github CI. Instructions.
• /test connector=connectors/<name> command is passing.
• New Connector version released on Dockerhub by running the /publish command described here
• After the connector is published, connector added to connector index as described here
• Seed specs have been re-generated by building the platform and committing the changes to the seed spec files, as described here

Updating a connector

Community member or Airbyter

• Grant edit access to maintainers (instructions)
• Secrets in the connector's spec are annotated with airbyte_secret
• Unit & integration tests added and passing. Community members, please provide proof of success locally e.g: screenshot or copy-paste unit, integration, and acceptance test output. To run acceptance tests for a Python connector, follow instructions in the README. For java connectors run ./gradlew :airbyte-integrations:connectors:<name>:integrationTest.
• Code reviews completed
• Documentation updated
  • Connector's README.md
  • Connector's bootstrap.md. See description and examples
  • Changelog updated in docs/integrations/<source or destination>/<name>.md including changelog. See changelog example
• PR name follows PR naming conventions

Airbyter

If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.

• Create a non-forked branch based on this PR and test the below items on it
• Build is successful
• Credentials added to Github CI. Instructions.
• /test connector=connectors/<name> command is passing.
• New Connector version released on Dockerhub by running the /publish command described here
• After the new connector version is published, connector version bumped in the seed directory as described here
• Seed specs have been re-generated by building the platform and committing the changes to the seed spec files, as described here

Connector Generator

• Issue acceptance criteria met
• PR name follows PR naming conventions
• If adding a new generator, add it to the list of scaffold modules being tested
• The generator test modules (all connectors with -scaffold in their name) have been updated with the latest scaffold by running ./gradlew :airbyte-integrations:connector-templates:generator:testScaffoldTemplates then checking in your changes
• Documentation which references the generator is updated as needed.

[sherifnada]

One thing i'm not sure about: do we currently require the developer to opt out explicitly of syncing some streams?

for example if there are streams A and B and the user provides a configured catalog containing only A, does the test fail? IMO it should unless the user explicitly configured an option saying that they are skipping the stream, as well as providing a reason

[augan-rymkhan]

One thing i'm not sure about: do we currently require the developer to opt out explicitly of syncing some streams?

for example if there are streams A and B and the user provides a configured catalog containing only A, does the test fail? IMO it should unless the user explicitly configured an option saying that they are skipping the stream, as well as providing a reason

One thing i'm not sure about: do we currently require the developer to opt out explicitly of syncing some streams?

for example if there are streams A and B and the user provides a configured catalog containing only A, does the test fail? IMO it should unless the user explicitly configured an option saying that they are skipping the stream, as well as providing a reason

@sherifnada No, it will not fail, in that case.
The code change in this PR implements the following, If configured_catalog_path is not provided in acceptance-test-config.yaml then SAT takes configured catalog from discover command's result.

As I understand, your requirements are

• All streams must be in the file specified by configured_catalog_path, to test all the existing streams?

• If developer wants to skip tests for some streams, those streams must be marked explicitly as skipped with the reason

  Correct?

[sherifnada]

Correct. The idea is that this test should verify data is coming from all streams except if the developer explicitly opts out.

[augan-rymkhan]

@sherifnada
Discussed it with the team on standup call.
I created a new ticket for that. If it's ok can we merge this PR?

[sherifnada]

separate issue for the comment is good w me 👍🏼

[augan-rymkhan]

/publish connector=bases/source-acceptance-test

🕑 bases/source-acceptance-test https://github.com/airbytehq/airbyte/actions/runs/1534569675
✅ bases/source-acceptance-test https://github.com/airbytehq/airbyte/actions/runs/1534569675