Does the 60-second hard cap on make test include building the test phase?
Your ruling on #41 (2026-08-10) set it: "org wide. the hard cap is 60 for ci/green, but over 20s should be filed as an improvement bug." Tests then ran on the host, with Go's build cache. make test is now an uncached docker build --no-cache --target test, so it also compiles everything from scratch with -race and saves the image. In dnswatcher (sneak/dnswatcher#259) that takes about 63 s for the test step plus 25 s to save the image, while its slowest test package takes 11.4 s. Read literally, most Go repositories now fail the cap without a slow test.
Options:
The cap covers the test run (the time go test reports); building the test phase counts against the existing 5-minute Docker build limit.
The cap covers all of make test, build included. Most Go repositories with -race exceed it.
Raise the cap for the uncached build.
Recommendation: option 1. It keeps what the cap measured when you set it, fast tests, and the 5-minute limit already bounds the build. The policy text gets one sentence saying so.
Model: opus-5-5
Does the 60-second hard cap on `make test` include building the test phase?
Your ruling on https://git.eeqj.de/sneak/prompts/issues/41 (2026-08-10) set it: "org wide. the hard cap is 60 for ci/green, but over 20s should be filed as an improvement bug." Tests then ran on the host, with Go's build cache. `make test` is now an uncached `docker build --no-cache --target test`, so it also compiles everything from scratch with `-race` and saves the image. In `dnswatcher` (https://git.eeqj.de/sneak/dnswatcher/pulls/259) that takes about 63 s for the test step plus 25 s to save the image, while its slowest test package takes 11.4 s. Read literally, most Go repositories now fail the cap without a slow test.
Options:
1. The cap covers the test run (the time `go test` reports); building the test phase counts against the existing 5-minute Docker build limit.
2. The cap covers all of `make test`, build included. Most Go repositories with `-race` exceed it.
3. Raise the cap for the uncached build.
Recommendation: option 1. It keeps what the cap measured when you set it, fast tests, and the 5-minute limit already bounds the build. The policy text gets one sentence saying so.
Model: opus-5-5
sneak
was assigned by clawbot2026-10-06 04:30:29 +02:00
Same question for the 5-minute Docker build limit, from #112 (closed: Go build cache mounts are caching, which you ruled out on #40, and --no-cache empties them anyway). On bsfirehose, after its re-vendor, on the shared build host at a load of about 100–150: make test 158 s, script/cibuild 454 s. Every compiling step starts from an empty Go build cache, and script/cibuild runs lint and test twice. If option 1 is taken for the test cap, the 5-minute limit would bound these builds alone, and bsfirehose breaks it too.
Model: opus-5-5
Same question for the 5-minute Docker build limit, from https://git.eeqj.de/sneak/prompts/issues/112 (closed: Go build cache mounts are caching, which you ruled out on https://git.eeqj.de/sneak/prompts/issues/40, and `--no-cache` empties them anyway). On `bsfirehose`, after its re-vendor, on the shared build host at a load of about 100–150: `make test` 158 s, `script/cibuild` 454 s. Every compiling step starts from an empty Go build cache, and `script/cibuild` runs lint and test twice. If option 1 is taken for the test cap, the 5-minute limit would bound these builds alone, and `bsfirehose` breaks it too.
Model: opus-5-5
Restated with a second ruling that the question above leaves out. This replaces it.
Two of your rulings cannot both hold for larger Go repositories on this host:
#40 (2026-08-10): lint and test run as Docker build phases "using no caching".
#41 (2026-08-10): make test has a 60-second hard cap, org wide; and sneak/homoicon#895 (2026-09-02): homoicon's make check finishes in under 60 seconds on this host.
With no cache, every make test compiles the module and all its dependencies from scratch before a test runs. That alone puts make test at about three minutes in homoicon (sneak/homoicon#1505) and 158 s in bsfirehose. #123 saves about 16 s per build, which is not enough.
Which gives way?
No caching stays. The 60-second limits count only the time the tests take to run; compiling counts against the 5-minute build limit. homoicon's make check limit is read the same way.
The 60-second limits stay as written. The lint and test builds keep Go's compiled packages between runs; every lint and test step still runs every time and no test result is reused. This partly reverses the no-caching ruling.
Raise the limits.
Recommendation: 2. It is the only option that brings homoicon's make check back toward 60 seconds, which is what sneak/homoicon#895 asked for; #112 measured a test step at 8 s with the compiled packages kept against 127 s without. This changes the recommendation above.
Model: opus-5-5
Restated with a second ruling that the question above leaves out. This replaces it.
Two of your rulings cannot both hold for larger Go repositories on this host:
- https://git.eeqj.de/sneak/prompts/issues/40 (2026-08-10): lint and test run as Docker build phases "using no caching".
- https://git.eeqj.de/sneak/prompts/issues/41 (2026-08-10): `make test` has a 60-second hard cap, org wide; and https://git.eeqj.de/sneak/homoicon/issues/895 (2026-09-02): homoicon's `make check` finishes in under 60 seconds on this host.
With no cache, every `make test` compiles the module and all its dependencies from scratch before a test runs. That alone puts `make test` at about three minutes in homoicon (https://git.eeqj.de/sneak/homoicon/pulls/1505) and 158 s in bsfirehose. https://git.eeqj.de/sneak/prompts/issues/123 saves about 16 s per build, which is not enough.
Which gives way?
1. No caching stays. The 60-second limits count only the time the tests take to run; compiling counts against the 5-minute build limit. homoicon's `make check` limit is read the same way.
2. The 60-second limits stay as written. The lint and test builds keep Go's compiled packages between runs; every lint and test step still runs every time and no test result is reused. This partly reverses the no-caching ruling.
3. Raise the limits.
Recommendation: 2. It is the only option that brings homoicon's `make check` back toward 60 seconds, which is what https://git.eeqj.de/sneak/homoicon/issues/895 asked for; https://git.eeqj.de/sneak/prompts/issues/112 measured a test step at 8 s with the compiled packages kept against 127 s without. This changes the recommendation above.
Model: opus-5-5
Correction to the bsfirehose figures above: since sneak/bsfirehose#96 replaced its cgo SQLite driver, script/cibuild there takes 259 s, under the 5-minute limit, and make test 68 s, with its slowest test package at 3.6 s. Under option 1 it meets both limits.
Model: opus-5-5
Correction to the `bsfirehose` figures above: since https://git.eeqj.de/sneak/bsfirehose/issues/96 replaced its cgo SQLite driver, `script/cibuild` there takes 259 s, under the 5-minute limit, and `make test` 68 s, with its slowest test package at 3.6 s. Under option 1 it meets both limits.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Does the 60-second hard cap on
make testinclude building the test phase?Your ruling on #41 (2026-08-10) set it: "org wide. the hard cap is 60 for ci/green, but over 20s should be filed as an improvement bug." Tests then ran on the host, with Go's build cache.
make testis now an uncacheddocker build --no-cache --target test, so it also compiles everything from scratch with-raceand saves the image. Indnswatcher(sneak/dnswatcher#259) that takes about 63 s for the test step plus 25 s to save the image, while its slowest test package takes 11.4 s. Read literally, most Go repositories now fail the cap without a slow test.Options:
go testreports); building the test phase counts against the existing 5-minute Docker build limit.make test, build included. Most Go repositories with-raceexceed it.Recommendation: option 1. It keeps what the cap measured when you set it, fast tests, and the 5-minute limit already bounds the build. The policy text gets one sentence saying so.
Model: opus-5-5
Same question for the 5-minute Docker build limit, from #112 (closed: Go build cache mounts are caching, which you ruled out on #40, and
--no-cacheempties them anyway). Onbsfirehose, after its re-vendor, on the shared build host at a load of about 100–150:make test158 s,script/cibuild454 s. Every compiling step starts from an empty Go build cache, andscript/cibuildruns lint and test twice. If option 1 is taken for the test cap, the 5-minute limit would bound these builds alone, andbsfirehosebreaks it too.Model: opus-5-5
Restated with a second ruling that the question above leaves out. This replaces it.
Two of your rulings cannot both hold for larger Go repositories on this host:
make testhas a 60-second hard cap, org wide; and sneak/homoicon#895 (2026-09-02): homoicon'smake checkfinishes in under 60 seconds on this host.With no cache, every
make testcompiles the module and all its dependencies from scratch before a test runs. That alone putsmake testat about three minutes in homoicon (sneak/homoicon#1505) and 158 s in bsfirehose. #123 saves about 16 s per build, which is not enough.Which gives way?
make checklimit is read the same way.Recommendation: 2. It is the only option that brings homoicon's
make checkback toward 60 seconds, which is what sneak/homoicon#895 asked for; #112 measured a test step at 8 s with the compiled packages kept against 127 s without. This changes the recommendation above.Model: opus-5-5
Correction to the
bsfirehosefigures above: since sneak/bsfirehose#96 replaced its cgo SQLite driver,script/cibuildthere takes 259 s, under the 5-minute limit, andmake test68 s, with its slowest test package at 3.6 s. Under option 1 it meets both limits.Model: opus-5-5