fix: metadata upload is conditional

[edgao]

#64886 split the metadata upload step into manual+merge, but we're running both >.> add the appropriate if clauses to each. Example failure - https://github.com/airbytehq/airbyte/actions/runs/16905539138/job/47894364199

This is probably breaking prerelease publishes, but nobody has tried that yet.

this isn't causing any correctness problems, b/c the new action is only pushing into the dev bucket. Just causes the publish to fail. It's not even really blocking master-merge, b/c we still run all the necessary steps to publish the connector.

[github-actions]

👋 Greetings, Airbyte Team Member!

Here are some helpful tips and reminders for your convenience.

Helpful Resources

• Developing Connectors Locally
• Managing Connector Secrets
• On-Demand Live Tests
• On-Demand Regression Tests
• #connector-ci-issues
• #connector-publish-updates
• #connector-build-statuses

PR Slash Commands

Airbyte Maintainers (that's you!) can execute the following slash commands on your PR:

• /format-fix - Fixes most formatting issues.
• /bump-version - Bumps connector versions.
  • You can specify a custom changelog by passing changelog. Example: /bump-version changelog="My cool update"
  • Leaving the changelog arg blank will auto-populate the changelog from the PR title.
• /run-cat-tests - Runs legacy CAT tests (Connector Acceptance Tests)
• /build-connector-images - Builds and publishes a pre-release docker image for the modified connector(s).
• /poe connector source-example lock - Run the Poe lock task on the source-example connector, committing the results back to the branch.
• /poe source example lock - Alias for /poe connector source-example lock.
• /poe source example use-cdk-branch my/branch - Pin the source-example CDK reference to the branch name specified.
• /poe source example use-cdk-latest - Update the source-example CDK dependency to the latest available version.

📝 Edit this welcome message.

[dbgold17]

is this to fit in with the paradigm of having separate steps for manual vs master merge? What happens if we define this as a single step that runs all of the time?

[edgao]

is this to fit in with the paradigm of having separate steps for manual vs master merge? What happens if we define this as a single step that runs all of the time?

yep. This is to support the paradigm where the GHA step has a hardcoded --main-release / ${{ inputs.publish-options }}.

When we do https://github.com/airbytehq/airbyte-internal-issues/issues/13874, we'll presumably add a step that outputs docker_image_tag or something? And just pass that into the script directly, rather than passing --main--release/--pre-release and having the script recompute the tag

(which would then allow us to combine the manual/on-merge steps into a single unconditional step)