CI: the monthly dependency run's `propose` job has a job-level `if`, which this runner turns into a failure #1159

New issue

Closed

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

tiagoagueda commented

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

Owner

What exists today

.forgejo/workflows/dependencies.yml:127-130: propose has needs: upgrade and if: needs.upgrade.outputs.changed == 'true'. upgrade writes changed=false at :80 when uv lock --upgrade leaves the lock as it was, and its own later steps already guard with step-level if: (:91, :99, :112, :119), the pattern that works here. The repository records why job-level conditions are avoided: dev-image.yml:41-43 says "this runner fails a job whose if is false instead of skipping it (tried on a throwaway branch)", and #1033 repeats it as a rule.

Checked through the API (GET /repos/postulo/postulo/actions/tasks, all 119 pages, 5,883 tasks): dependencies.yml has one task ever, run 652 "Monthly dependency upgrade", scheduled 2026-10-03, status failure. That run predates the split: propose arrived in c35862ce5 on 2026-10-17 ("Hold the dependency bot's token in a job that runs nothing from the new packages"). So no run has yet shown the false-if failure; the claim rests on the runner behaviour the repository documents. The first run with the split is the cron at :34, 2026-11-03 05:23 UTC. Run 652's own failure (in the single job of that time) was not investigated here.

Correction to the candidate: whether that month goes red depends on whether the lock moves; in a month it does (the usual case) propose runs. The failure shows up only in a quiet month, which makes it rarer and more confusing when it comes.

What would change

Remove the job-level if from propose and put the same condition on each of its steps (if: needs.upgrade.outputs.changed == 'true'), as upgrade already does; or keep the job and make its first step exit 0 with a note in $GITHUB_STEP_SUMMARY when nothing changed, the rest guarded. tests/test_release_tools.py or whichever test reads the workflows can assert that no job in .forgejo/workflows/ has a job-level if other than the github.ref_name guard in dev-image.yml:69 (which is only false on a branch the trigger already excludes).

What it saves or protects

small (reliability): a month in which the lock does not move ends green instead of red, so a red monthly run keeps meaning something broke

Accessibility

none

Decisions

Before 2026-11-03? Recommended: yes if convenient, since that is the first run with the split; otherwise read that run's result when it comes.

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

## What exists today `.forgejo/workflows/dependencies.yml:127-130`: `propose` has `needs: upgrade` and `if: needs.upgrade.outputs.changed == 'true'`. `upgrade` writes `changed=false` at `:80` when `uv lock --upgrade` leaves the lock as it was, and its own later steps already guard with step-level `if:` (`:91`, `:99`, `:112`, `:119`), the pattern that works here. The repository records why job-level conditions are avoided: `dev-image.yml:41-43` says "this runner fails a job whose `if` is false instead of skipping it (tried on a throwaway branch)", and #1033 repeats it as a rule. Checked through the API (`GET /repos/postulo/postulo/actions/tasks`, all 119 pages, 5,883 tasks): `dependencies.yml` has one task ever, run 652 "Monthly dependency upgrade", scheduled 2026-10-03, status `failure`. That run predates the split: `propose` arrived in c35862ce5 on 2026-10-17 ("Hold the dependency bot's token in a job that runs nothing from the new packages"). So no run has yet shown the false-`if` failure; the claim rests on the runner behaviour the repository documents. The first run with the split is the cron at `:34`, 2026-11-03 05:23 UTC. Run 652's own failure (in the single job of that time) was not investigated here. Correction to the candidate: whether that month goes red depends on whether the lock moves; in a month it does (the usual case) `propose` runs. The failure shows up only in a quiet month, which makes it rarer and more confusing when it comes. ## What would change Remove the job-level `if` from `propose` and put the same condition on each of its steps (`if: needs.upgrade.outputs.changed == 'true'`), as `upgrade` already does; or keep the job and make its first step exit 0 with a note in `$GITHUB_STEP_SUMMARY` when nothing changed, the rest guarded. `tests/test_release_tools.py` or whichever test reads the workflows can assert that no job in `.forgejo/workflows/` has a job-level `if` other than the `github.ref_name` guard in `dev-image.yml:69` (which is only false on a branch the trigger already excludes). ## What it saves or protects small (reliability): a month in which the lock does not move ends green instead of red, so a red monthly run keeps meaning something broke ## Accessibility none ## Decisions - **Before 2026-11-03?** Recommended: yes if convenient, since that is the first run with the split; otherwise read that run's result when it comes. --- Found by the efficiency and reliability audit of 2026-10-30 (finding X1; 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:25 +00:00

tiagoagueda added the

performance

bug

labels

2026-10-31 03:04:25 +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