CI: the weekly schedule runs the whole of CI to get a dependency audit and an ESCO check #1136

New issue

Closed

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

tiagoagueda commented

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

Owner

What exists today

.forgejo/workflows/ci.yml:46-49:

schedule:
  # The dependency audit below also runs weekly, so a vulnerability disclosed in a
  # library is noticed even in a week when nothing was pushed.
  - cron: "17 6 * * 1"

The trigger is workflow-wide, so the Monday run starts all five jobs. Two of them are why it exists: Security (:646) and the unit job's ESCO step, which skips its cache on a schedule (:270, if: github.event_name != 'schedule') so the download validates the API's shape weekly. SECURITY.md:42 relies on the weekly audit. Nothing in tests/ asserts the schedule. The release gate reads (push) statuses, not scheduled ones.

The cost is lower than the candidate said: #1033 puts a CI run at about 48 runner-minutes. It runs at 06:17 on a Monday, usually on a quiet host, so it delays little. What it buys beyond the audit is a full run of main in a week without pushes (date-dependent tests, an apt or PyPI change); with dozens of pushes to main a day, that week is rare.

Constraint on this runner: a job-level if: that is false fails the job rather than skipping it (ci.yml:22-25), so the scheduled run cannot skip the browser, Checks and PostgreSQL jobs with if: github.event_name != 'schedule'. Step-level if: on every step would leave three green jobs that did nothing, which reads as a lie in the status list.

What would change

A weekly.yml of its own with the cron, holding the Security job (moved or duplicated; it stays in ci.yml for pushes, since the release gate requires it) and one ESCO job: install uv, sync without the e2e group, manage.py fetch_esco --revision "$ESCO_REVISION" with no cache. The schedule: block and the :270 condition leave ci.yml. SECURITY.md:42 and the comment at :46-48 move with it. tests/test_release_tools.py and tests/test_tooling.py read the workflows and must still pass; the Security job's text should exist once (a shared step is not possible here, so a test that holds the two copies equal, as test_release_tools.py does for the unit legs).

What it saves or protects

small: about 50 runner-minutes a week (browser 29, unit 14, Checks 2.5, PostgreSQL 4, Security 1, from #1033's run 1169), not 1.5 runner-hours; the Every Python weekly run (about 28 more) is a separate question

Accessibility

none (the weekly browser run includes the axe walks; dropping it removes only a weekly repeat of what every push to main runs)

Decided by the maintainer (2026-10-31)

weekly.yml with the audit and the ESCO check only; the ci.yml schedule goes; Every Python's weekly run stays

Decisions

Keep a weekly full run of main? Recommended: no; move the audit and the ESCO check to weekly.yml. The full run tests nothing a push did not test within hours, except in idle weeks.
Every Python's weekly cron (every-python.yml:23-25, half an hour later): recommended to keep, since it is the only regular run of 3.12 and 3.13 now that issue branches no longer trigger it (see C10).

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

## What exists today `.forgejo/workflows/ci.yml:46-49`: ``` schedule: # The dependency audit below also runs weekly, so a vulnerability disclosed in a # library is noticed even in a week when nothing was pushed. - cron: "17 6 * * 1" ``` The trigger is workflow-wide, so the Monday run starts all five jobs. Two of them are why it exists: Security (`:646`) and the unit job's ESCO step, which skips its cache on a schedule (`:270`, `if: github.event_name != 'schedule'`) so the download validates the API's shape weekly. `SECURITY.md:42` relies on the weekly audit. Nothing in `tests/` asserts the schedule. The release gate reads `(push)` statuses, not scheduled ones. The cost is lower than the candidate said: #1033 puts a CI run at about 48 runner-minutes. It runs at 06:17 on a Monday, usually on a quiet host, so it delays little. What it buys beyond the audit is a full run of `main` in a week without pushes (date-dependent tests, an apt or PyPI change); with dozens of pushes to `main` a day, that week is rare. Constraint on this runner: a job-level `if:` that is false fails the job rather than skipping it (`ci.yml:22-25`), so the scheduled run cannot skip the browser, Checks and PostgreSQL jobs with `if: github.event_name != 'schedule'`. Step-level `if:` on every step would leave three green jobs that did nothing, which reads as a lie in the status list. ## What would change A `weekly.yml` of its own with the cron, holding the Security job (moved or duplicated; it stays in `ci.yml` for pushes, since the release gate requires it) and one ESCO job: install uv, sync without the e2e group, `manage.py fetch_esco --revision "$ESCO_REVISION"` with no cache. The `schedule:` block and the `:270` condition leave `ci.yml`. `SECURITY.md:42` and the comment at `:46-48` move with it. `tests/test_release_tools.py` and `tests/test_tooling.py` read the workflows and must still pass; the Security job's text should exist once (a shared step is not possible here, so a test that holds the two copies equal, as `test_release_tools.py` does for the unit legs). ## What it saves or protects small: about 50 runner-minutes a week (browser 29, unit 14, Checks 2.5, PostgreSQL 4, Security 1, from #1033's run 1169), not 1.5 runner-hours; the Every Python weekly run (about 28 more) is a separate question ## Accessibility none (the weekly browser run includes the axe walks; dropping it removes only a weekly repeat of what every push to `main` runs) ## Decided by the maintainer (2026-10-31) weekly.yml with the audit and the ESCO check only; the ci.yml schedule goes; Every Python's weekly run stays ## Decisions - **Keep a weekly full run of `main`?** Recommended: no; move the audit and the ESCO check to `weekly.yml`. The full run tests nothing a push did not test within hours, except in idle weeks. - **Every Python's weekly cron (`every-python.yml:23-25`, half an hour later):** recommended to keep, since it is the only regular run of 3.12 and 3.13 now that issue branches no longer trigger it (see C10). --- Found by the efficiency and reliability audit of 2026-10-30 (finding C7; 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:17 +00:00

tiagoagueda added the

performance

enhancement

labels

2026-10-31 03:04:17 +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 pull request that will close it,

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