[bsinou]

Description

Up to the tag, a publication already reruns cleanly: build-image never overwrites, and promote-image, publish-chart and publish-chart-s3 answer present when the work is done. After the tag it was a dead end. draft-release refused anything that wasn't a draft, so a run that broke on the declaration, the S3 chart or the wire-builds bump could only be finished by hand. This PR makes the whole publication replayable.

draft-release resumes. With if-published: resume (the new default), resolve and publish accept a release that an earlier run published, provided its tag sits on the commit the release targets (and on expected-commit when given). resolve downloads the assets as it does for a draft. publish writes nothing: each replace-assets file has to match the published asset. For the manifest, the publication block is ignored, since a rerun completes it again with a new date; every other file is compared byte for byte. Any difference fails the step. A draft sitting next to a published release with the same tag also fails, rather than guessing. New output already-published; make-latest is unchanged on a resume. if-published: fail keeps the old strict behaviour.

publish-chart reads back. After a chart-file push, the chart is pulled again and must have the sha256 of the file (hence the same version and appVersion) and the digest the push printed. Package mode (dev builds) is untouched.

wire-builds-bump, new action. Replaces the hand-written bumps of build.json in each component. It sets version, repo and the meta fields of helmCharts.<chart> (other meta fields are kept), bumps the pre-release of the top-level version, and commits through the contents API with the blob sha as a compare-and-swap. An entry already at the target is a no-op, so a rerun, a repair or a commit whose answer got lost all end with unchanged. When another commit lands in between, the file is read and the change applied again (5 attempts). Before each write, the file minus .version and the chart's entry must be identical to what was read (normalized with jq -S).

templates/repair-publication.yml. A workflow for components to copy: workflow_dispatch with version, reason and a typed confirm (v<version>), gated by release-publication. It resolves the published release (and refuses a draft), verifies the assets against the manifest, checks the image tag and the chart in the registry, then replays the declaration, the S3 chart and the wire-builds bump, each behind its own input. Nothing is rebuilt and everything comes from the release assets, which don't expire. The template calls the actions at @dev here, and make release-prep now repoints it along with dev-build.yml.

One publication at a time. templates/README.md recommends one concurrency group per repository, publish-${{ github.repository }} with cancel-in-progress: false, shared by publish-release and the repair. A group per version, which some components use today, lets two versions publish at the same time, and both then decide make_latest and both bump wire-builds.

release-manifest complete keeps the first publication. A manifest that already carries a publication block with the same digests is left as it is, first date and first run included; other digests fail. Without this, a rerun would send the release managers a manifest with a new date, and a version pinned in a published bundle answers that with a 409 (any manifest change on a locked version is refused). With it, the resend is identical. I checked the release manager side (upsert_versions): the same version, digest, declaration and manifest sent twice is an update with no change, no duplicate and no error, locked or not, and a release request that is already published isn't touched again.

Checks run locally: 652 tests, shellcheck, actionlint (workflows and templates), zizmor offline, gitleaks, commit messages.

Related Issue

• WPB-29305

Types of changes

• 🐞Bug fix – A non-breaking change that resolves an existing issue.
• ✨New feature – A non-breaking change that introduces new functionality
• 💥Breaking change – A change that alters existing functionality in a way that is not backward compatible.
• 🧼Code Cleanup - Code refactoring or improvements with no functional impact.
• 📖Documentation – Updates or additions to documentation only.
• 🛠️Tooling - fix or add tools in the repository to build / lint / ...