Say which Dockerfile stages run script/bootstrap (closes #90) #97
@@ -21,6 +21,13 @@ fmt-check, and commit.
|
||||
|
||||
# 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 start from
|
||||
their pinned base images and install what those images lack either inline, as
|
||||
the canonical Go `Dockerfile` does for `git`, or by running
|
||||
`script/bootstrap`, as this repo's own `Dockerfile` does for its yarn
|
||||
packages. 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: Added a root `.gitattributes` that merges `TODO.md` with git's
|
||||
union merge (issue 98), so two branches that each add an entry at the top of
|
||||
Completed Steps merge without a conflict. Git now never reports a conflict in
|
||||
|
||||
@@ -124,8 +124,10 @@ are thin shims calling them. Model scripts:
|
||||
- [ ] `script/bootstrap` / `make bootstrap` — installs all dependencies,
|
||||
idempotently, assuming nothing (pkg manager detection nix/apt/brew/apk;
|
||||
node used if present, else pinned version via nvm from a hash-verified
|
||||
archive; pinned yarn via corepack); Dockerfile runs it instead of inline
|
||||
installs
|
||||
archive; pinned yarn via corepack); a non-server repo's development
|
||||
environment stage runs it instead of inline installs; a gate phase or the
|
||||
build stage installs what its base image lacks either inline or by running
|
||||
it
|
||||
- [ ] `script/setup` / `make setup` — readies a fresh clone: runs `bootstrap`,
|
||||
then `install-precommit`, plus repo-specific init
|
||||
- [ ] `script/test` / `make test` — `docker build --no-cache --target test .`,
|
||||
|
||||
@@ -104,10 +104,14 @@ style conventions are in separate documents:
|
||||
`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
|
||||
brings up a development environment; for server repos it is the runtime image.
|
||||
Dockerfiles install development prerequisites by running `script/bootstrap`
|
||||
rather than duplicating installs inline; COPY `script/` and the dependency
|
||||
manifests (`package.json` + `yarn.lock`, `go.mod` + `go.sum`, etc.) before
|
||||
running it.
|
||||
The gate phases and the build stage start from their pinned base images and
|
||||
install what those images lack either inline, as the canonical Go `Dockerfile`
|
||||
below does for `git`, or by running `script/bootstrap`, as the `prompts`
|
||||
repo's own `Dockerfile` does for its yarn packages. The development
|
||||
environment stage installs development prerequisites by running
|
||||
`script/bootstrap` rather than duplicating its installs inline. A stage that
|
||||
runs `script/bootstrap` COPYs `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
|
||||
no separate lint file. `script/lint` and `script/test` each build one phase
|
||||
|
||||
Reference in New Issue
Block a user