Dev image: Debian's apt layer runs again on every push to main, not once a day #1139

New issue

Closed

opened 2026-10-31 03:04:18 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-31 03:04:18 +00:00

Owner

What exists today

docker/Dockerfile:266-285: ARG POSTULO_APT_REFRESH sits right before the runtime stage's one apt layer (apt-get update, upgrade, the Pango and font packages, the PostgreSQL client), so any new value reruns that layer. .forgejo/workflows/dev-image.yml:127-129 sets the value to date -u +%Y-%m-%dT%H:%M:%SZ, a new one each run, and passes it to both builds (:138, :161). image.yml does the same for releases.

Correction to the candidate: the per-run value does not cost "every later layer". The ARG is declared in the runtime stage only, so the styles and build stages are untouched, and the layers after the apt one (COPY --from=build, collectstatic, the pip removal, useradd) depend on the source and rerun on nearly every push anyway. The real extra cost is the apt layer itself: the network round trips plus fonts-noto-cjk and the rest unpacked, under QEMU for arm64, in two builders per run. The layer is already placed as early as it can be.

Not measured locally (no Docker here); the 282 s is #1033's measurement of the arm64 layer, which #1033 lists without proposing a change, so this is not covered there.

What would change

In dev-image.yml only, make the moment a day: date -u +%Y-%m-%d. The first dev image of a UTC day asks Debian; later ones that day reuse the cached layer in both builders (the docker-container builder postulo-dev keeps its cache between runs). A workflow_dispatch run could keep the full timestamp, so a rebuild by hand still asks again. image.yml, scan-image.sh and check-image.sh keep the per-run moment: a release is rare and should ask Debian when it is built. tests/test_image_build.py:490-516 checks for $(date -u and for both builds sharing the moment; both stay true. The Dockerfile comment at :248-265 and the workflow comment at :120-126 should say why the dev channel uses a day.

What it saves or protects

medium: the apt layer (282 s of arm64 under QEMU in run 1170, per #1033's table, plus its amd64 copy in both the scan build and the push build) skipped on every dev image after the first of the day; 4 to 6 dev images a day (#1033's counts for 18-21 October)

Accessibility

none

Decided by the maintainer (2026-10-31)

:dev push builds take Debian packages at day granularity; dispatch and releases fresh every run

Decisions

Day granularity for :dev? Recommended: yes, for push runs; keep the full timestamp for workflow_dispatch and for releases. #300's problem was a layer frozen for weeks; a day is well inside what that fix was for.

Found by the efficiency and reliability audit of 2026-10-30 (finding I3; index postulo/postulo#1108). Checked against main at daee30b15 (2026-10-30).

## What exists today `docker/Dockerfile:266-285`: `ARG POSTULO_APT_REFRESH` sits right before the runtime stage's one apt layer (`apt-get update`, `upgrade`, the Pango and font packages, the PostgreSQL client), so any new value reruns that layer. `.forgejo/workflows/dev-image.yml:127-129` sets the value to `date -u +%Y-%m-%dT%H:%M:%SZ`, a new one each run, and passes it to both builds (`:138`, `:161`). `image.yml` does the same for releases. Correction to the candidate: the per-run value does not cost "every later layer". The ARG is declared in the runtime stage only, so the `styles` and `build` stages are untouched, and the layers after the apt one (`COPY --from=build`, `collectstatic`, the pip removal, `useradd`) depend on the source and rerun on nearly every push anyway. The real extra cost is the apt layer itself: the network round trips plus `fonts-noto-cjk` and the rest unpacked, under QEMU for arm64, in two builders per run. The layer is already placed as early as it can be. Not measured locally (no Docker here); the 282 s is #1033's measurement of the arm64 layer, which #1033 lists without proposing a change, so this is not covered there. ## What would change In `dev-image.yml` only, make the moment a day: `date -u +%Y-%m-%d`. The first dev image of a UTC day asks Debian; later ones that day reuse the cached layer in both builders (the `docker-container` builder `postulo-dev` keeps its cache between runs). A `workflow_dispatch` run could keep the full timestamp, so a rebuild by hand still asks again. `image.yml`, `scan-image.sh` and `check-image.sh` keep the per-run moment: a release is rare and should ask Debian when it is built. `tests/test_image_build.py:490-516` checks for `$(date -u` and for both builds sharing the moment; both stay true. The Dockerfile comment at `:248-265` and the workflow comment at `:120-126` should say why the dev channel uses a day. ## What it saves or protects medium: the apt layer (282 s of arm64 under QEMU in run 1170, per #1033's table, plus its amd64 copy in both the scan build and the push build) skipped on every dev image after the first of the day; 4 to 6 dev images a day (#1033's counts for 18-21 October) ## Accessibility none ## Decided by the maintainer (2026-10-31) :dev push builds take Debian packages at day granularity; dispatch and releases fresh every run ## Decisions - **Day granularity for `:dev`?** Recommended: yes, for push runs; keep the full timestamp for `workflow_dispatch` and for releases. #300's problem was a layer frozen for weeks; a day is well inside what that fix was for. --- Found by the efficiency and reliability audit of 2026-10-30 (finding I3; index postulo/postulo#1108). Checked against `main` at `daee30b15` (2026-10-30).

tiagoagueda added this to the 0.6.0 milestone

2026-10-31 03:04:18 +00:00

tiagoagueda added the

performance

enhancement

labels

2026-10-31 03:04:18 +00:00

tiagoagueda referenced this issue

2026-10-31 03:04:41 +00:00

Efficiency and reliability audit of 2026-10-30: index #1108

tiagoagueda referenced this issue from a commit

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