ci: allow releasing the Go module on its own - #120
Merged
Conversation
The Go module was the only package that could not be published from the Actions tab: tag-go-module ran on a release event alone, and a release event also uploads to PyPI and npm. That was the shape the Go port needed the day it landed — the other two were already at 1.6.0 and had nothing new to publish — and it had to be done by hand. `target` now takes `go`, and `both` becomes `all` since there are three packages to choose from. Run from a release the module tag still points at the release's tag; run by hand it points at the dispatched commit, which is what releasing the module alone means. Two guards, because a published Go version is immutable in the proxy and cannot be replaced: the job refuses a version that is already tagged, and refuses a commit that carries no go/go.mod, which would otherwise cache an empty module forever. `dry_run` reports what it would tag.
Review of the previous commit found that refusing an existing tag broke the path this very change adds: dispatch the module tag at 1.7.0, then publish the 1.7.0 release, and the release workflow goes red at a step that has nothing left to do — with PyPI and npm already published, and advice to bump a version that is correct. Re-running a release after a transient upload failure hit the same wall. The check now compares commits rather than names: the same commit is a no-op, a different one is the immutable-version error it was meant to be. Two more, both about a push that cannot be taken back. A dispatch can be started from any branch, so the commit now has to be on main. And the dry-run guard read "true means dry run", which pushed for any other value — including the empty string a trigger with no inputs would produce; it now pushes only when told "false" in so many words. The section in CONTRIBUTING promised a flow the version gate forbids: bumping only the Go version fails verify-versions, so target: go publishes the version the repository already declares, which is what it is for.
The guards were hard failures even in a dry run, so the only way to try a change to a dispatch — running it from its own branch — died at the first one. They now report what they would refuse and leave the job green: a rehearsal has nothing to undo. The commit is resolved through the same path, rather than letting the step die on a raw git message with no annotation, and the ancestry check tells apart "not an ancestor" from git failing, so an infrastructure problem stops reading as an accusation about the commit. The tag job now runs after the two registry jobs. It is the only step here that cannot be taken back, and a proxy that will serve a version forever should not outlive an upload that was rejected. Skipped dependencies would otherwise take the job with them on a single-target dispatch, which the cancelled/failure guard prevents.
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
1 participant
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.
The Go module is the only package that cannot be published from the Actions
tab.
tag-go-moduleruns on a release event alone, and a release event alsouploads to PyPI and npm — so releasing the Go SDK meant releasing all three, or
tagging by hand, which is how
go/v1.6.0went out.What changes
targetnow offersgo, andbothbecomesallnow that there are threepackages to choose from:
allpypinpmgoA release event still publishes everything, exactly as before.
Where the tag points depends on how the job was started. From a release it is
the release's own tag, as today. By hand it is the dispatched commit — which is
what releasing the module on its own means: the other two packages did not
change, so there is no release tag to hang it from.
Guards
A published Go version is immutable in the module proxy — it cannot be deleted
or replaced, only retracted — so the job now refuses to:
go/flightradarapi/doc.goto bumpgo/go.mod, which would cache an empty module foreverdry_run(on by default) reports what would be tagged and pushes nothing.Testing
The workflow cannot run before it is merged, so the step's script was extracted
from the YAML and exercised directly, once per path:
The malformed-tag case is already covered upstream:
verify-versionscomparesthe release tag against the three declared versions before this job runs.