Skip to content

release: v<YYYYMMDD>.<NN> by release.yml after CI, and go tool task runs the latest go-tools - #101

Merged
aledbf merged 3 commits into
mainfrom
tool-latest
Nov 9, 2026
Merged

aledbf merged 3 commits into
mainfrom
tool-latest

Conversation

@aledbf

@aledbf aledbf commented Nov 9, 2026

Copy link
Copy Markdown
Member

Follow-up to #100, after a decision (2026-11-09):

  • go-tools is released automatically each time CI passes on main;
  • the name follows spin's rules;
  • repositories run the latest release, with nothing pinning go-tools in their versions.yaml.

Releases (release.yml)

  • Started by workflow_run when CI succeeds on a push to main. It checks out the commit that passed, not whatever main is by then.
  • The name is v<YYYYMMDD>.<NN>, as spin's hack/releaseversion: the UTC day and the day's sequence number, two digits (internal/release, internal/release/cmd/releasename).
    • A commit that's already released (CI re-run) is that release, not a second one.
    • vYYYYMMDD.NN isn't three-number semver, so go get never takes these tags for module versions.
  • It builds, attests (attest-build-provenance) and publishes last. The release creates the tag, so a failed publish leaves no tag without files.
  • Each release carries a checksums.txt.
  • The release job leaves ci.yml. One release at a time (concurrency: release).

go tool task (cmd/task)

  • Task: from versions.yaml, pinned by sha256 per platform, as before.
  • go-tools: the latest release (toolcache.Latest).
    • It resolves the name with the /releases/latest redirect, which counts against no API quota.
    • It checks the archive against the sha256 in that release's checksums.txt and unpacks it once.
    • It asks which release is the latest at most every 10 minutes. With no network, it keeps using the release it already has, no network needed.
  • Gate: with cmd/task in go.mod it only requires task. The go-tools entry and its tie to go.mod go away.

What this gives up

With no pin, a go-tools release reaches every repository's next run without a PR in each. It's protected by the gate that passed on main and the attestation, not by a sha in each repository. checksums.txt guards against a corrupt download, not a malicious release.

Checked

  • task lint, task test and task site pass.
  • go run ./cmd/mutate -base origin/main -max 600: 0 survived.
  • release:name and release:build ran locally: the next name today, and the checksums of the four archives.

bin-20261109.212154, from #100, stays as an old release. The first v... is cut when this merges, and becomes the latest.

🤖 Generated with Claude Code

aledbf and others added 3 commits November 9, 2026 18:38
…atest

Releases are named as spin-stack names releases (internal/release, as
spin's releaseversion): v<YYYYMMDD>.<NN>, the day in UTC and its number.
release.yml makes one of main each time CI passes on it - the commit that
passed - builds, attests, and publishes last, with a checksums.txt; a
commit released already is that release, not a second one.

cmd/task takes go-tools from the latest release, held to the sha256 its
checksums give, asking which is the latest at most every ten minutes and
going on with the last one offline (internal/toolcache's Latest). No
versions.yaml pins go-tools, so the gate asks only for task.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…that nothing refused

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@aledbf
aledbf merged commit b4b5f4a into main Nov 9, 2026
3 checks passed
@aledbf
aledbf deleted the tool-latest branch November 9, 2026 21:47
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