ci(release): one runner per target, reuse build.yaml's warm caches - #961
Merged
Conversation
…'s caches The Release job built darwin plus all four zig cross targets in one goreleaser invocation on a single 3-core macOS runner (37 min in v2.18.5), with setup-go's default GOCACHE that the Go Test workflow populates with -race objects no cross target can use. PR #951 fixed both for build.yaml but not here. Cross targets now build on a Linux matrix with the same cache keys and paths as build.yaml, so a tag pushed after a main build restores warm objects (~35s per target vs ~6 min cold). macOS only builds darwin. goreleaser OSS can't release prebuilt binaries, so each job archives its own output in the same layout and a final job writes checksums.txt and creates the draft release with gh.
rektdeckard
approved these changes
Sep 2, 2026
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
2 participants
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
Releasejob for v2.18.5 took 39 minutes, 36m43s of it inRun GoReleaser. v2.18.4 and v2.18.3 look the same, so this is not a regression: #951 moved the PR/main Build workflow to one runner per zig target with per-targetGOCACHEcaches, butrelease.yamlkept the pre-#951 shape:macos-latestrunner (3 vCPU) compiling darwin plus all four zig cross targets in a single goreleaser run; the cross targets took 11 to 22 minutes each, two at a time, while both darwin builds finished in ~2 minutessetup-go's default cache (cache: true), whose key is only OS/arch/Go version/go.sum and so collides with the Go Test workflow's macOS leg. Test claims the key first with native-raceobjects,actions/cachenever overwrites on a hit, and the release restored 702 MB of objects no zig target could use, every release. This is the same collisionbuild.yamlalready documents and opts out of.The warm cache does work for zig targets once it actually contains their objects. Build runs on
mainsince #951: 267s to 401s per target on the first (cold) run, 22s to 60s on every run since, including the 712b1f7 run that preceded this tag.Change
buildjob: a matrix of the four zig targets onubuntu-latestpluslk-darwinonmacos-latest, each runninggoreleaser build --id <target>. TheGOCACHEand.crosscache keys and paths are identical tobuild.yaml's so the tag build restores what the push tomainjust saved (caches on the default branch are readable from tag refs). No new cache footprint, which matters because the repo's Actions cache sits at 9.8 GB of the 10 GB quota.prebuiltbuilder or--split, so each job archives its own binaries in the layoutgoreleaser releaseproduced (lk_<version>_<os>_<arch>.tar.gz/.zipwithLICENSE,autocomplete/and the binary at the root), and a finalreleasejob writeschecksums.txt(samesha256sumformat) and runsgh release create --draft --generate-notes, with--prereleasewhen the tag has a prerelease suffix. Published releases already use GitHub's generated notes, so the body format is unchanged.lk-darwinid (separate commit) so one macOS job builds both arches.build.yaml's darwin cache key is renamed togo-<os>-lk-darwin-so both workflows share it.Verified locally:
goreleaser check,goreleaser build --snapshot --id lk-darwin, and thePackage archivesstep against its output produce the same archive layout as the v2.18.4 assets.Expected: ~39 min → ~5 min when caches are warm, ~8 min cold.