Say which Dockerfile stages run script/bootstrap (closes #90)
check / check (push) Failing after 2s

The bullet in `prompts/REPO_POLICIES.md` that requires a `Dockerfile` said every Dockerfile installs its prerequisites by running `script/bootstrap`, while the canonical Go `Dockerfile` never runs it: its gate phases use their pinned images as they are and its build stage installs `git` inline.

The bullet now says the gate phases and the build stage take their tools from their pinned base images and install only what those images lack, and that the development environment stage, the final stage of a non-server repo, runs `script/bootstrap`. The new repo checklist says the same.

Model: opus-5-5
This commit is contained in:
2026-10-04 09:04:57 +00:00
parent c32b10e77f
commit 30e13d73bb
3 changed files with 14 additions and 6 deletions
+6
View File
@@ -21,6 +21,12 @@ fmt-check, and commit.
# Completed Steps # Completed Steps
- 2026-10-04: `REPO_POLICIES.md` now says which `Dockerfile` stages run
`script/bootstrap` (issue 90). The gate phases and the build stage take their
tools from their pinned base images and install only what those images lack,
as the canonical Go `Dockerfile` does. The development environment stage, the
final stage of a non-server repo, runs `script/bootstrap`. The new repo
checklist says the same.
- 2026-10-04: Fixed the server lifecycle example in - 2026-10-04: Fixed the server lifecycle example in
`prompts/GO_HTTP_SERVER_CONVENTIONS.md` (issue 86). Only fx handles SIGINT and `prompts/GO_HTTP_SERVER_CONVENTIONS.md` (issue 86). Only fx handles SIGINT and
SIGTERM, and `Run()` in `main` exits with the shutdown's exit code. A listen SIGTERM, and `Run()` in `main` exits with the shutdown's exit code. A listen
+2 -2
View File
@@ -119,8 +119,8 @@ are thin shims calling them. Model scripts:
- [ ] `script/bootstrap` / `make bootstrap` — installs all dependencies, - [ ] `script/bootstrap` / `make bootstrap` — installs all dependencies,
idempotently, assuming nothing (pkg manager detection nix/apt/brew/apk; idempotently, assuming nothing (pkg manager detection nix/apt/brew/apk;
node used if present, else pinned version via nvm from a hash-verified node used if present, else pinned version via nvm from a hash-verified
archive; pinned yarn via corepack); Dockerfile runs it instead of inline archive; pinned yarn via corepack); a non-server repo's development
installs environment stage runs it instead of inline installs
- [ ] `script/setup` / `make setup` — readies a fresh clone: runs `bootstrap`, - [ ] `script/setup` / `make setup` — readies a fresh clone: runs `bootstrap`,
then `install-precommit`, plus repo-specific init then `install-precommit`, plus repo-specific init
- [ ] `script/test` / `make test` — `docker build --no-cache --target test .`, - [ ] `script/test` / `make test` — `docker build --no-cache --target test .`,
+6 -4
View File
@@ -104,10 +104,12 @@ style conventions are in separate documents:
`lint` phase and a `test` phase, with the final stage depending on both so the `lint` phase and a `test` phase, with the final stage depending on both so the
image cannot be built unless they pass. For non-server repos the final stage image cannot be built unless they pass. For non-server repos the final stage
brings up a development environment; for server repos it is the runtime image. brings up a development environment; for server repos it is the runtime image.
Dockerfiles install development prerequisites by running `script/bootstrap` The gate phases and the build stage take their tools from their pinned base
rather than duplicating installs inline; COPY `script/` and the dependency images and install only what those images lack, as the canonical Go
manifests (`package.json` + `yarn.lock`, `go.mod` + `go.sum`, etc.) before `Dockerfile` below does. The development environment stage installs
running it. development prerequisites by running `script/bootstrap` rather than
duplicating its installs inline; COPY `script/` and the dependency manifests
(`package.json` + `yarn.lock`, `go.mod` + `go.sum`, etc.) before running it.
- **Linting and testing run in Docker, as phases of the `Dockerfile`.** There is - **Linting and testing run in Docker, as phases of the `Dockerfile`.** There is
no separate lint file. `script/lint` and `script/test` each build one phase no separate lint file. `script/lint` and `script/test` each build one phase