⚠️ Retire destination-bigquery-denormalized

[evantahler]

Closes #28449

Breaking Change Playbook - https://docs.google.com/document/d/1kJjEsc5UrYxVIkkS4eaEFIf9gCoHIPKlVMqADPaqiVY/edit

The destination was created in 2021 here #4176

[github-actions]

Before Merging a Connector Pull Request

Wow! What a great pull request you have here! 🎉

To merge this PR, ensure the following has been done/considered for each connector added or updated:

• PR name follows PR naming conventions
• Breaking changes are considered. If a Breaking Change is being introduced, ensure an Airbyte engineer has created a Breaking Change Plan and you've followed all steps in the Breaking Changes Checklist
• Connector version has been incremented in the Dockerfile and metadata.yaml according to our Semantic Versioning for Connectors guidelines
• You've updated the connector's metadata.yaml file any other relevant changes, including a breakingChanges entry for major version bumps. See metadata.yaml docs
• Secrets in the connector's spec are annotated with airbyte_secret
• All documentation files are up to date. (README.md, bootstrap.md, docs.md, etc...)
• Changelog updated in docs/integrations/<source or destination>/<name>.md with an entry for the new version. See changelog example
• The connector tests are passing in CI
• If set, you've ensured the icon is present in the platform-internal repo. (Docs)

If the checklist is complete, but the CI check is failing,

1. Check for hidden checklists in your PR description

2. Toggle the github label checklist-action-run on/off to re-run the checklist CI.

[edgao]

🍄 ☁️

(assuming the metadata changes work the way we want)

[evantahler]

Update - for the period until Nov1, we are just going to call this a breaking change and publish a V2 is a no-op. Then we can delete the connector after Nov 1

[bnchrch]

Thumbs up on the metadata side!

[edgao]

lgtm... though getting tests to green might be a challenge, given the state of the bq-denormalized codebase

it might actually be easier to just manually copy the docker image to 2.0.0 instead of publishing a new build, and then do any metadata operations to activate the breaking changes stuff? That feels safer too - I definitely wasn't trying to keep bigquery-denormalized in good shape when publishing dv2, so there might be real test failures in the current codebase.

[erohmensing]

This will be a little weird that it will still tell the user to upgrade by the deadline. If they upgrade, their connections will still sync, with the same code as before. Maybe that's what you meant in the migration guide?

[erohmensing]

Once we have the sync pauser, after this date there should be no more running syncs on this destination - at which time (or maybe a little after, to give them the kick in the butt to move over to the new one once the syncs stop running) we can tombstone the connector (which tombstones their actors/connections) 👍🏻

[erohmensing]

Basically I'm wondering if the end goal of this is "all syncs are paused, and then we can delete them" or "we let them keep vibing but shrug if they have any problems"

[evantahler]

I added one final change in e758357 to override the dockerImageTag in both cloud and oss to continue run v1.5.3 when users click upgrade. This way, if anyone really does need this connector for some reason, it will still work. Above, @edgao commented that the Dv2 work has been ignoring this connector (rightfully so), and this connector's code might be totally borked now. I think this easier and clearer than copying the image/re-tagging it.

I'll will be doing step 2 later this week, where we remove both the code from this repo, and set the registries to false, so no new connections can be made

[edgao]

does the registry override mean that we won't get the breaking change notification? (because cloud will see the latest version as 1.5.3)

otherwise

[evantahler]

does the registry override mean that we won't get the breaking change notification? (because cloud will see the latest version as 1.5.3)

Dang! Good point. Ok, reverted that change in 38cc904 - I'll do the manual docker image tagging to duplicate 1.5.3 to 2.0.0 first before merging this in.

[github-actions]

destination-bigquery-denormalized test report (commit 38cc90473a) - ❌

⏲️ Total pipeline duration: 21mn02s

Step	Result
Java Connector Unit Tests	✅
Build connector tar	✅
Build destination-bigquery-denormalized docker image for platform linux/x86_64	✅
Java Connector Integration Tests	❌
Validate airbyte-integrations/connectors/destination-bigquery-denormalized/metadata.yaml	✅
Connector version semver check	✅
Connector version increment check	✅
QA checks	✅

🔗 View the logs here

☁️ View runs for commit in Dagger Cloud

Please note that tests are only run on PR ready for review. Please set your PR to draft mode to not flood the CI engine and upstream service on following commits.
You can run the same pipeline locally on this branch with the airbyte-ci tool with the following command

airbyte-ci connectors --name=destination-bigquery-denormalized test

[edgao]

womp womp. sounds like a plan

[evantahler]

I have manually created the docker tag airbyte/destination-bigquery-denormalized:2.0.0 with the following command:

docker buildx imagetools create -t airbyte/destination-bigquery-denormalized:2.0.0 airbyte/destination-bigquery-denormalized:1.5.3

Thanks, StackOverfolow!

It looks right on docker hub because the SHAs match v1.5.3

[evantahler]

/approve-and-merge reason="destination-bigquery-denormalized is going away. This PR adds a breaking change warning"

[octavia-approvington]

Approve this