Postulo/postulo

Fork 0

CI has never passed: the dependency audit fails on Postulo itself #75

New issue

Closed

opened 2026-09-07 09:49:04 +00:00 by tiagoagueda · 1 comment

tiagoagueda commented

2026-09-07 09:49:04 +00:00

Owner

Observation

Found while auditing main. CI has never passed. Every one of the 38 runs since the
project moved into the postulo organisation is red, and the README carries a CI badge.

What is wrong

Two separate faults.

1. The dependency audit fails on Postulo itself

uv sync --locked --python 3.14 --all-groups
uv run --with pip-audit pip-audit --strict

uv sync installs Postulo as an editable package. pip-audit --strict fails on
anything it cannot look up, and Postulo is not on PyPI:

ERROR:pip_audit._cli:postulo: Dependency not found on PyPI and could not be audited: postulo (0.1.0)
exit 1

--skip-editable does not help; --strict still counts a skip as a failure.

The consequence is worse than a red badge. The README promises that "dependencies are
checked for known vulnerabilities on every run and on a schedule, so a fresh disclosure is
noticed without anyone having to remember to look". The audit stopped at the project and
never reported on the dependencies at all, and a real disclosure would have arrived as one
more red run among thirty-eight. (Checked by hand while auditing: Python and npm are both
clean right now. The promise was unkept, not violated.)

2. Nothing on a release branch is checked

on:
  push:
    branches: [main]

Work moved onto per-release branches when 0.2.0 closed. 0.3.0 has commits on it and
zero CI runs — the filter said main and the commits were going somewhere else.

The fix

Audit the lock file rather than the installed environment:

uv export --no-emit-project --all-groups --format requirements-txt --no-hashes \
  > /tmp/locked-requirements.txt
uv run --with pip-audit pip-audit --strict -r /tmp/locked-requirements.txt

--no-emit-project leaves Postulo out by construction, so --strict is kept: a
dependency that becomes unauditable still fails the build, which is the entire point of
it. This audits exactly what will be installed rather than an environment that also
contains the project. Verified locally: 80 pinned packages audited, exit 0.

And run on the release branches, not only main.

Not included

The plugin repositories are red too — 7 of the 10 repositories in the organisation,
everything except the two browser extensions and postulo-templates, which has no CI at
all. Their cause is different: postulo-helloworld's complete CI sequence — sync, ruff,
catalogue compile, pytest — passes locally, so the failure is environmental, most likely
the runner fetching git+https://source.tiagoagueda.com/postulo/postulo.git from inside
its container. That needs the job logs and is its own issue.

Classification

Bug. The build has been reporting failure regardless of the state of the code, which is the
same as reporting nothing.

## Observation Found while auditing `main`. **CI has never passed.** Every one of the 38 runs since the project moved into the `postulo` organisation is red, and the README carries a CI badge. ## What is wrong Two separate faults. ### 1. The dependency audit fails on Postulo itself ``` uv sync --locked --python 3.14 --all-groups uv run --with pip-audit pip-audit --strict ``` `uv sync` installs Postulo as an **editable** package. `pip-audit --strict` fails on anything it cannot look up, and Postulo is not on PyPI: ``` ERROR:pip_audit._cli:postulo: Dependency not found on PyPI and could not be audited: postulo (0.1.0) exit 1 ``` `--skip-editable` does not help; `--strict` still counts a skip as a failure. The consequence is worse than a red badge. The README promises that *"dependencies are checked for known vulnerabilities on every run and on a schedule, so a fresh disclosure is noticed without anyone having to remember to look"*. **The audit stopped at the project and never reported on the dependencies at all**, and a real disclosure would have arrived as one more red run among thirty-eight. (Checked by hand while auditing: Python and npm are both clean right now. The promise was unkept, not violated.) ### 2. Nothing on a release branch is checked ```yaml on: push: branches: [main] ``` Work moved onto per-release branches when 0.2.0 closed. `0.3.0` has commits on it and **zero CI runs** — the filter said `main` and the commits were going somewhere else. ## The fix Audit the **lock file** rather than the installed environment: ```sh uv export --no-emit-project --all-groups --format requirements-txt --no-hashes \ > /tmp/locked-requirements.txt uv run --with pip-audit pip-audit --strict -r /tmp/locked-requirements.txt ``` `--no-emit-project` leaves Postulo out by construction, so `--strict` is kept: a *dependency* that becomes unauditable still fails the build, which is the entire point of it. This audits exactly what will be installed rather than an environment that also contains the project. Verified locally: 80 pinned packages audited, exit 0. And run on the release branches, not only `main`. ## Not included The **plugin repositories are red too** — 7 of the 10 repositories in the organisation, everything except the two browser extensions and `postulo-templates`, which has no CI at all. Their cause is different: `postulo-helloworld`'s complete CI sequence — sync, ruff, catalogue compile, pytest — passes locally, so the failure is environmental, most likely the runner fetching `git+https://source.tiagoagueda.com/postulo/postulo.git` from inside its container. That needs the job logs and is its own issue. ## Classification Bug. The build has been reporting failure regardless of the state of the code, which is the same as reporting nothing.

tiagoagueda added this to the 0.3.0 milestone

2026-09-07 09:49:04 +00:00

tiagoagueda added the

security

tier

bug

labels

2026-09-07 09:49:04 +00:00

tiagoagueda referenced this issue from a commit

2026-09-07 09:51:02 +00:00

Audit the lock rather than the project, so CI can pass at all

tiagoagueda closed this issue

2026-09-07 09:51:02 +00:00

tiagoagueda referenced this issue

2026-09-07 10:08:17 +00:00

Two tests pass only on the machine they were written on #76

tiagoagueda commented

2026-09-07 10:08:18 +00:00

Author

Owner

Reopening in spirit rather than in state: the audit fix landed as 2a80712 and was correct, but it was not the only reason CI failed. Run 725 was still red afterwards. The rest is #76.

Reopening in spirit rather than in state: the audit fix landed as `2a80712` and was correct, but it was not the only reason CI failed. Run 725 was still red afterwards. The rest is #76.

tiagoagueda referenced this issue

2026-09-07 10:16:43 +00:00

The workflow audit asks GitHub about a repository Forgejo never fetches from GitHub #77

tiagoagueda referenced this issue from a commit

2026-09-07 10:27:00 +00:00

Take the continuous integration fixes onto 0.3.0

tiagoagueda referenced this issue

2026-09-07 11:44:15 +00:00

The release run never finishes: a job queued against a label no runner has #81

tiagoagueda modified the milestone from 0.3.0 to 0.2.0

2026-09-07 11:44:15 +00:00