On a fresh clone, make check fails with two errors before it can do anything useful:
TestVendoredAssetsMatchManifest/js/alpine.min.js
js/alpine.min.js is listed in vendor.sha256 but is not embedded;
run `script/fetch-assets` (or `make assets`) to install the pinned
third-party assets
TestBaseTemplateScriptsAreServed//s/js/alpine.min.js
make bootstrap (or make assets) fixes it. The error message is excellent and names the exact remedy — this is not a mystery failure. But make check is the gate, and a gate that cannot run on a clean checkout of the repo is a papercut every newcomer pays.
Filing it because it has now caught three independent parties in a single session: a deployability audit lane, a PR reviewer, and the repo manager running a release gate — where it briefly looked like next had gone red. Each recovered within a minute, and each lost that minute.
The container build is unaffected: the Dockerfile fetches assets itself, which is why CI has never surfaced this.
Definition of done
Pick one and state why:
script/check ensures the vendored assets are present before running tests — either by invoking the fetch itself, or by depending on the target that does. This makes make check work on a clean clone, which is what a gate should do.
Or: make check deliberately requires make bootstrap first, and that is documented at the top of the README's Entrypoints section rather than discovered through a test failure.
The first is better unless there is a reason the gate must stay side-effect-free — if there is, the second is fine but the documentation is then mandatory, not optional.
Whichever is chosen, verify by executing it against a genuinely fresh git clone with no prior state.
Not milestoned: it costs a minute once, and the failure explains itself.
On a fresh clone, `make check` fails with two errors before it can do anything useful:
```
TestVendoredAssetsMatchManifest/js/alpine.min.js
js/alpine.min.js is listed in vendor.sha256 but is not embedded;
run `script/fetch-assets` (or `make assets`) to install the pinned
third-party assets
TestBaseTemplateScriptsAreServed//s/js/alpine.min.js
```
`make bootstrap` (or `make assets`) fixes it. The error message is excellent and names the exact remedy — this is not a mystery failure. But `make check` is the gate, and a gate that cannot run on a clean checkout of the repo is a papercut every newcomer pays.
Filing it because it has now caught three independent parties in a single session: a deployability audit lane, a PR reviewer, and the repo manager running a release gate — where it briefly looked like `next` had gone red. Each recovered within a minute, and each lost that minute.
The container build is unaffected: the `Dockerfile` fetches assets itself, which is why CI has never surfaced this.
## Definition of done
Pick one and state why:
- `script/check` ensures the vendored assets are present before running tests — either by invoking the fetch itself, or by depending on the target that does. This makes `make check` work on a clean clone, which is what a gate should do.
- Or: `make check` deliberately requires `make bootstrap` first, and that is documented at the top of the README's Entrypoints section rather than discovered through a test failure.
The first is better unless there is a reason the gate must stay side-effect-free — if there is, the second is fine but the documentation is then mandatory, not optional.
Whichever is chosen, verify by executing it against a genuinely fresh `git clone` with no prior state.
Not milestoned: it costs a minute once, and the failure explains itself.
Plan. Take the second option: make check keeps requiring the fetched assets, and the README says so at the top of its Entrypoints section.
Why: REPO_POLICIES.md says make check must not modify any files in the repo, and script/check states the same. script/fetch-assets writes into static/, so a gate that fetched would break that rule and would also need the network to run.
Add a short paragraph at the top of "Entrypoints": make check needs the pinned browser assets in static/, so run make bootstrap (or make assets) once after cloning. The gate does not fetch them itself, because it must not change files in the repo. The Quick Start already runs make bootstrap first; leave it as it is.
Docs only: no script or Makefile change.
Verify on a genuinely fresh git clone with no earlier state: make check alone fails with the test message that names the remedy, and make bootstrap followed by make check passes.
Model: opus-5-5
Plan. Take the second option: `make check` keeps requiring the fetched assets, and the README says so at the top of its Entrypoints section.
Why: `REPO_POLICIES.md` says `make check` must not modify any files in the repo, and `script/check` states the same. `script/fetch-assets` writes into `static/`, so a gate that fetched would break that rule and would also need the network to run.
- Add a short paragraph at the top of "Entrypoints": `make check` needs the pinned browser assets in `static/`, so run `make bootstrap` (or `make assets`) once after cloning. The gate does not fetch them itself, because it must not change files in the repo. The Quick Start already runs `make bootstrap` first; leave it as it is.
- Docs only: no script or Makefile change.
- Verify on a genuinely fresh `git clone` with no earlier state: `make check` alone fails with the test message that names the remedy, and `make bootstrap` followed by `make check` passes.
Model: opus-5-5
clawbot
self-assigned this 2026-09-29 03:13:51 +02:00
Done as planned in #326: the README's Entrypoints section now says to run make bootstrap (or make assets) once after cloning, before make check. Docs only.
Model: opus-5-5
Done as planned in https://git.eeqj.de/sneak/webhooker/pulls/326: the README's Entrypoints section now says to run `make bootstrap` (or `make assets`) once after cloning, before `make check`. Docs only.
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.
On a fresh clone,
make checkfails with two errors before it can do anything useful:make bootstrap(ormake assets) fixes it. The error message is excellent and names the exact remedy — this is not a mystery failure. Butmake checkis the gate, and a gate that cannot run on a clean checkout of the repo is a papercut every newcomer pays.Filing it because it has now caught three independent parties in a single session: a deployability audit lane, a PR reviewer, and the repo manager running a release gate — where it briefly looked like
nexthad gone red. Each recovered within a minute, and each lost that minute.The container build is unaffected: the
Dockerfilefetches assets itself, which is why CI has never surfaced this.Definition of done
Pick one and state why:
script/checkensures the vendored assets are present before running tests — either by invoking the fetch itself, or by depending on the target that does. This makesmake checkwork on a clean clone, which is what a gate should do.make checkdeliberately requiresmake bootstrapfirst, and that is documented at the top of the README's Entrypoints section rather than discovered through a test failure.The first is better unless there is a reason the gate must stay side-effect-free — if there is, the second is fine but the documentation is then mandatory, not optional.
Whichever is chosen, verify by executing it against a genuinely fresh
git clonewith no prior state.Not milestoned: it costs a minute once, and the failure explains itself.
Plan. Take the second option:
make checkkeeps requiring the fetched assets, and the README says so at the top of its Entrypoints section.Why:
REPO_POLICIES.mdsaysmake checkmust not modify any files in the repo, andscript/checkstates the same.script/fetch-assetswrites intostatic/, so a gate that fetched would break that rule and would also need the network to run.make checkneeds the pinned browser assets instatic/, so runmake bootstrap(ormake assets) once after cloning. The gate does not fetch them itself, because it must not change files in the repo. The Quick Start already runsmake bootstrapfirst; leave it as it is.git clonewith no earlier state:make checkalone fails with the test message that names the remedy, andmake bootstrapfollowed bymake checkpasses.Model: opus-5-5
Done as planned in #326: the README's Entrypoints section now says to run
make bootstrap(ormake assets) once after cloning, beforemake check. Docs only.Model: opus-5-5