CI: the job image has no node, so the checkout cannot run; the install is not --locked and only 3.14 is tested #8

New issue

Closed

opened 2026-10-01 10:48:02 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-01 10:48:02 +00:00

Owner

Found on 2026-09-29 in a read-only review of postulo-mcp at 0b29e70b9, comparing .forgejo/workflows/ci.yml with the workflows of the other repositories.

The workflow runs in python:3.14-slim-bookworm. Forgejo runs actions/checkout as JavaScript inside the job container, and that image has no node. That is the fault postulo/postulo-helloworld#2 and postulo/postulo-imap#1 described in their own repositories ("the checkout dies before any step"), fixed there by moving to node:22-bookworm; every other repository in the project, the core included, now uses that image, and postulo-mcp is the only one still on the Python image. On that evidence no lint or test in this repository is being run by CI. Two smaller gaps sit behind it and would show as soon as it runs.

Where: .forgejo/workflows/ci.yml:13-14 (the container image), .forgejo/workflows/ci.yml:26-27 (uv sync), pyproject.toml:6 (requires-python = ">=3.12"), pyproject.toml:46 (target-version = "py312")
What happens:
1. The image. actions/checkout@v4 needs node in the container; python:3.14-slim-bookworm has none, so the run stops at the first step. The apt-get install curl in the next step would be unnecessary on node:22-bookworm, which carries curl and git.
2. The install. uv sync without --locked re-resolves when pyproject.toml and uv.lock disagree, instead of failing. The server tracks the MCP SDK closely (mcp.server.mcpserver, mcp_types, the TokenVerifier and AuthSettings shapes), so a lower bound bumped without re-locking would be tested against a resolution nobody reviewed. Every other Python repository runs uv sync --locked --python 3.14 and says why in a comment (for example postulo-dav .forgejo/workflows/ci.yml:50-53).
3. The Python versions. The package declares >=3.12 and ruff targets py312, but the job tests one version. Unlike the plugins, which run inside the core's Python (and the core tests 3.12–3.14 in a matrix), this server is installed on its own with uv tool install under whatever Python the person has, so the versions it claims are the ones people run.
Why it matters: the README makes promises that only tests hold (#1 asks for more of them), and a CI that cannot start holds none of them. A red or absent run on every push also trains whoever reads it to ignore it.
Fix: run the job in node:22-bookworm with persist-credentials: false on the checkout, as the plugin repositories do; install with uv sync --locked; run the tests over a 3.12 / 3.13 / 3.14 matrix (uv sync --locked --python ${{ matrix.python-version }}), or raise requires-python to what is tested. Pinning the uv installer version (astral.sh/uv/${UV_VERSION}/install.sh, as the core does) is worth doing in the same change.

Done when

A push to main shows the CI run reaching and passing the lint and test steps on every listed Python version, and a deliberately stale uv.lock on a branch makes the install step fail.

Found on 2026-09-29 in a read-only review of postulo-mcp at 0b29e70b9, comparing `.forgejo/workflows/ci.yml` with the workflows of the other repositories. The workflow runs in `python:3.14-slim-bookworm`. Forgejo runs `actions/checkout` as JavaScript inside the job container, and that image has no `node`. That is the fault postulo/postulo-helloworld#2 and postulo/postulo-imap#1 described in their own repositories ("the checkout dies before any step"), fixed there by moving to `node:22-bookworm`; every other repository in the project, the core included, now uses that image, and postulo-mcp is the only one still on the Python image. On that evidence no lint or test in this repository is being run by CI. Two smaller gaps sit behind it and would show as soon as it runs. - **Where:** `.forgejo/workflows/ci.yml:13-14` (the container image), `.forgejo/workflows/ci.yml:26-27` (`uv sync`), `pyproject.toml:6` (`requires-python = ">=3.12"`), `pyproject.toml:46` (`target-version = "py312"`) - **What happens:** 1. **The image.** `actions/checkout@v4` needs `node` in the container; `python:3.14-slim-bookworm` has none, so the run stops at the first step. The `apt-get install curl` in the next step would be unnecessary on `node:22-bookworm`, which carries curl and git. 2. **The install.** `uv sync` without `--locked` re-resolves when `pyproject.toml` and `uv.lock` disagree, instead of failing. The server tracks the MCP SDK closely (`mcp.server.mcpserver`, `mcp_types`, the `TokenVerifier` and `AuthSettings` shapes), so a lower bound bumped without re-locking would be tested against a resolution nobody reviewed. Every other Python repository runs `uv sync --locked --python 3.14` and says why in a comment (for example postulo-dav `.forgejo/workflows/ci.yml:50-53`). 3. **The Python versions.** The package declares `>=3.12` and ruff targets py312, but the job tests one version. Unlike the plugins, which run inside the core's Python (and the core tests 3.12–3.14 in a matrix), this server is installed on its own with `uv tool install` under whatever Python the person has, so the versions it claims are the ones people run. - **Why it matters:** the README makes promises that only tests hold (#1 asks for more of them), and a CI that cannot start holds none of them. A red or absent run on every push also trains whoever reads it to ignore it. - **Fix:** run the job in `node:22-bookworm` with `persist-credentials: false` on the checkout, as the plugin repositories do; install with `uv sync --locked`; run the tests over a 3.12 / 3.13 / 3.14 matrix (`uv sync --locked --python ${{ matrix.python-version }}`), or raise `requires-python` to what is tested. Pinning the uv installer version (`astral.sh/uv/${UV_VERSION}/install.sh`, as the core does) is worth doing in the same change. ## Done when - A push to main shows the CI run reaching and passing the lint and test steps on every listed Python version, and a deliberately stale `uv.lock` on a branch makes the install step fail.

tiagoagueda added this to the 0.5.0 milestone

2026-10-01 10:48:02 +00:00

tiagoagueda added the

bug

label

2026-10-01 10:48:02 +00:00

tiagoagueda referenced this issue from a commit

2026-10-01 21:22:44 +00:00

Retake the snapshot of Postulo's API, which is fifteen days and seven addresses behind

tiagoagueda referenced this issue

2026-10-17 10:39:31 +00:00

SEC2-050: postulo-mcp locks mcp 2.1.1, whose Streamable HTTP server keeps sessions without bound (CVE-2026-59951), and CI never audits it #17