Skip to content

v0.121.2

Choose a tag to compare

@smm-h smm-h released this 13 Sep 23:28
· 1623 commits to main since this release

Go binary releases ship their archives, and a release that ships none fails loudly.

Context

A releasable published its Go module, its PyPI package and its npm package with
zero archives on its GitHub Release, and the release reported success. Two
independent defects met:

goreleaser reads GORELEASER_CURRENT_TAG's tag contents while collecting git
state -- before --skip=validate can excuse anything -- so the bare vX.Y.Z tag the
generated workflow derives from a prefixed monorepo tag aborted the build, since
no ref in the repository carries that name. The workflow now creates that tag
locally at the released commit (lightweight, never pushed, a no-op where tags are
already bare), and the goreleaser version is pinned exactly from rlsbl's
action-version table rather than floating on "~> v2", which is how the breaking
goreleaser arrived unasked in the first place.

And nothing noticed. The post-publish check asked registries whether the version
was being served; the Go proxy serves a module from its tag whether or not a
single archive exists, so it answered yes. A pipeline whose declared artifact is
a binary is now also asked for its Release assets, per platform its goreleaser
config declares, plus checksums.txt -- and per member in a batch.

Fixes

  • Go binary releases publish their archives again. The generated Go publish workflow now creates the bare vX.Y.Z tag goreleaser reads before running it, so a monorepo releasable whose tags are prefixed (name@vX.Y.Z) no longer fails the build with couldn't get tag contents -- which shipped a GitHub Release carrying zero archives while the release reported success. The goreleaser version is pinned exactly instead of floating on ~> v2, so no scaffolded project adopts a goreleaser release on its own. Re-run rlsbl scaffold to pick this up.
  • A release that publishes no binaries is now a hard error. After CI concludes, a pipeline whose artifact is a binary has its GitHub Release checked for the archives it ships -- one per platform its goreleaser config declares, plus checksums.txt -- instead of only asking registries whether the version is served. A Go module is served from its tag whether or not a single archive was built, so a broken publish workflow used to end as a green release with nothing downloadable. The failure names what is missing and points at rlsbl release retry; in a batch, each member's own Release is checked.