Make a version bump the release - #14
Merged
Merged
Conversation
Landing a fix on master published nothing. Both release workflows fire on a tag only, so every release waited on someone remembering to push `<package>-v<version>` by hand, and master could sit ahead of npm indefinitely. It did: the compiler fix merged at 0.2.3 while npm served 0.2.2. The convention this repository already follows is that a fix bumps the version in the same commit, so the bump is the intent to release and nothing else needs saying. Both workflows now also run on a push to master, and each publishes a package when the version there is not on npm. npm is the check rather than the diff. A rerun, or a publish that died after packing, is safe to repeat, and a merge that touched no version resolves to nothing and skips its build rather than burning three matrix jobs to produce an artifact nobody publishes. Deliberately not modelled on the @pathscale/ui release, which infers the next version from commit messages and writes a `chore(release)` commit back to master. That makes the published version an output of parsing rather than a decision, and the parser is one more thing to be wrong. Tags keep working, for an explicit or a repeat release, and still fail when they disagree with package.json. Dispatch still builds a bootstrap artifact without publishing. `@pathscale/test-ui` is private and stays tag- and dispatch-only. release-js.yml covers three packages, so its single job became a matrix over whatever the decision selected, and artifacts are named per package rather than one shared `npm-package`. Both decision scripts were extracted and run against the real registry across every path: tag matching, tag disagreeing, dispatch, a bump landing, and a push with nothing to do.
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.
Landing a fix on
masterpublishes nothing today. Both release workflows fire on a tag only, so every release waits on someone remembering to push<package>-v<version>by hand, andmastercan sit ahead of npm indefinitely.It currently is:
solid-layoutsrsbuild-plugin-solid-layoutssolid-layouts-oxcThe rule
A version bump is the release. This repository already bumps the version in the same commit as the fix, so the bump is the intent to release and nothing else needs saying. Both workflows now also run on a push to
master, and each publishes a package when the version there is not on npm.npm is the check rather than the diff. That makes it idempotent: a rerun, or a publish that died after packing, is safe to repeat. A merge that touched no version resolves to nothing and skips its build, rather than burning three matrix jobs to produce an artifact nobody publishes.
Nothing else changes. Tags still work for an explicit or repeat release and still fail when they disagree with
package.json. Dispatch still builds a bootstrap artifact without publishing. The audited publish path, a GitHub-hosted job withid-token: writeand no npm secret, is untouched.@pathscale/test-uiis excluded from the automatic path: it isprivate: trueand unpublished, so it ships only when a tag or a dispatch names it.Not modelled on the UI release
@pathscale/uiinfers the next version from commit messages viascripts/next-version.tsand writes achore(release): … [skip ci]commit back to master. That makes the published version an output of parsing rather than a decision, and the parser is one more thing that can be wrong. Reading the version a human already wrote is less machinery and fewer ways to surprise someone.Shape
release-oxc.ymlgains adecidejob;build,packageandpublishare gated on its outputs, and the tag/version check moves into it so it can also gate the run.release-js.ymlcovers three packages, so its singlepackagejob became a matrix over whateverdecideselected, and artifacts are namednpm-package-<name>rather than one sharednpm-package. Its decision is a small Node script rather than acaseover the ref, because it now has to answer "which of these need releasing" instead of "which one did the tag name".Verification
Both decision scripts were extracted from the YAML and run against the real npm registry across every path:
build=true publish=truepackages=[] any=false, build skippedpublish=truepublish=falsepublish=falseAll three workflow files parse as YAML.
First run
Merging this releases
solid-layouts-oxc@0.2.3, which is the compiler fix from #11 that is currently sitting unpublished on master. That is the intended first exercise of the path, and it is what unblocks@pathscale/uipicking the fix up.