feat(release): add force option to delete/recreate dangling tags and releases (#7119)

[Hugo Dupras (jabesq)]

Proposed changes

• Add a force option to the release-connector workflow that deletes and recreates an existing GitHub Release/tag for a version, to recover from a partially failed release (e.g. manifest fragment generation or XTM Hub publish failure) that left a dangling tag/release behind
• Skip connectors without a manifest file in the bulk-release workflow instead of failing the whole run

Related issues

• Closes feat(decoupling): send manifest fragment #7119

Checklist

• I consider the submitted work as finished
• I have signed my commits using GPG key.
• I tested the code for its functionality using different use cases
• I added/update the relevant documentation (either on github or on notion)
• Where necessary I refactored code to improve the overall quality

Further comments

A follow-up stacked PR (manifest-fragment min_version fix) branches off this one; merge this PR first.

[Copilot]

Pull request overview

Adds a force mode to the GitHub Actions-based connector release workflows to help recover from partially failed releases (dangling releases/tags) and updates bulk release resolution to skip connectors that lack a manifest.

Changes:

• Add force input propagation and overwrite/cleanup logic to the per-connector release workflow.
• Add force support to the bulk orchestrator workflow, including dispatch + tracking label updates.
• Update bulk connector discovery to exclude connectors missing __metadata__/connector_manifest.json.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
.github/workflows/release-connector.yml	Adds force input handling and introduces overwrite-guard + failure cleanup behavior during release creation.
.github/workflows/release-bulk-connectors.yml	Adds force input wiring, dispatch flags, and tracking-title updates for bulk runs.
.github/scripts/bulk_release.py	Skips connectors without a connector_manifest.json during “all connectors” discovery.

Suppressed comments (3)

.github/workflows/release-connector.yml:590

• This condition prints a warning that it is “skipping” XTM Hub publish, but then exits 1 (failing the release). If publishing is intended to be blocking, this should be an error message (and not described as skipping).

          if [ -z "$XTM_HUB_TOKEN" ]; then
            echo "::warning::XTM_HUB_TOKEN secret not set -- skipping XTM Hub publish"
            exit 1
          fi

.github/workflows/release-bulk-connectors.yml:231

• The job summary text says force mode will delete/recreate tags, but the per-connector workflow reuses existing tags. Consider updating the wording to avoid implying the tag will be recreated (and potentially moved).

            if [ "$FORCE" = "true" ]; then
              echo "⚠️ **Force mode** — any existing tag/GitHub Release at this version will be deleted and recreated for every connector."
              echo ""
            fi

.github/workflows/release-connector.yml:781

• This step says it is “skipping” when the manifest is missing, but it exits 1. Since the whole job is marked continue-on-error: true, returning 0 here would better match the intent (skip without surfacing a red failed step).

          if [ ! -f "$MANIFEST" ]; then
            echo "⚠️ Manifest not found: $MANIFEST — skipping"
            exit 1

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.