chore(ci): add republish workflow for re-publishing a release tag

[gwossum]

Add a republish workflow for rebuilding and republishing a release tag if the original source build succeeded, but other parts of the CI pipeline failed. This allows those parts that are not integral to building the binaries to be fixed and release performed without needing to move the tag or burn a release number.

The republish workflow takes its source from a release tag and its configuration from the branch it is triggered against. A new 'release-ref' parameter names the tag, and 'checkout_source' replaces plain 'checkout' throughout, detaching to that tag so get-version derives VERSION from it exactly as it does on a tag build.

releng/republish triggers the workflow through the CircleCI API. The workflow could also be triggered directly from the CircleCI UI.

[Copilot]

🟡 Changes recommended

Shell injection and incorrect release-version resolution could compromise or mislabel republished artifacts.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Adds a CircleCI workflow and release-engineering utility to rebuild and republish existing release tags.

Changes:

• Adds source-tag checkout and release metadata handling.
• Adds approval-gated republish jobs.
• Adds a CLI for validating and triggering republishing.

File summaries

File	Description
.circleci/config.yml	Defines republish parameters, commands, and workflow.
releng/republish	Validates and triggers republish pipelines.

Review details

Suppressed comments (3)

.circleci/config.yml:42

• This validation accepts abbreviated tags such as v1 and v1.13, but .circleci/scripts/get-version only recognizes three-component tags. An accepted republish of such a tag therefore falls back to a 1.x-<sha> version instead of rebuilding the requested release. Require all three version components here.

            if ! echo "${REF}" | grep -Eq '^v[0-9]+(\.[0-9]+)?(\.[0-9]+)?$' ; then

.circleci/config.yml:69

• Checking out the requested tag's commit does not make get-version select that tag: the script enumerates every tag pointing at HEAD and chooses the highest version. For the documented existing case where v1.9.0 and v1.9.1 share a commit, republishing v1.9.0 stamps the binaries as 1.9.1. Make get-version honor an explicit tag and set that tag before invoking it.

            # After checkout_source, HEAD is the release tag, so get-version
            # derives VERSION from it exactly as it does on a tag build.

releng/republish:188

• The tag, commit, branch, and configuration are all verified against the local origin, but this request always targets influxdata/influxdb. In a normal fork clone, the confirmation can therefore describe the fork while CircleCI builds the official repository's different refs. Verify that the selected remote is the official repository (or perform all resolution against a dedicated official remote) before triggering the request.

ENDPOINT="https://circleci.com/api/v2/project/${PROJECT_SLUG}/pipeline"

• Files reviewed: 2/2 changed files
• Comments generated: 2
• Review effort level: Balanced

---

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

[Copilot]

🟡 Changes recommended

Shared-commit tags can produce incorrectly versioned binaries, and rebuilt artifacts can publish before tests pass.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

.circleci/config.yml:668

• This gate can be approved while every rebuilt test job is still running or has failed, because none is a dependency. The republish may use a changed CI configuration and defaults to a newer floating builder, so the original release's test results do not validate these new artifacts. Require the package, static, Flux, and unit-test jobs before permitting publication.

      - hold_publish:
          type: approval
          requires:
            - sign_packages
            - changelog

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Balanced

[devanbenz]

This all seems okay to me. Just one comment.

[devanbenz]

What happens when workflow is set to republish and release-ref is not set? Should we add a guard for that of some sort?