why does the webhooker build download alpine js and then check its hash? it's tiny, vendor it in.
then:
vendor in the tgz in vendor/ in the root
and, told that Go treats a root vendor/ directory as its module vendor directory:
then don't do that. use 3p/
Today the image build runs script/fetch-assets, which downloads alpinejs-3.14.9.tgz from the npm registry, checks its sha256, extracts alpine.min.js, and checks that too; static/vendor.sha256 and static/vendor_test.go re-check the embedded bytes. This was added by #145, which read REPO_POLICIES.md's "No build artifacts in version control" as forbidding a committed third-party file. sneak's ruling above settles it for webhooker: the package tarball is committed. The policy is about this repo's own build output; a committed third-party package is a dependency, and committing it is not a finding.
Definition of done:
3p/alpinejs-3.14.9.tgz is committed at the repo root: the exact tarball the build downloads today (same sha256 as script/fetch-assets pins).
The build extracts the Alpine file from that tarball into the place go:embed reads it, from a make target that make build, make test and the Dockerfile all use, with no network access. The extracted file is not committed (it stays ignored).
script/fetch-assets, its Dockerfile step, static/vendor.sha256 and static/vendor_test.go are removed; nothing downloads or hash-checks the asset any more.
The README and any doc that describes fetching the asset are updated; the UI works as before.
Model: opus-5-5
sneak, 2026-09-29 in chat (verbatim):
> why does the webhooker build download alpine js and then check its hash? it's tiny, vendor it in.
then:
> vendor in the tgz in vendor/ in the root
and, told that Go treats a root `vendor/` directory as its module vendor directory:
> then don't do that. use 3p/
Today the image build runs `script/fetch-assets`, which downloads `alpinejs-3.14.9.tgz` from the npm registry, checks its sha256, extracts `alpine.min.js`, and checks that too; `static/vendor.sha256` and `static/vendor_test.go` re-check the embedded bytes. This was added by https://git.eeqj.de/sneak/webhooker/issues/145, which read REPO_POLICIES.md's "No build artifacts in version control" as forbidding a committed third-party file. sneak's ruling above settles it for webhooker: the package tarball is committed. The policy is about this repo's own build output; a committed third-party package is a dependency, and committing it is not a finding.
Definition of done:
- `3p/alpinejs-3.14.9.tgz` is committed at the repo root: the exact tarball the build downloads today (same sha256 as `script/fetch-assets` pins).
- The build extracts the Alpine file from that tarball into the place `go:embed` reads it, from a make target that `make build`, `make test` and the Dockerfile all use, with no network access. The extracted file is not committed (it stays ignored).
- `script/fetch-assets`, its Dockerfile step, `static/vendor.sha256` and `static/vendor_test.go` are removed; nothing downloads or hash-checks the asset any more.
- The README and any doc that describes fetching the asset are updated; the UI works as before.
Model: opus-5-5
clawbot
self-assigned this 2026-09-29 11:21:49 +02:00
clawbot
changed title from Commit Alpine.js to the repo instead of downloading it at build time to Commit the Alpine.js tarball in vendor/ instead of downloading it at build time2026-09-29 11:22:15 +02:00
Plan. The issue body is the brief; the tarball goes in 3p/ at the repo root, per the owner's correction. Points it leaves to the implementer:
The committed tarball: it must be byte-identical to the one script/fetch-assets pins today. Check its sha256 against ALPINE_TARBALL_SHA256 in that script before deleting the script, and say in the commit body that it matches.
Extraction: one make target that make build, make test, make check and the Dockerfile all use, including the lint stage if its //go:embed needs the file. It writes only the ignored static/js/alpine.min.js. That supersedes the reasoning recorded in #282, which kept make check from writing into static/. Update the README's Entrypoints paragraph from that issue, since make bootstrap is no longer needed before make check.
Go:3p/ is not special to Go, so GOFLAGS and the Go stages stay as they are. .golangci.yml is never modified.
The Dockerfile overlap:#340 changes the Dockerfile too. Whichever lands second rebases onto the other; conflicts are that worker's.
Reviews: committing the tarball is the owner's ruling and is not a finding.
Model: opus-5-5
Plan. The issue body is the brief; the tarball goes in `3p/` at the repo root, per the owner's correction. Points it leaves to the implementer:
- **The committed tarball:** it must be byte-identical to the one `script/fetch-assets` pins today. Check its sha256 against `ALPINE_TARBALL_SHA256` in that script before deleting the script, and say in the commit body that it matches.
- **Extraction:** one make target that `make build`, `make test`, `make check` and the `Dockerfile` all use, including the lint stage if its `//go:embed` needs the file. It writes only the ignored `static/js/alpine.min.js`. That supersedes the reasoning recorded in https://git.eeqj.de/sneak/webhooker/issues/282, which kept `make check` from writing into `static/`. Update the README's Entrypoints paragraph from that issue, since `make bootstrap` is no longer needed before `make check`.
- **Go:** `3p/` is not special to Go, so `GOFLAGS` and the Go stages stay as they are. `.golangci.yml` is never modified.
- **The `Dockerfile` overlap:** https://git.eeqj.de/sneak/webhooker/issues/340 changes the `Dockerfile` too. Whichever lands second rebases onto the other; conflicts are that worker's.
- **Reviews:** committing the tarball is the owner's ruling and is not a finding.
Model: opus-5-5
clawbot
changed title from Commit the Alpine.js tarball in vendor/ instead of downloading it at build time to Commit the Alpine.js tarball in 3p/ instead of downloading it at build time2026-09-29 11:23:00 +02:00
Done in #351: the Alpine.js tarball is committed as 3p/alpinejs-3.14.9.tgz, byte for byte the one script/fetch-assets pinned. make assets extracts the browser build from it into the ignored static/js/alpine.min.js, and make test, make check, make build and make dev run it first, so the Dockerfile gets it through make test and make build. The fetch script, its manifest and its test are gone, and the README is updated.
Judgement call: the pre-commit hook runs script/check directly, so on a clone where none of those targets has run yet, it fails until make assets runs.
Model: opus-5-5
Done in https://git.eeqj.de/sneak/webhooker/pulls/351: the Alpine.js tarball is committed as `3p/alpinejs-3.14.9.tgz`, byte for byte the one `script/fetch-assets` pinned. `make assets` extracts the browser build from it into the ignored `static/js/alpine.min.js`, and `make test`, `make check`, `make build` and `make dev` run it first, so the Dockerfile gets it through `make test` and `make build`. The fetch script, its manifest and its test are gone, and the README is updated.
Judgement call: the pre-commit hook runs `script/check` directly, so on a clone where none of those targets has run yet, it fails until `make assets` runs.
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.
sneak, 2026-09-29 in chat (verbatim):
then:
and, told that Go treats a root
vendor/directory as its module vendor directory:Today the image build runs
script/fetch-assets, which downloadsalpinejs-3.14.9.tgzfrom the npm registry, checks its sha256, extractsalpine.min.js, and checks that too;static/vendor.sha256andstatic/vendor_test.gore-check the embedded bytes. This was added by #145, which read REPO_POLICIES.md's "No build artifacts in version control" as forbidding a committed third-party file. sneak's ruling above settles it for webhooker: the package tarball is committed. The policy is about this repo's own build output; a committed third-party package is a dependency, and committing it is not a finding.Definition of done:
3p/alpinejs-3.14.9.tgzis committed at the repo root: the exact tarball the build downloads today (same sha256 asscript/fetch-assetspins).go:embedreads it, from a make target thatmake build,make testand the Dockerfile all use, with no network access. The extracted file is not committed (it stays ignored).script/fetch-assets, its Dockerfile step,static/vendor.sha256andstatic/vendor_test.goare removed; nothing downloads or hash-checks the asset any more.Model: opus-5-5
Commit Alpine.js to the repo instead of downloading it at build timeto Commit the Alpine.js tarball in vendor/ instead of downloading it at build timePlan. The issue body is the brief; the tarball goes in
3p/at the repo root, per the owner's correction. Points it leaves to the implementer:script/fetch-assetspins today. Check its sha256 againstALPINE_TARBALL_SHA256in that script before deleting the script, and say in the commit body that it matches.make build,make test,make checkand theDockerfileall use, including the lint stage if its//go:embedneeds the file. It writes only the ignoredstatic/js/alpine.min.js. That supersedes the reasoning recorded in #282, which keptmake checkfrom writing intostatic/. Update the README's Entrypoints paragraph from that issue, sincemake bootstrapis no longer needed beforemake check.3p/is not special to Go, soGOFLAGSand the Go stages stay as they are..golangci.ymlis never modified.Dockerfileoverlap: #340 changes theDockerfiletoo. Whichever lands second rebases onto the other; conflicts are that worker's.Model: opus-5-5
Commit the Alpine.js tarball in vendor/ instead of downloading it at build timeto Commit the Alpine.js tarball in 3p/ instead of downloading it at build timeDone in #351: the Alpine.js tarball is committed as
3p/alpinejs-3.14.9.tgz, byte for byte the onescript/fetch-assetspinned.make assetsextracts the browser build from it into the ignoredstatic/js/alpine.min.js, andmake test,make check,make buildandmake devrun it first, so the Dockerfile gets it throughmake testandmake build. The fetch script, its manifest and its test are gone, and the README is updated.Judgement call: the pre-commit hook runs
script/checkdirectly, so on a clone where none of those targets has run yet, it fails untilmake assetsruns.Model: opus-5-5