CI: build the dev image only from a commit CI passed

tiagoagueda commented

2026-10-04 20:43:12 +00:00

Owner

Measured from Forgejo's task API and job logs, runs 561–710 (24 Sep – 4 Oct 2026): wall time per push about 52–55 min, up from about 15; the browser suite grew from 149 to 645 tests in five days and runs serially (29 min); the runner takes two jobs at a time, in the order the workflow file lists them, so the browser job starts 19–22 min after the push; and Forgejo cancels the older push run when a newer push lands, which stopped 18 of 56 browser jobs before they gave a verdict.

dev-image.yml builds and publishes :dev on every push to main, at the same time as CI: 14–19 minutes of amd64+arm64 (the arm64 half under QEMU) on the same six-core host as the two CI slots. So the image competes with the tests for the processor, and an instance following :dev can be given a commit whose tests failed.

Decision (user, 2026-10-04)

The dev image becomes a job in ci.yml that needs: the test jobs, runs on docker, only for main (push or manual run), with contents: read and packages: write at job level. Its steps do not change. dev-image.yml goes; a rebuild without a commit is a manual run of CI on main.
The comment from #190 about why a push may reach the docker runner moves with it, rewritten for its new home. tests/test_image_build.py's list of workflows that build the image follows.
concurrency: dev-image goes too: Forgejo already cancels the older push run when a newer one lands, dev-image job included.

To check before relying on it

On postulo-firefox, a tag-only job with a job-level if and needs: was still handed to the runner on every branch push and ended in "Early termination" (2026-09-18, #251). This is tried on a throwaway branch first. If it misbehaves here, the fallback keeps dev-image.yml on push and gives it a first step that waits for the commit's CI result through the API and stops before building unless it passed.

Done when

A push whose CI fails publishes no dev image, and a passing one publishes it after the tests.

Measured from Forgejo's task API and job logs, runs 561–710 (24 Sep – 4 Oct 2026): wall time per push about 52–55 min, up from about 15; the browser suite grew from 149 to 645 tests in five days and runs serially (29 min); the runner takes **two jobs at a time, in the order the workflow file lists them**, so the browser job starts 19–22 min after the push; and Forgejo cancels the older push run when a newer push lands, which stopped 18 of 56 browser jobs before they gave a verdict. `dev-image.yml` builds and publishes `:dev` on every push to `main`, at the same time as CI: 14–19 minutes of amd64+arm64 (the arm64 half under QEMU) on the same six-core host as the two CI slots. So the image competes with the tests for the processor, and an instance following `:dev` can be given a commit whose tests failed. ## Decision (user, 2026-10-04) - The dev image becomes a job in `ci.yml` that `needs:` the test jobs, runs on `docker`, only for `main` (push or manual run), with `contents: read` and `packages: write` at job level. Its steps do not change. `dev-image.yml` goes; a rebuild without a commit is a manual run of CI on `main`. - The comment from #190 about why a push may reach the docker runner moves with it, rewritten for its new home. `tests/test_image_build.py`'s list of workflows that build the image follows. - `concurrency: dev-image` goes too: Forgejo already cancels the older push run when a newer one lands, dev-image job included. ## To check before relying on it On postulo-firefox, a tag-only job with a job-level `if` and `needs:` was still handed to the runner on every branch push and ended in "Early termination" (2026-09-18, #251). This is tried on a throwaway branch first. If it misbehaves here, the fallback keeps `dev-image.yml` on push and gives it a first step that waits for the commit's CI result through the API and stops before building unless it passed. ## Done when - A push whose CI fails publishes no dev image, and a passing one publishes it after the tests.

tiagoagueda added the

enhancement

label

2026-10-04 20:43:12 +00:00

tiagoagueda referenced this issue from a commit

2026-10-04 21:23:09 +00:00

Build the dev image only from a commit CI passed

tiagoagueda closed this issue

2026-10-04 21:23:09 +00:00

tiagoagueda commented

2026-10-04 21:23:55 +00:00

Author

Owner

Probed on a throwaway branch ci-probe (runs 715 and 716, deleted afterwards). The runner is forgejo-runner v6.4.0 against Forgejo 15:

a job-level if: that is false fails its job ("Early termination"), with or without needs:;
needs: works when the dependent job's if is true, across runners (ubuntu-latest → docker);
job-level timeout-minutes is ignored (a 1-minute job ran 2 m 30 s); step-level timeout-minutes works ("context deadline exceeded" at 1 m 0 s);
the server expands a matrix without any github context: fromJSON(github.ref == … && '[…]' || '[…]'), by ref, ref_name or event_name, always took the last branch.

Upgrading the runner may fix the first and third; that is a host change.

A dev-image job in ci.yml would need a job-level if for pull requests and release branches, so it stayed in dev-image.yml, whose first step is release_tools.py wait-ci $GITHUB_SHA: it waits for the push's own CI jobs (unit, browser, checks) and builds nothing unless all pass (b3cb4e7ba).

Probed on a throwaway branch `ci-probe` (runs 715 and 716, deleted afterwards). The runner is forgejo-runner **v6.4.0** against Forgejo 15: - a job-level `if:` that is false **fails** its job ("Early termination"), with or without `needs:`; - `needs:` works when the dependent job's `if` is true, across runners (ubuntu-latest → docker); - job-level `timeout-minutes` is **ignored** (a 1-minute job ran 2 m 30 s); step-level `timeout-minutes` works ("context deadline exceeded" at 1 m 0 s); - the server expands a matrix **without any `github` context**: `fromJSON(github.ref == … && '[…]' || '[…]')`, by `ref`, `ref_name` or `event_name`, always took the last branch. Upgrading the runner may fix the first and third; that is a host change. A dev-image job in `ci.yml` would need a job-level `if` for pull requests and release branches, so it stayed in `dev-image.yml`, whose first step is `release_tools.py wait-ci $GITHUB_SHA`: it waits for the push's own CI jobs (unit, browser, checks) and builds nothing unless all pass (`b3cb4e7ba`).

tiagoagueda referenced this issue from a commit

2026-10-05 01:52:24 +00:00

Keep waiting for CI through a failed lookup, not stop the dev image on it

tiagoagueda referenced this issue

2026-10-22 01:06:16 +00:00

CI: make a push report sooner and cost less, without new hardware #1033

Rows
Columns

CI: build the dev image only from a commit CI passed #716

Decision (user, 2026-10-04)

To check before relying on it

Done when