fix(ci): rebuild Go backends on linked pkg/ changes and on matrix entry edits

[localai-bot]

#10975 taught the backend matrix filter about shared build inputs but deliberately left two paths that still rebuild nothing. Both are closed here.

Gap 1: Go backends link pkg/, but pkg/ changes rebuilt nothing

Excluded from #10975 on the assumption that including pkg/ would fire a Go matrix on nearly every commit. The import analysis says otherwise.

go list -deps ./backend/go/... resolves to exactly six subtrees — pkg/audio, pkg/grpc (incl. base, grpcerrors, proto), pkg/httpclient, pkg/sound, pkg/store, pkg/utils — identical for GOOS/GOARCH in {linux,darwin} × {amd64,arm64}. That is 6 of 27 pkg/ subtrees; pkg/model, pkg/downloader, pkg/xio and the rest are core-server-only and never reach a backend binary.

Path	% of last 638 commits	Linux blast radius
all of pkg/	8.6%	199/417
the six linked subtrees	2.0%	199/417
scripts/build/ (accepted in #10975)	1.9%	176/417
root Makefile (rejected in #10975)	3.8%	n/a

Enumerating puts this at the same frequency as a rule #10975 already accepted at comparable radius, and below the one it rejected. The "199 images on every commit" concern is really "199 images on 1 commit in 50".

_test.go files are excluded (they never reach a binary — mirrors the existing *_test.sh carve-out), and Darwin's bespoke C++ builders that carry lang: go only for runner selection are correctly skipped.

Measured: 199/417 Linux, 26/56 Darwin. Unlinked subtrees and _test.go: 0/417, 0/56.

Gap 2: editing an existing matrix entry rebuilt nothing

.github/backend-matrix.yml was excluded wholesale because matching its path would rebuild all 417 entries on every new-backend PR. That hid a real hole: changing an entry's base-image, build-type or CUDA version changes the image it produces while touching no file the prefix match can see.

The change is within a structured file, so the filter now compares it against the base revision and rebuilds only the entries whose fields differ. Entries are keyed on (tag-suffix, platform-tag) — verified unique across all 417 Linux and 56 Darwin entries — and fingerprinted order-independently, so reindenting or reordering compares equal.

Scenario	Linux	Darwin
One entry's base-image edited	1/417	0/56
One Darwin entry edited	0/417	1/56
6 new vllm entries added	6/417	0/56
Comment/whitespace-only edit	0/417	0/56
Entry removed	0/417	0/56
Base revision unresolvable	417/417	56/56

changed-backends.js fetches the base revision via the contents API, and only when the changed-file list names the matrix file, so the common path costs no extra request. The filter itself stays pure. An unresolvable base revision rebuilds everything rather than claiming nothing changed — that is precisely the #10946 failure mode this family of fixes exists to prevent.

This also closes a third hole neither gap described: adding a new matrix entry for an existing backend (a new CUDA variant of vllm, say) touches nothing under that backend's directory and previously rebuilt nothing. It now rebuilds exactly the new entries.

Tests

13 new cases in scripts/lib/backend-filter_test.mjs (node --test, zero deps, run by make test-ci-scripts from the build-scripts job).

Red-first: 8 fail before the change — exactly the new positive triggers. The 5 negative pins (unlinked pkg/ subtree, _test.go, no-op matrix edit, entry removal, previous-ignored-when-file-unchanged) pass both before and after, which is what proves the new triggers are not over-broad — the same property that validated #10975.

Final: 28/28 pass. make lint: 0 issues.

---

🤖 Generated with Claude Code