Skip to content

fix(release): install Zsh before verifying the release tag - #497

Merged
ss-o merged 1 commit into
nextfrom
bug-496
Sep 3, 2026
Merged

fix(release): install Zsh before verifying the release tag#497
ss-o merged 1 commit into
nextfrom
bug-496

Conversation

@ss-o

@ss-o ss-o commented Sep 3, 2026

Copy link
Copy Markdown
Member

Adds the missing Zsh install to the publish job. One step.

The defect

release.yml runs the authorization verifier under Zsh:

- name: Verify release authorization
  run: zsh -f scripts/verify-release-tag.zsh

ubuntu-latest ships no Zsh, so the step exits 127 before any verification happens and publication fails for every tag:

/home/runner/work/_temp/....sh: line 1: zsh: command not found
##[error]Process completed with exit code 127

Every other workflow that runs Zsh installs it first (promotion-readiness.yml:27, zsh-n.yml:84). The publish job was the only one that did not. I swept the remaining workflows for the same shape and found no other occurrence.

Why it went unnoticed

The workflow reached main only with #494, since #470 added it on next before v2.0.0 shipped. Pushing v2.0.1 was its first ever execution, and it failed on that run. Latent since #470.

What happened to v2.0.1

Published manually, because the alternative was worse. verify-release-tag.zsh requires the tag target to equal the current origin/main, so landing this fix moves main and invalidates any tag already pushed. Recovering through the workflow would have meant either moving a public tag or burning a version number.

Before publishing I ran the verifier locally against the exact tag:

Release authorization verified for v2.0.1 at 86758198344052d60b25f454cd3b64269a8ef2ea.

so the authorization logic was exercised in full and only its broken execution environment was bypassed.

Follow-up worth considering, not in this PR

That same tag-equals-main precondition is what made this failure expensive to recover from: any fix to the release path invalidates the pending tag. Loosening it to "tag target is an ancestor of origin/main" would preserve the intent, that a release comes from reviewed stable history, while allowing a straightforward retry. Raised in #496 and left for a separate decision.

Closes #496

The publish job runs

    zsh -f scripts/verify-release-tag.zsh

on ubuntu-latest, which ships no Zsh, so the step exits 127 before any
verification happens and publication fails for every tag:

    /home/runner/work/_temp/....sh: line 1: zsh: command not found

Every other workflow here installs Zsh before running it, promotion-readiness
and zsh-n among them. This job was the only one that did not.

Latent since #470, because the workflow reached main only with the #494
promotion. Pushing v2.0.1 was its first execution and it failed on that run.
v2.0.1 was published manually after running verify-release-tag.zsh locally
against the exact tag, which passed, so the authorization logic was exercised
and only its broken environment was bypassed.

Swept the other workflows for the same shape; this was the only occurrence.

Closes #496
@ss-o ss-o mentioned this pull request Sep 3, 2026
@ss-o
ss-o merged commit 8104e93 into next Sep 3, 2026
9 checks passed
@ss-o
ss-o deleted the bug-496 branch September 3, 2026 00:51
@ss-o ss-o mentioned this pull request Sep 3, 2026
13 tasks
@github-actions github-actions Bot mentioned this pull request Sep 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant