Dependencies workflow: the lock upgrade is checked on one Python with part of CI, and its pull request runs no CI #585

New issue

Closed

opened 2026-10-01 10:47:50 +00:00 by tiagoagueda · 1 comment

tiagoagueda commented

2026-10-01 10:47:50 +00:00

Owner

Found on 2026-09-29 in a read-only review of postulo at 95348908d, comparing .forgejo/workflows/dependencies.yml with the test job in .forgejo/workflows/ci.yml.

Related to #233.

Checked again on 2026-10-01 against main at 0a5cad587: still present. The CONTRIBUTING.md passage is now at CONTRIBUTING.md:289-293.

The monthly lock upgrade says it runs "the same checks the test job runs, minus the browser" and opens its pull request saying "the suite passed against the result". It runs a subset, on Python 3.14 only, and the pull request it opens never gets a CI run of its own, because it is pushed and opened with the workflow's automatic token. A lock that breaks a check it skipped looks green until it reaches main.

Where: .forgejo/workflows/dependencies.yml:68-82 (uv sync --locked --python 3.14 --no-group e2e, then ruff check, makemigrations --check, messages.py compile, pytest -n 2); dependencies.yml:84-132 (push and pull request with TOKEN: ${{ secrets.GITHUB_TOKEN }}); .forgejo/workflows/ci.yml:41-140 (the test job it claims to mirror); .pre-commit-config.yaml:44-46 (ruff-pre-commit at rev: v0.16.6); CONTRIBUTING.md:287-291.
What happens: compared with ci.yml's test job, the upgrade job skips:
- the 3.12 and 3.13 legs of the matrix;
- ruff format --check (ci.yml:93), although uv lock --upgrade moves ruff itself (ruff>=0.16 in the dev group);
- messages.py extract --check and messages.py check (ci.yml:104-105);
- fetch_esco (ci.yml:114), so tests/test_esco.py and the other ESCO tests skip;
- the deployment check and collectstatic (ci.yml:134-140);
- the PostgreSQL job (psycopg from the postgres extra is never installed), the security audit and the browser suite.
  The branch is then pushed and the pull request opened with the automatic token. Forgejo, like Gitea, ignores events whose doer is the Actions user (to avoid cycles), so neither the push to dependencies/YYYY-MM nor the pull_request event starts ci.yml, and the pull request shows no statuses at all.
Why it matters: a dependency that breaks only on 3.12, a ruff release with a new format style, or a psycopg or Playwright change is merged on the strength of "the suite passed", and main goes red on the next push. A new ruff in the lock also leaves the pre-commit hook pinned at v0.16.6, so contributors' hooks format differently from CI.
Fix: move ci.yml's test steps into a reusable workflow (or a script both call) and run it from the upgrade job over the same matrix, adding --extra postgres and the ESCO download; or, simpler, push the branch and open the pull request with a bot account's token (a repository secret) so ci.yml runs on it as on any other pull request, and say in the body that CI on the pull request is the check. Have the job fail, or bump .pre-commit-config.yaml in the same commit, when the locked ruff version differs from the hook's rev. Correct the comment at dependencies.yml:73-74 and the pull-request body to say what was run.

Done when

A pull request opened by the Dependencies workflow carries the statuses of every ci.yml job, or the upgrade job runs the same checks over the same Pythons; and a check (in the workflow or tests/test_tooling.py or similar) fails when the locked ruff and the pre-commit rev disagree.

Found on 2026-09-29 in a read-only review of postulo at 95348908d, comparing `.forgejo/workflows/dependencies.yml` with the test job in `.forgejo/workflows/ci.yml`. Related to #233. Checked again on 2026-10-01 against `main` at `0a5cad587`: still present. The `CONTRIBUTING.md` passage is now at `CONTRIBUTING.md:289-293`. The monthly lock upgrade says it runs "the same checks the test job runs, minus the browser" and opens its pull request saying "the suite passed against the result". It runs a subset, on Python 3.14 only, and the pull request it opens never gets a CI run of its own, because it is pushed and opened with the workflow's automatic token. A lock that breaks a check it skipped looks green until it reaches `main`. - **Where:** `.forgejo/workflows/dependencies.yml:68-82` (`uv sync --locked --python 3.14 --no-group e2e`, then `ruff check`, `makemigrations --check`, `messages.py compile`, `pytest -n 2`); `dependencies.yml:84-132` (push and pull request with `TOKEN: ${{ secrets.GITHUB_TOKEN }}`); `.forgejo/workflows/ci.yml:41-140` (the test job it claims to mirror); `.pre-commit-config.yaml:44-46` (`ruff-pre-commit` at `rev: v0.16.6`); `CONTRIBUTING.md:287-291`. - **What happens:** compared with ci.yml's test job, the upgrade job skips: - the 3.12 and 3.13 legs of the matrix; - `ruff format --check` (ci.yml:93), although `uv lock --upgrade` moves ruff itself (`ruff>=0.16` in the dev group); - `messages.py extract --check` and `messages.py check` (ci.yml:104-105); - `fetch_esco` (ci.yml:114), so `tests/test_esco.py` and the other ESCO tests skip; - the deployment check and `collectstatic` (ci.yml:134-140); - the PostgreSQL job (`psycopg` from the `postgres` extra is never installed), the security audit and the browser suite. The branch is then pushed and the pull request opened with the automatic token. Forgejo, like Gitea, ignores events whose doer is the Actions user (to avoid cycles), so neither the push to `dependencies/YYYY-MM` nor the `pull_request` event starts ci.yml, and the pull request shows no statuses at all. - **Why it matters:** a dependency that breaks only on 3.12, a ruff release with a new format style, or a psycopg or Playwright change is merged on the strength of "the suite passed", and `main` goes red on the next push. A new ruff in the lock also leaves the pre-commit hook pinned at v0.16.6, so contributors' hooks format differently from CI. - **Fix:** move ci.yml's test steps into a reusable workflow (or a script both call) and run it from the upgrade job over the same matrix, adding `--extra postgres` and the ESCO download; or, simpler, push the branch and open the pull request with a bot account's token (a repository secret) so ci.yml runs on it as on any other pull request, and say in the body that CI on the pull request is the check. Have the job fail, or bump `.pre-commit-config.yaml` in the same commit, when the locked ruff version differs from the hook's `rev`. Correct the comment at `dependencies.yml:73-74` and the pull-request body to say what was run. ## Done when - A pull request opened by the Dependencies workflow carries the statuses of every ci.yml job, or the upgrade job runs the same checks over the same Pythons; and a check (in the workflow or `tests/test_tooling.py` or similar) fails when the locked ruff and the pre-commit `rev` disagree.

tiagoagueda added this to the 0.6.0 milestone

2026-10-01 10:47:50 +00:00

tiagoagueda added the

enhancement

label

2026-10-01 10:47:50 +00:00

tiagoagueda referenced this issue from a commit

2026-10-06 03:03:42 +00:00

Run CI on the dependency upgrade pull request and keep ruff's pin in step

tiagoagueda commented

2026-10-06 09:32:11 +00:00

Author