Resolves#11. The frontend/root Dockerfile ran only RUN yarn build, so script/lint and script/fmt-check (prettier) never gated CI — only a broken build failed it. (script/cibuild's comment even claimed "the Dockerfile runs make check", which was false.) The backend Dockerfile.backend already runs make check; nothing covered the frontend's lint/fmt-check.
RUN yarn build -> RUN make check — which runs script/test (yarn build, producing dist/) then script/lint + script/fmt-check. dist/ is still produced in one build (no redundant rebuild); the final nginx runtime image is unchanged.
Verified via a fresh clone (a worktree's .git pointer breaks vite's git rev-parse, so builds must come from a real checkout — as CI's actions/checkout provides): positive docker build succeeds with in-image make check green; a negative test (a prettier-violating but build-valid file) makes the build fail at make check, confirming CI now goes red on a check regression, not just a broken build.
Left open for review (not merged).
Resolves #11. The frontend/root `Dockerfile` ran only `RUN yarn build`, so `script/lint` and `script/fmt-check` (prettier) never gated CI — only a broken build failed it. (`script/cibuild`'s comment even claimed "the Dockerfile runs make check", which was false.) The backend `Dockerfile.backend` already runs `make check`; nothing covered the frontend's lint/fmt-check.
Change (single file, `Dockerfile`):
- `apk add ... git` -> `apk add ... git make` (build stage needs `make`).
- `RUN yarn build` -> `RUN make check` — which runs `script/test` (`yarn build`, producing `dist/`) then `script/lint` + `script/fmt-check`. `dist/` is still produced in one build (no redundant rebuild); the final nginx runtime image is unchanged.
Verified via a fresh clone (a worktree's `.git` pointer breaks `vite`'s `git rev-parse`, so builds must come from a real checkout — as CI's `actions/checkout` provides): positive `docker build` succeeds with in-image `make check` green; a negative test (a prettier-violating but build-valid file) makes the build fail at `make check`, confirming CI now goes red on a check regression, not just a broken build.
Left open for review (not merged).
The frontend Dockerfile ran only yarn build, so the container build
failed only on a broken build, not on lint or fmt-check regressions --
while script/cibuild's comment already assumed the Dockerfile ran make
check. Install make in the build stage and run make check (test + lint
+ fmt-check) in place of the bare yarn build. Its test step is the
production yarn build, so dist/ is still produced in a single build with
no redundant rebuild, and CI now goes red on any check failure.
sneak
merged commit fbfe1df349 into main2026-08-07 17:46:37 +02:00
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.
Resolves #11. The frontend/root
Dockerfileran onlyRUN yarn build, soscript/lintandscript/fmt-check(prettier) never gated CI — only a broken build failed it. (script/cibuild's comment even claimed "the Dockerfile runs make check", which was false.) The backendDockerfile.backendalready runsmake check; nothing covered the frontend's lint/fmt-check.Change (single file,
Dockerfile):apk add ... git->apk add ... git make(build stage needsmake).RUN yarn build->RUN make check— which runsscript/test(yarn build, producingdist/) thenscript/lint+script/fmt-check.dist/is still produced in one build (no redundant rebuild); the final nginx runtime image is unchanged.Verified via a fresh clone (a worktree's
.gitpointer breaksvite'sgit rev-parse, so builds must come from a real checkout — as CI'sactions/checkoutprovides): positivedocker buildsucceeds with in-imagemake checkgreen; a negative test (a prettier-violating but build-valid file) makes the build fail atmake check, confirming CI now goes red on a check regression, not just a broken build.Left open for review (not merged).