feat(registry): add cdk version

[bnchrch]

What

Adds the cdk version for python connectors to the regisry

closes https://github.com/airbytehq/airbyte-internal-issues/issues/7462

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
airbyte-docs	⬜️ Ignored (Inspect)	Visit Preview		May 9, 2024 2:46pm

[bnchrch]

• feat(registry): add cdk version #37809 👈
• Add provinance to the registry entry #37804
• Notify commit owner via slack message #37803
• Upload git info with metadata file (#1) #37802
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @bnchrch and the rest of your teammates on Graphite

[alafanechere]

If this is to power docs I'd appreciate a dedicated docs field or a cdk_version top level field.
I'm concerned about introducing a dependencies field which just has the CDK ATM. I'd prefer dependencies to contain all dependencies, and find a language agnostic way of expressing them.
So I'd be fine with both or either one of these approaches:

• Add all connectors dependencies to dependencies (basically copying the information available in these files
• Add a doc specific field to the registry entry which would show the CDK version (after searching it from the dependencies field or directly from dependencies.json).

[bnchrch]

Fair point!

What are your thoughts on cdk_version as a top level field?

or moving cdk_version under generated?

[alafanechere]

Fair point!

What are your thoughts on cdk_version as a top level field?

or moving cdk_version under generated?

Happy to move cdk_version to a top level field and find a way to tell if it's the python or java cdk version.
Could be two, mutually exclusive, top level fields: python_cdk_version, java_cdk_version

[bnchrch]

Im thinking we avoid adding cdk_version to the top level of the registry for the following reasons:

1. Not all connectors will have a CDK version
2. If we keep adding info like this to the top level it will get messy

So I wanted to ask you is there a top level field we could use to contain this that:

1. Would make sense to put cdk_version under
2. Would not be prescriptive to where its used/consumed? (This was why I wasnt immediately happy with docs)
3. We likely would put future fields under

?

[bnchrch]

Merge activity

• May 9, 10:18 AM EDT: @bnchrch started a stack merge that includes this pull request via Graphite.
• May 9, 10:46 AM EDT: Graphite rebased this pull request as part of a merge.
• May 9, 11:02 AM EDT: @bnchrch merged this pull request with Graphite.