0.6.0 fixes, bunch 2: the image and the repository #1224

Merged

tiagoagueda merged 5 commits from b2-image into main

2026-11-10 12:10:41 +00:00

tiagoagueda commented

2026-11-10 11:31:09 +00:00

Owner

Bunch 2 of the 0.6.0 fixes: the image and the repository. One signed commit per issue; merge fast-forward-only so each keeps its own.

Closes #1161: git ignores the GeoNames lookup databases a checkout builds.
Closes #1141: .dockerignore leaves the downloaded datasets and bytecode out at any depth.
Closes #1139: a pushed dev image asks Debian once a day; by hand and for a release, every time.
Closes #1140: README.md out of the dependency layer, and a BuildKit cache mount instead of --no-cache.
Closes #1143: both image workflows start the scanned image and wait for it to be healthy before the push; check-image.sh --start-only, and no GeoNames download inside the check.

Tested locally: lint, migration and catalogue checks, the full unit suite (21,216 passed), zizmor, bash -n on the script. Not built: there is no Docker on the machine this was written on, and this pull request's CI does not build the image. The first dev image after the merge is the build that proves #1139, #1140 and #1143; a failed build publishes nothing.

#1142 (the stylesheet stage) is left for the change that moves that stage to the build platform (#1033 item 4), as the issue recommends.

🤖 Generated with Claude Code

Bunch 2 of the 0.6.0 fixes: the image and the repository. One signed commit per issue; merge fast-forward-only so each keeps its own. - Closes #1161: git ignores the GeoNames lookup databases a checkout builds. - Closes #1141: `.dockerignore` leaves the downloaded datasets and bytecode out at any depth. - Closes #1139: a pushed dev image asks Debian once a day; by hand and for a release, every time. - Closes #1140: README.md out of the dependency layer, and a BuildKit cache mount instead of `--no-cache`. - Closes #1143: both image workflows start the scanned image and wait for it to be healthy before the push; `check-image.sh --start-only`, and no GeoNames download inside the check. Tested locally: lint, migration and catalogue checks, the full unit suite (21,216 passed), zizmor, `bash -n` on the script. **Not built:** there is no Docker on the machine this was written on, and this pull request's CI does not build the image. The first dev image after the merge is the build that proves #1139, #1140 and #1143; a failed build publishes nothing. #1142 (the stylesheet stage) is left for the change that moves that stage to the build platform (#1033 item 4), as the issue recommends. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

tiagoagueda added 5 commits

2026-11-10 11:31:09 +00:00

Ignore the GeoNames lookup databases aa8be37f09

`manage.py fetch_geonames` builds SQLite lookups beside the text tables it
downloads, and .gitignore named the tables only. A checkout that had fetched
the data showed a 30 MB untracked file, and the recipes here use `git add -A`.

The databases, their journal files and the half-written `.tmp` files are
ignored now. A test asks git about every file the two fetch commands write,
and checks the three committed files there stay visible.

Closes #1161

Co-Authored-By: Claude <noreply@anthropic.com>

Leave the downloads and bytecode out of a locally built image d8d4bfe20a

A .dockerignore pattern is matched against the path from the context root,
so `data`, `__pycache__` and `*.py[cod]` left out those names at the root
and nowhere else. An image built from a working tree that had run the app
(compose.build.yml, scripts/check-image.sh) was sent, and through `COPY src`
shipped, 71 MB of ESCO and GeoNames downloads and every bytecode directory
under src. Published images come from a clean checkout and were unaffected.

The any-depth names are written `**/`, and the downloaded files are named by
path, leaving the committed licence notes and NACE table in. A test holds the
file to both, with a matcher that is itself checked against the old patterns.

Closes #1141

Co-Authored-By: Claude <noreply@anthropic.com>

Ask Debian once a day for a pushed dev image ca3f5b0478

The moment a build asks Debian for updates is the cache key of the image's
apt layer. The dev image workflow passed it to the second, so every push to
main ran that layer again in both builders, 282 s for arm64 under emulation
plus its amd64 copy, for packages that had not changed since the morning.

A dev image built by a push now passes the day: the first of a UTC day asks,
the rest reuse the layer. One started by hand still asks at once, and so does
every release, as the maintainer decided.

Closes #1139

Co-Authored-By: Claude <noreply@anthropic.com>

Keep README changes and repeat downloads out of the image's dependency layer 5a04c8a5f3

The Dockerfile copied README.md in before the first `uv sync`, so it was part
of the dependency layer's cache key: 11 of the 33 commits that rebuilt that
layer in a month had changed nothing but the README, whose language tables
are rewritten whenever translations land. Only the project's own build reads
it, so it is copied in before the second sync instead.

Both syncs, and the optional extra-package install, ran with `--no-cache`,
from the days the build stage shipped. They now use a BuildKit cache mount:
the cache stays in the builder's storage, in no layer, and a changed lock is
mostly a local copy. As decided by the maintainer, in one change.

Not built here (no Docker on this machine): the first dev image after the
merge is the build that proves it.

Closes #1140

Co-Authored-By: Claude <noreply@anthropic.com>

Start an image before publishing it, without waiting on GeoNames

CI / Unit tests and coverage (Python 3.14) (pull_request) Successful in 19m42s

Details

CI / Checks: lint, migrations, catalogues, settings, built files (pull_request) Successful in 1m43s

Details

CI / Database tests on PostgreSQL (pull_request) Successful in 4m6s

Details

CI / Security audit (pull_request) Successful in 25s

Details

CI / Browser tests (Chromium) (pull_request) Successful in 38m58s

Details

CI / Unit tests and coverage (Python 3.14) (push) Successful in 15m56s

Details

CI / Checks: lint, migrations, catalogues, settings, built files (push) Successful in 1m47s

Details

CI / Database tests on PostgreSQL (push) Successful in 4m10s

Details

CI / Security audit (push) Successful in 24s

Details

CI / Browser tests (Chromium) (push) Successful in 34m21s

Details

Dev image / Dev image: build, scan, push (push) Successful in 48m26s

Details

c40e870d7e

Neither image workflow ever ran a container: an image that built and scanned
clean but could not start (an entrypoint, a settings check, a migration on an
empty volume) was first found on the instance that follows its tag.

scripts/check-image.sh gains `--start-only`, which starts an existing tag as
a deployment runs it and waits for Docker's own health check: no build, no
compose file and no published port, since a workflow's job is a container
and cannot ask a port on the host. Both workflows run it on the image they
scanned, before the push. Its containers are named per process, so a dev
image and a release cannot remove each other's.

Both of the script's containers now set POSTULO_SKIP_GEONAMES, so a slow
GeoNames mirror no longer fails an image check.

Not run here (no Docker on this machine): the first dev image after the
merge exercises it.

Closes #1143

Co-Authored-By: Claude <noreply@anthropic.com>

tiagoagueda merged commit c40e870d7e into main

2026-11-10 12:10:41 +00:00

tiagoagueda deleted branch b2-image

2026-11-10 12:10:43 +00:00