A release tag is a name attached to a point in history. It is not a test strategy.
In the v1.28.5-to-v1.28.6 sequence, WorldScript Studio encountered a tag-first native build and parity failure. The useful lesson is not that tags are bad. It is that a tag can arrive before the evidence needed to trust the candidate.
If the first meaningful native build starts only after the tag exists, the process has committed to a candidate before exercising one of its important paths.
Build the candidate you intend to name
Release validation should be tied to an exact source identity. If the native bundle is built from one tree but the tag points somewhere else, a successful build does not qualify the tagged commit. If the pipeline discovers a parity issue only after tagging, the team has to decide whether to repair the same tag, create a successor, or publish partial artifacts.
A safer order is to choose the candidate commit, run the relevant platform builds and qualification steps against that commit, review the outcomes, and only then create the tag. The tag becomes an identity for evidence already collected, not a trigger for the first meaningful experiment.
This does not mean every possible environment can be tested in advance. It means the process should be explicit about which jobs are candidate qualification and which are tag-time publication.
Workflow graphs reveal real dependencies
On current main, the Tauri release job has a dependency on the bundle job. The Docker workflow and OSV audit are separate tag-triggered workflows. They therefore have independent outcomes unless another mechanism coordinates them.
That shape matters. A green Tauri result cannot stand in for Docker publication. A successful container push cannot stand in for a clean dependency audit. And a tag event can start multiple workflows without making them one atomic release transaction.
The job graph should encode dependencies that automation must enforce. Where workflows remain mechanically independent, the release protocol must not imply that a dependency exists just because operators watch the same dashboard.
Distinguish parity from equivalence
A “similar” local build is not the same evidence as the exact commit, runner, configuration, and artifact intended for release. Toolchain versions, platform permissions, environment settings, and packaging inputs can all change what gets produced.
For each candidate, record the source SHA, build environment, artifact digest, and qualification outcome. If a candidate is rebuilt, the new artifact is a new evidence subject. If the tag moves, prior evidence may no longer apply.
Move discovery earlier, preserve truthful release states
The point of pre-tag build qualification is to find expensive surprises while the candidate is still easy to replace. A failed candidate should remain a failed candidate. Creating a tag does not convert failure into success, and completing one platform’s build does not qualify another platform’s package.
The old incident is a reminder to make release order match the claims the team wants to make. Build the candidate. Qualify the relevant outputs. Bind the evidence to the exact source and artifact. Then tag the thing that passed.
Continue reading
Next: Test the Artifact You Built, Not an Equivalent Rebuild carries the same identity question from release candidates to the exact bytes that ran.
Related: The PR Was Green. Main Was Red. follows the same evidence-boundary problem from reviewed changes to the state that landed on main.
Practical extension: rehearse the candidate before naming it
Move expensive discovery earlier by building the candidate from the same commit and workflow shape that a tag will use. The goal is not to pretend every pre-tag build is identical to a release; it is to expose predictable failures before the release name becomes public.
Record the commit, workflow file revision, dependency lockfile, runner image, toolchain, and produced artifact digest. Then state which later step changes the evidence: a new runner, a tag-triggered workflow, a signing identity, a packaging configuration, or a rebuilt binary. If the release pipeline builds again, qualify that output independently instead of transferring the earlier green result.
Before creating a tag, ask:
- Did the exact candidate pass the checks required by repository policy?
- Did the workflow that will run on the tag complete without skipped or cancelled dependencies?
- Are the artifacts from the candidate or from a later rebuild?
- Can a reviewer map each user-facing claim to a recorded run and digest?
Required checks and their expected source can be configured in GitHub rulesets; the platform documents that source binding in available ruleset rules. This makes the check identity part of the release contract, not a label inferred from a green badge.
Top comments (0)