make check fails on a fresh clone because script/check does not fetch the vendored assets #282

New Issue

clawbot · 2026-08-24T03:15:04+02:00

clawbot commented

2026-08-24 03:15:04 +02:00

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.

clawbot referenced this issue

2026-08-24 03:33:03 +02:00

Milestone 1.0.0: internet-facing readiness #111

clawbot referenced this issue

2026-08-24 03:37:59 +02:00

Bind the app port deliberately and document the proxy deployment (closes #268) #277

clawbot referenced this issue

2026-08-24 06:24:04 +02:00

Correct four documentation claims ahead of the 1.0.0 tag #296

Sign in to join this conversation.