Publish connectors whose dockerfile versions were already updated

[erohmensing]

What

The following connectors have dockerfile versions higher than on dockerhub because they weren't published, although their code was merged to master:

• source-recharge (PR)
• source-slack (PR)

The following were published but the *_definitions.yml file wasn't generated automatically and wasn't manually updated accordingly:

• source-tiktok-marketing (publish comment)
• destination-databend (PR - looks like they were generated, but a later force push removed them)

How to fix

Publish the first 2 in this PR, updating the changelogs accordingly. Only changes should be changelog dates and commits made automatically via the publish workflow.

After the first 2 are published, manually update source_definitions.yml and destination_definitons.yml to reflect the correct latest versions for databend and tiktok marketing.

[erohmensing]

/test connector=connectors/source-recharge

🕑 connectors/source-recharge https://github.com/airbytehq/airbyte/actions/runs/4237673067
❌ connectors/source-recharge https://github.com/airbytehq/airbyte/actions/runs/4237673067
🐛 https://gradle.com/s/jfffksfwoyjz6

Build Failed

Test summary info:

=========================== short test summary info ============================
FAILED test_core.py::TestBasicRead::test_read[inputs0] - Failed: Stream produ...
SKIPPED [1] ../usr/local/lib/python3.9/site-packages/connector_acceptance_test/tests/test_core.py:98: The previous and actual specifications are identical.
SKIPPED [1] ../usr/local/lib/python3.9/site-packages/connector_acceptance_test/tests/test_core.py:507: The previous and actual discovered catalogs are identical.
============== 1 failed, 34 passed, 2 skipped in 93.08s (0:01:33) ==============

[evantahler]

/publish away!

I don't really know what to do if the tests fail though...

[erohmensing]

Ugh, yeah. Probably the same as last time - check if the failure is expected as of the latest #connector-health state and if so, publish without tests

[erohmensing]

/test connector=connectors/source-slack

🕑 connectors/source-slack https://github.com/airbytehq/airbyte/actions/runs/4238847117
❌ connectors/source-slack https://github.com/airbytehq/airbyte/actions/runs/4238847117
🐛 https://gradle.com/s/e2gjskhtdpmve

Build Failed

Test summary info:

=========================== short test summary info ============================
FAILED test_incremental.py::TestIncremental::test_read_sequential_slices[inputs0]
SKIPPED [1] ../usr/local/lib/python3.9/site-packages/connector_acceptance_test/tests/test_core.py:98: The previous and actual specifications are identical.
SKIPPED [1] ../usr/local/lib/python3.9/site-packages/connector_acceptance_test/tests/test_core.py:507: The previous and actual discovered catalogs are identical.
============= 1 failed, 36 passed, 2 skipped in 1911.44s (0:31:51) =============

[erohmensing]

Both failures are the same as the ones currently on master:

• recharge
• slack

With no changes here, it's using the code already on master. Both test suites were passing when the code was merged, and tests have passed in nightly runs previously after they were merged, so I don't think the fact that they are failing now is related to those code changes.

[erohmensing]

/publish connector=connectors/source-slack run-tests=false

🕑 Publishing the following connectors:
connectors/source-slack
https://github.com/airbytehq/airbyte/actions/runs/4243927769

Connector	Did it publish?	Were definitions generated?
connectors/source-slack	✅	✅

if you have connectors that successfully published but failed definition generation, follow step 4 here ▶️

[erohmensing]

/publish connector=connectors/source-recharge run-tests=false

🕑 Publishing the following connectors:
connectors/source-recharge
https://github.com/airbytehq/airbyte/actions/runs/4243929127

Connector	Did it publish?	Were definitions generated?
connectors/source-recharge	✅	❌

if you have connectors that successfully published but failed definition generation, follow step 4 here ▶️

[erohmensing]

I don't see any actors in the cloud DB that use destination-databend yet, so I think the deletion in the spec is safe - otherwise that would be a change we could probably have to enforce users who had selected a different protocol to use.