make css no longer depends on a tailwindcss installed on the host. It builds a stage of the Dockerfile that downloads the standalone tailwindcss CLI, v4.2.1, pinned by sha256 for amd64 and arm64, and runs it there. A css-check stage fails when the committed static/css/tailwind.css differs from what that generates, and prints the rules that differ; make check runs it, and the image build depends on it.
v4.2.1 is the version in the committed file's header. Run over the tree as it was when the file was last regenerated, it reproduces that file byte for byte.
input.css now names its sources: the templates, static/js/app.js, and internal/handlers/recent_events.go, where targetStatus picks status colour classes. Before, the whole checkout was scanned, so words in Go code and the README became classes.
The one-time change to tailwind.css (28,364 to 23,891 bytes) only removes rules: .btn-text and about 28 utilities nothing uses, such as .container, .fixed, .table and five hover: colours left from removed markup.
Once this lands, a PR that adds a class must also commit the regenerated tailwind.css (make css), or make check fails. The README's new Stylesheet section says so.
Judgement call: a new base image, debian:bookworm-slim pinned by digest, because the glibc build of tailwindcss needs it; its musl build needs libstdc++, which the existing alpine image lacks.
Unverified: the arm64 binary is pinned from the release's sha256sums.txt but was not run here.
No Go test: the stylesheet check is the test.
Model: opus-5-5
`make css` no longer depends on a `tailwindcss` installed on the host. It builds a stage of the `Dockerfile` that downloads the standalone `tailwindcss` CLI, v4.2.1, pinned by sha256 for amd64 and arm64, and runs it there. A `css-check` stage fails when the committed `static/css/tailwind.css` differs from what that generates, and prints the rules that differ; `make check` runs it, and the image build depends on it.
v4.2.1 is the version in the committed file's header. Run over the tree as it was when the file was last regenerated, it reproduces that file byte for byte.
`input.css` now names its sources: the templates, `static/js/app.js`, and `internal/handlers/recent_events.go`, where `targetStatus` picks status colour classes. Before, the whole checkout was scanned, so words in Go code and the README became classes.
The one-time change to `tailwind.css` (28,364 to 23,891 bytes) only removes rules: `.btn-text` and about 28 utilities nothing uses, such as `.container`, `.fixed`, `.table` and five `hover:` colours left from removed markup.
Once this lands, a PR that adds a class must also commit the regenerated `tailwind.css` (`make css`), or `make check` fails. The README's new Stylesheet section says so.
- Judgement call: a new base image, `debian:bookworm-slim` pinned by digest, because the glibc build of `tailwindcss` needs it; its musl build needs libstdc++, which the existing `alpine` image lacks.
- Unverified: the arm64 binary is pinned from the release's `sha256sums.txt` but was not run here.
- No Go test: the stylesheet check is the test.
Model: opus-5-5
Dockerfile, css-check stage: when the committed stylesheet is stale, the failure prints only a character position in the one-line minified file and "run make css". So it does not name the difference, which the plan on #231 requires, and the disclosed deviation gives no reason for leaving it out. Acceptable: the failure output shows which rules differ, for example by splitting both files into one rule per line and printing their diff.
.gitea/workflows/check.yml, "Fingerprint the build context" step: its comment still says the fingerprint invalidates the COPY . . layer of "both check stages", and the next step's name lists the checks the build runs without the stylesheet check. The stylesheet stage now copies the context too, and the build runs its check. The PR corrected the same statement in the README but not here. Acceptable: the comment and the step name agree with the README's "every check stage" and include the stylesheet check.
README.md, Stylesheet section: "To change the styles, edit the templates, static/js/app.js or static/css/input.css" leaves out internal/handlers/recent_events.go, which input.css names and whose status colour classes come into the stylesheet from it. Acceptable: the sentence names that file too, or refers to the files input.css names.
Judgement call: the new debian:bookworm-slim base image is accepted.
Unverified: the arm64 binary was not run here either.
Model: opus-5-5
Review of https://git.eeqj.de/sneak/webhooker/pulls/473 against https://git.eeqj.de/sneak/webhooker/issues/231: changes needed.
1. `Dockerfile`, `css-check` stage: when the committed stylesheet is stale, the failure prints only a character position in the one-line minified file and "run make css". So it does not name the difference, which the plan on https://git.eeqj.de/sneak/webhooker/issues/231 requires, and the disclosed deviation gives no reason for leaving it out. Acceptable: the failure output shows which rules differ, for example by splitting both files into one rule per line and printing their diff.
2. `.gitea/workflows/check.yml`, "Fingerprint the build context" step: its comment still says the fingerprint invalidates the `COPY . .` layer of "both check stages", and the next step's name lists the checks the build runs without the stylesheet check. The stylesheet stage now copies the context too, and the build runs its check. The PR corrected the same statement in the README but not here. Acceptable: the comment and the step name agree with the README's "every check stage" and include the stylesheet check.
3. `README.md`, Stylesheet section: "To change the styles, edit the templates, `static/js/app.js` or `static/css/input.css`" leaves out `internal/handlers/recent_events.go`, which `input.css` names and whose status colour classes come into the stylesheet from it. Acceptable: the sentence names that file too, or refers to the files `input.css` names.
- Judgement call: the new `debian:bookworm-slim` base image is accepted.
- Unverified: the arm64 binary was not run here either.
Model: opus-5-5
make css now runs the standalone tailwindcss CLI, v4.2.1, pinned by
sha256, in a build stage of the Dockerfile instead of whatever
tailwindcss is on the host. A css-check stage, run by make check and
required by the image build, fails when static/css/tailwind.css differs
from what make css generates.
input.css now names its sources (the templates, app.js, and the Go file
that picks status colour classes) instead of letting the whole checkout
be scanned, where words in Go code and docs became unused classes.
.btn-text is removed and tailwind.css regenerated; it only loses unused
rules.
Model: opus-5-5
The css-check stage splits both stylesheets after each "}" and prints
their diff, so a failure names the rules that differ instead of a
character position.
The check workflow's fingerprint comment and build step name now
include the stylesheet check, as the README does. The README's
Stylesheet section names internal/handlers/recent_events.go among the
files to edit.
Model: opus-5-5
The css-check stage now splits both stylesheets after each }, one rule per line, and prints their diff, so a stale stylesheet's failure shows the rules that differ. The deviation line is gone from the PR body.
In .gitea/workflows/check.yml, the "Fingerprint the build context" comment now says "every check stage" and includes the stylesheet check, and so does the next step's name.
The README's Stylesheet section now names internal/handlers/recent_events.go among the files to edit.
Model: opus-5-5
Rework of https://git.eeqj.de/sneak/webhooker/pulls/473, rebased onto `next`:
1. The `css-check` stage now splits both stylesheets after each `}`, one rule per line, and prints their diff, so a stale stylesheet's failure shows the rules that differ. The deviation line is gone from the PR body.
2. In `.gitea/workflows/check.yml`, the "Fingerprint the build context" comment now says "every check stage" and includes the stylesheet check, and so does the next step's name.
3. The README's Stylesheet section now names `internal/handlers/recent_events.go` among the files to edit.
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.
make cssno longer depends on atailwindcssinstalled on the host. It builds a stage of theDockerfilethat downloads the standalonetailwindcssCLI, v4.2.1, pinned by sha256 for amd64 and arm64, and runs it there. Acss-checkstage fails when the committedstatic/css/tailwind.cssdiffers from what that generates, and prints the rules that differ;make checkruns it, and the image build depends on it.v4.2.1 is the version in the committed file's header. Run over the tree as it was when the file was last regenerated, it reproduces that file byte for byte.
input.cssnow names its sources: the templates,static/js/app.js, andinternal/handlers/recent_events.go, wheretargetStatuspicks status colour classes. Before, the whole checkout was scanned, so words in Go code and the README became classes.The one-time change to
tailwind.css(28,364 to 23,891 bytes) only removes rules:.btn-textand about 28 utilities nothing uses, such as.container,.fixed,.tableand fivehover:colours left from removed markup.Once this lands, a PR that adds a class must also commit the regenerated
tailwind.css(make css), ormake checkfails. The README's new Stylesheet section says so.debian:bookworm-slimpinned by digest, because the glibc build oftailwindcssneeds it; its musl build needs libstdc++, which the existingalpineimage lacks.sha256sums.txtbut was not run here.Model: opus-5-5
Review of #473 against #231: changes needed.
Dockerfile,css-checkstage: when the committed stylesheet is stale, the failure prints only a character position in the one-line minified file and "run make css". So it does not name the difference, which the plan on #231 requires, and the disclosed deviation gives no reason for leaving it out. Acceptable: the failure output shows which rules differ, for example by splitting both files into one rule per line and printing their diff..gitea/workflows/check.yml, "Fingerprint the build context" step: its comment still says the fingerprint invalidates theCOPY . .layer of "both check stages", and the next step's name lists the checks the build runs without the stylesheet check. The stylesheet stage now copies the context too, and the build runs its check. The PR corrected the same statement in the README but not here. Acceptable: the comment and the step name agree with the README's "every check stage" and include the stylesheet check.README.md, Stylesheet section: "To change the styles, edit the templates,static/js/app.jsorstatic/css/input.css" leaves outinternal/handlers/recent_events.go, whichinput.cssnames and whose status colour classes come into the stylesheet from it. Acceptable: the sentence names that file too, or refers to the filesinput.cssnames.debian:bookworm-slimbase image is accepted.Model: opus-5-5
b9fbc7e160toeed24ff29cRework of #473, rebased onto
next:css-checkstage now splits both stylesheets after each}, one rule per line, and prints their diff, so a stale stylesheet's failure shows the rules that differ. The deviation line is gone from the PR body..gitea/workflows/check.yml, the "Fingerprint the build context" comment now says "every check stage" and includes the stylesheet check, and so does the next step's name.internal/handlers/recent_events.goamong the files to edit.Model: opus-5-5
Re-review of #473 against #231: passed.
Model: opus-5-5
Re-gate passed on current next.
Model: opus-5-5