Extract build and test into composite actions - #1
Merged
Conversation
ci.yml and release.yml each carried their own copy of the same cross-compile matrix. The CI copy built the four targets to /tmp and threw the result away; the release copy built the same four, archived them and checksummed them. Nothing kept the two lists in step, so CI could have gone on passing for a target the release had stopped building, or the reverse. This was the only real logic duplication in the repo. Now there is one definition of each, in .github/actions, called by both. A pull request builds exactly what a release builds; the only difference is that one of them goes on to publish. Build runs before Test, in both workflows. CI already did; release ran Test first. One ordering with no exceptions is worth more than the cross-compile a failing release now pays for. The version assertion moved with it, and got stricter: it extracts the archive and runs what came out, rather than the binary sitting in the build directory. The archive is what people download. It also handles the unstamped case honestly -- `--version` on a dev build reports the VCS pseudo-version from build info, not the literal "dev", so that path asserts non-empty rather than an exact string it would never match. The first release is now 0.0.1 whatever bump was asked for, matching komizo. Under 0.x a minor claims a milestone that has not happened, and a first release is not the place to claim one. Release notes carry the `go install` line. It is the one thing a consumer has to do and it is the same every time. Also: workflow_dispatch on CI, the job renamed test -> ci, third-party actions pinned by SHA, timeout-minutes on both jobs, and `name: release` lowercase to match the filename. Verified locally: both build paths (1.2.3 and dev), gofmt, vet, and the race suite. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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 largest single piece of the standardization plan, and the only real logic duplication found anywhere in the audit.
The duplication
ci.ymlandrelease.ymleach carried their own copy of the same cross-compile matrix:linux/amd64 linux/arm64 darwin/amd64 darwin/arm64to/tmpand threw the result awayNothing kept the two lists in step. CI could have gone on passing for a target the release had stopped building, or the reverse — and the release is the one nobody watches until it breaks.
Now there is one definition of each in
.github/actions, called by both. A pull request builds exactly what a release builds.Build before Test, in both
CI already did.
release.ymlran Test first. This costs a cross-compile of four platforms on a release whose tests then fail, and buys one ordering with no exceptions to remember. (Decision 1)The version assertion got stricter
It now extracts the archive and runs what came out of it, rather than the binary sitting in the build directory. The archive is what people download.
It also handles the unstamped case honestly.
ormos --versionon a dev build reports the VCS pseudo-version from build info — verified locally as0.0.0-20260729205949-42b7c9e6c809+dirty— not the literaldev. So that path asserts non-empty rather than an exact string it could never match. Asserting"dev"would have failed every pull request.Other changes
go installline in the release notes. (C7)workflow_dispatchon CI. (C4)test→ci. (C3)timeout-minutes: 20,name: releaselowercase to match the filename. (X1, X2)0.0.1, matchingkomizo, replacing the bump-aware1.0.0/0.1.0/0.0.1mapping. (C6 / Decision 5)Correction on that last point
An earlier version of this description said this repo had no tags and that this run would produce
v0.0.1. That was wrong — I read tags from a local clone that had never fetched them. This repo is atv0.1.0, released 2026-07-29, sorelease.ymlhas run before and the bootstrap branch is unreachable. The next bump from here isv0.1.1.The bootstrap change is still worth keeping: it makes the two CLI repos say the same thing, and it is the path the next CLI repo takes. It just does not affect this one.
Verified locally
Both build paths (
1.2.3→ exact match,dev→ non-empty),gofmt,go vet, and the full-racesuite across all three packages.Phase 4 of the standardization plan (C1).
🤖 Generated with Claude Code