fix(release): pass an explicit npm dist-tag, stop tee masking a failure - #61
Merged
Conversation
Two defects in the GitHub Packages publish step, neither yet surfaced
because release.yml has not been tagged since.
npm/cli refuses to publish a prerelease version whose dist-tag is left
at its default ("You must specify a tag using --tag when publishing a
prerelease version"); the check is on whether --tag was passed at all,
not on its value. Every version this step publishes is a pre-release, so
the next tagged run would have stopped here with the NuGet packages
already pushed - which is exactly how v0.5.0-preview.3 failed in
vault-extract and had to be re-cut.
--tag latest is passed explicitly rather than reusing
steps.channel.outputs.npm-tag ("next" here): this registry only ever
receives pre-releases - stable goes to npmjs under the public @dignite/*
name - so latest tracking the newest preview is what a consumer of this
channel wants, it keeps an unpinned install resolving, and it stops the
latest tag earlier untagged publishes already set from freezing on a
stale preview.
The second defect is why the first would have been hard to read: the
publish ran as `if ! npm publish ... | tee`, and the step shell is
`bash -e` with no pipefail, so the pipeline status was always tee's.
The failure branch could never fire, the "already published" soft skip
was unreachable, and an E401 - or this --tag error - would have been
reported as a green step. Redirect to the log and test npm's own exit
status instead, which is also what turns `exit 1` into `exit $status`.
Same bug and same fix as vault-extract's release workflow.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two defects in
release.yml's Publish pre-release Angular package to GitHub Packages step. Neither has surfaced yet because the workflow has not been tagged since — the nextv*tag would have hit both.1. The publish would have failed on its dist-tag
npm/cli now refuses a version carrying a SemVer pre-release suffix when its dist-tag is left at the default:
The check is
isDefault('tag') && !manifest.publishConfig?.tag— whether--tagwas passed at all, not what it was set to. Every version this step publishes is a pre-release (the step is gated onchannel == 'preview'), so the next tagged run would have stopped here after the NuGet packages had already been pushed.That is not hypothetical — it is exactly how
v0.5.0-preview.3failed in vault-extract today, leaving that version published on the NuGet channel only and forcing a re-cut as0.5.0-preview.4.abp-moduleswas never exposed: both of its publish steps already pass--tag.--tag latest, notsteps.channel.outputs.npm-tag(which isnexton this branch). GitHub Packages only ever receives pre-releases here — stable goes to npmjs under the public@dignite/*name — solatesttracking the newest preview is what a consumer of this channel wants, it keeps an unpinned install resolving, and it stops thelatesttag that earlier untagged publishes already set from freezing on a stale preview.2. A failed publish was reported as a green step
The publish ran as:
The step shell is
bash -ewith nopipefail, so the pipeline's status is alwaystee's — zero. Theif !branch could never fire: the "already published" soft skip was unreachable, and a real failure (anE401, or the--tagerror above) would have passed as success. Same bug vault-extract's release workflow shipped and fixed; this is the same fix — redirect to the log, testnpm's own exit status, and propagate it (exit 1→exit $status).Verification
The workflow file parses, and the step's
runblock carries--tag latest, no liveteepipeline, andexit $status.verify-packed-npm-install.shis unaffected: it installs the exact version (npm:@dignite-projects/ng.site@${version}), never a dist-tag.CHANGELOG entry added under
[Unreleased] / Fixed.