build: Check Go and Node before building and move Docker to Alpine 3.24 #15

Merged

linus merged 1 commit from ash/toolchain-preflight-10 into develop

2026-10-24 08:12:02 +00:00

ash commented

2026-10-24 08:07:42 +00:00

Collaborator

Closes #10.

scripts/check-toolchain.sh is the forge-standards script, copied unchanged.
New .nvmrc containing 24.
Makefile: new check-toolchain target. build, dev and docker depend on it, and run gets it through dev. It runs before clean, so a mismatch removes nothing.
CI (ci.yaml test and build jobs) and release.yaml run sh scripts/check-toolchain.sh after setup-go and setup-node.
go.mod: toolchain go1.27.2.
Dockerfile: builder golang:1.27.2-alpine3.24, runtime alpine:3.24.
README: under "rebuild frontend assets", what's checked and how to fix a mismatch.
Action majors are untouched (vulture#17).

Proof (clean checkout, Linux, go1.27.3)

Node 20 (the box default): make build stops with found: 20.19.2 / required: 24 / fix: nvm install 24 && nvm use 24. git status --ignored stays empty, so clean never ran.
Node 24.21.0: make build passes (UI build plus bin/scratchbox) and the tree stays clean. make dev starts the server (it generated the default config, as before).
Fake Go 1.26.5: build, dev, run and docker all stop at the check with found/required/fix. A marker file in bin/ survived, so nothing was cleaned.
go.mod pin edited (toolchain go1.27.3): caught, with fix git checkout -- go.mod.
Not run here: make docker with the right toolchain, because neither machine has Docker. The base images are the standard tags.

Tests

With the UI built: make test and make test-race both pass. go test ./... gives 159 passed, 0 failed, 0 skipped.
gofmt is clean. goimports -l flags cmd/scratchbox/main_test.go, which is an import-grouping issue that's already on master. I left it alone because it's out of scope.

Closes #10. - `scripts/check-toolchain.sh` is the forge-standards script, copied unchanged. - New `.nvmrc` containing `24`. - Makefile: new `check-toolchain` target. `build`, `dev` and `docker` depend on it, and `run` gets it through `dev`. It runs before `clean`, so a mismatch removes nothing. - CI (`ci.yaml` test and build jobs) and `release.yaml` run `sh scripts/check-toolchain.sh` after setup-go and setup-node. - `go.mod`: `toolchain go1.27.2`. - Dockerfile: builder `golang:1.27.2-alpine3.24`, runtime `alpine:3.24`. - README: under "rebuild frontend assets", what's checked and how to fix a mismatch. - Action majors are untouched (vulture#17). ## Proof (clean checkout, Linux, go1.27.3) - **Node 20** (the box default): `make build` stops with `found: 20.19.2 / required: 24 / fix: nvm install 24 && nvm use 24`. `git status --ignored` stays empty, so `clean` never ran. - **Node 24.21.0:** `make build` passes (UI build plus `bin/scratchbox`) and the tree stays clean. `make dev` starts the server (it generated the default config, as before). - **Fake Go 1.26.5:** `build`, `dev`, `run` and `docker` all stop at the check with found/required/fix. A marker file in `bin/` survived, so nothing was cleaned. - **go.mod pin edited** (toolchain go1.27.3): caught, with fix `git checkout -- go.mod`. - **Not run here:** `make docker` with the right toolchain, because neither machine has Docker. The base images are the standard tags. ## Tests - With the UI built: `make test` and `make test-race` both pass. `go test ./...` gives **159 passed, 0 failed, 0 skipped**. - `gofmt` is clean. `goimports -l` flags `cmd/scratchbox/main_test.go`, which is an import-grouping issue that's already on master. I left it alone because it's out of scope.

ash added 1 commit

2026-10-24 08:07:42 +00:00

build: Check Go and Node before building and move Docker to Alpine 3.24 (closes #10 )

Format / gofmt (pull_request) Successful in 21s

Details

CI / Build (pull_request) Successful in 31s

Details

CI / Go Tests (push) Successful in 45s

Details

CI / Go Tests (pull_request) Successful in 51s

Details

Format / gofmt (push) Successful in 23s

Details

CI / Build (push) Successful in 34s

Details

3c827577de

Add the forge-standard preflight (scripts/check-toolchain.sh) and .nvmrc
(24). build, dev and docker depend on make check-toolchain, so a wrong Go
or Node, or a rewritten go.mod pin, stops the build before any work with
found/required/fix. CI and release run it after setup-go/setup-node.

Align with the standard: toolchain go1.27.2 in go.mod, builder
golang:1.27.2-alpine3.24, runtime alpine:3.24. README notes the check.

ash requested review from eva

2026-10-24 08:07:42 +00:00

ash changed target branch from master to develop

2026-10-24 08:08:48 +00:00

eva approved these changes

2026-10-24 08:09:57 +00:00

eva left a comment

GO. This does what #10 asks and nothing more.

scripts/check-toolchain.sh is byte-for-byte the forge-standards copy.
build, dev and docker run the check first, and it runs before clean, so a mismatch leaves the tree alone. run picks it up through dev.
CI and release both run the preflight after setup-go and setup-node, and CI is green on 3c82757 with that step in it.
go.mod gets toolchain go1.27.2, .nvmrc is 24, and the Dockerfile moves to golang:1.27.2-alpine3.24 and alpine:3.24. The action majors weren't touched, which is right while vulture#17 pilots them.
The head sits right on the current base tip, so no rebase is needed.

One gap: make docker with the right toolchain wasn't run, because neither machine has Docker. The image tags are standard and it's a patch bump, so I'm fine landing without it. If it breaks, revert the merge.

This touches CI config, so it's on the normal merge path, not the low-risk one. Over to Linus.

GO. This does what #10 asks and nothing more. - `scripts/check-toolchain.sh` is byte-for-byte the forge-standards copy. - `build`, `dev` and `docker` run the check first, and it runs before `clean`, so a mismatch leaves the tree alone. `run` picks it up through `dev`. - CI and release both run the preflight after setup-go and setup-node, and CI is green on 3c82757 with that step in it. - go.mod gets `toolchain go1.27.2`, `.nvmrc` is 24, and the Dockerfile moves to `golang:1.27.2-alpine3.24` and `alpine:3.24`. The action majors weren't touched, which is right while vulture#17 pilots them. - The head sits right on the current base tip, so no rebase is needed. One gap: `make docker` with the right toolchain wasn't run, because neither machine has Docker. The image tags are standard and it's a patch bump, so I'm fine landing without it. If it breaks, revert the merge. This touches CI config, so it's on the normal merge path, not the low-risk one. Over to Linus.

blake approved these changes

2026-10-24 08:11:16 +00:00

blake left a comment

Blake security/CI gate: APPROVE on 3c827577de (base develop 1a51a12).

Checked:

Workflows: the only change is a sh scripts/check-toolchain.sh step after setup-go/setup-node in ci (both jobs) and release. Triggers are unchanged (ci/fmt on push/pull_request; release on tags + dispatch), with no pull_request_target, no permissions change, no new secrets, actions or ${{ }} in run:. The registry secrets stay in the tag/dispatch-only release docker job.
Script is byte-identical (blob efeeb0e) to the one approved on wls#21, SwipedCommissions#16 and Paste#12. No network; exit 1 with found/required/fix.
Node 24 is consistent: the new .nvmrc = 24, setup-node@v4 node-version: "24" in ci and release, and Alpine 3.24's nodejs package (used by the Docker builder) is 24.22.1. package.json has no engines field (optional).
npm: npm ci from package-lock.json everywhere (CI, release, Dockerfile). The lockfile is unchanged and package.json has no pre/postinstall scripts. The only install script in the lock is fsevents (dev, macOS-only, pre-existing). No curl|sh.
Go: toolchain go1.27.2 is a real release. golang:1.27.2-alpine3.24 and alpine:3.24 exist on Docker Hub.
Dockerfile: only the two base tags changed. Still USER scratchbox (system user), EXPOSE 8080 only, no new caps.

Non-blocking:

make docker wasn't exercised here either: the jumpbox has no docker/podman. No PR CI job builds the image (only the release workflow does), so the base-tag bump is first built at the next tag. If you want a local proof, route a docker build to Jerry/Dockge.
make docker runs the host preflight, but the image builds with its own pinned golang image and Alpine's nodejs, so the host check doesn't govern the image. That's fine, since the image pins match.
Pre-existing: actions are pinned to tags, not SHAs.

Blake security/CI gate: **APPROVE on 3c827577de** (base develop 1a51a12). Checked: - Workflows: the only change is a `sh scripts/check-toolchain.sh` step after setup-go/setup-node in ci (both jobs) and release. Triggers are unchanged (ci/fmt on push/pull_request; release on tags + dispatch), with no pull_request_target, no permissions change, no new secrets, actions or `${{ }}` in run:. The registry secrets stay in the tag/dispatch-only release docker job. - Script is byte-identical (blob efeeb0e) to the one approved on wls#21, SwipedCommissions#16 and Paste#12. No network; exit 1 with found/required/fix. - Node 24 is consistent: the new `.nvmrc` = 24, setup-node@v4 `node-version: "24"` in ci and release, and Alpine 3.24's `nodejs` package (used by the Docker builder) is 24.22.1. package.json has no engines field (optional). - npm: `npm ci` from package-lock.json everywhere (CI, release, Dockerfile). The lockfile is unchanged and package.json has no pre/postinstall scripts. The only install script in the lock is fsevents (dev, macOS-only, pre-existing). No curl|sh. - Go: `toolchain go1.27.2` is a real release. golang:1.27.2-alpine3.24 and alpine:3.24 exist on Docker Hub. - Dockerfile: only the two base tags changed. Still `USER scratchbox` (system user), EXPOSE 8080 only, no new caps. Non-blocking: 1. `make docker` wasn't exercised here either: the jumpbox has no docker/podman. No PR CI job builds the image (only the release workflow does), so the base-tag bump is first built at the next tag. If you want a local proof, route a `docker build` to Jerry/Dockge. 2. `make docker` runs the host preflight, but the image builds with its own pinned golang image and Alpine's nodejs, so the host check doesn't govern the image. That's fine, since the image pins match. 3. Pre-existing: actions are pinned to tags, not SHAs.