Compare commits
2
Commits
4928c6a890
...
f61b2084c7
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
f61b2084c7 | ||
|
|
5e5e7ea951 |
@@ -21,6 +21,24 @@ fmt-check, and commit.
|
|||||||
|
|
||||||
# Completed Steps
|
# Completed Steps
|
||||||
|
|
||||||
|
- 2026-10-04: Went through the fleet findings recorded on 2026-08-09 (issue 62)
|
||||||
|
and added the two rules `REPO_POLICIES.md` did not yet state: a new or changed
|
||||||
|
check is proven by planting a defect it must catch; and a change to a separate
|
||||||
|
workflow limited to `main` is first run from the feature branch, added to that
|
||||||
|
workflow's `branches` list and removed again before merging. The other
|
||||||
|
findings were already stated, replaced by `--no-cache`, about git worktrees,
|
||||||
|
or about how agents work together. The warning against
|
||||||
|
`golangci-lint config verify` is dropped because sneak ruled on
|
||||||
|
https://git.eeqj.de/sneak/prompts/issues/40 (2026-08-10) that there is no
|
||||||
|
config check step and the config is assumed valid; a vendored `.golangci.yml`
|
||||||
|
stays byte-identical to the canonical copy. The issue gives each reason.
|
||||||
|
- 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
|
- 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
|
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
|
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,
|
- [ ] `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; 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`,
|
- [ ] `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 .`,
|
||||||
|
|||||||
@@ -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
|
`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 start from their pinned base images and
|
||||||
rather than duplicating installs inline; COPY `script/` and the dependency
|
install what those images lack either inline, as the canonical Go `Dockerfile`
|
||||||
manifests (`package.json` + `yarn.lock`, `go.mod` + `go.sum`, etc.) before
|
below does for `git`, or by running `script/bootstrap`, as the `prompts`
|
||||||
running it.
|
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
|
- **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
|
||||||
@@ -156,6 +160,9 @@ style conventions are in separate documents:
|
|||||||
not evidence that anything ran: a sub-second build reporting success is a
|
not evidence that anything ran: a sub-second build reporting success is a
|
||||||
cache hit, not a result. Never invalidate by pruning — `docker builder prune`
|
cache hit, not a result. Never invalidate by pruning — `docker builder prune`
|
||||||
and friends destroy a build cache shared with every other build on the host.
|
and friends destroy a build cache shared with every other build on the host.
|
||||||
|
When a check is added or changed, prove it works by planting a defect it must
|
||||||
|
catch and watching the run fail on it, then revert the defect. A green run
|
||||||
|
alone shows neither that the check ran nor that it covers what it should.
|
||||||
|
|
||||||
- **The gate phases are separate stages, and the build stage depends on both.**
|
- **The gate phases are separate stages, and the build stage depends on both.**
|
||||||
The lint phase is based on the `golangci/golangci-lint` image (pinned by
|
The lint phase is based on the `golangci/golangci-lint` image (pinned by
|
||||||
@@ -279,7 +286,12 @@ style conventions are in separate documents:
|
|||||||
carry the same guarantee, because its gate phases may come from the cache. The
|
carry the same guarantee, because its gate phases may come from the cache. The
|
||||||
image build is uncached and so runs the gate phases a second time. That is the
|
image build is uncached and so runs the gate phases a second time. That is the
|
||||||
price of the rule above, and it is worth paying: the image that ships is built
|
price of the rule above, and it is worth paying: the image that ships is built
|
||||||
from a run of its own gates rather than from a cache entry.
|
from a run of its own gates rather than from a cache entry. A separate
|
||||||
|
workflow limited to `main` by a `branches` list under `on: push` cannot be
|
||||||
|
checked by review: to try a change to it, add the feature branch to that list
|
||||||
|
and push, then remove the branch from the list again before merging. Keep any
|
||||||
|
job in it that publishes behind `if: github.ref_name == 'main'`, so the run
|
||||||
|
from the feature branch publishes nothing.
|
||||||
|
|
||||||
- Use platform-standard formatters: `black` for Python, `prettier` for
|
- Use platform-standard formatters: `black` for Python, `prettier` for
|
||||||
JS/CSS/Markdown/HTML, `go fmt` for Go. Always use default configuration with
|
JS/CSS/Markdown/HTML, `go fmt` for Go. Always use default configuration with
|
||||||
|
|||||||
Reference in New Issue
Block a user