ci: make the unit workflow work on the forge runner #10

Merged

troed merged 1 commit from fix/ci-unit into main

2026-10-21 10:03:25 +02:00

troed commented

2026-10-21 10:00:19 +02:00

Owner

The ci / unit workflow has never passed: every run failed 3-4s in, before any test executed.

Root causes (from the run logs)

actions/setup-python@v5 cannot install on the runner's job image. The log:
```
Version 3.13 was not found in the local cache
::error::The version '3.13' with architecture 'x64' was not found for this operating system.
 -> Skipping step 'actions/setup-python@v5'
```
setup-python installs from GitHub's prebuilt-toolcache manifest, which has no asset for Debian 13 (the runner image is node:24-trixie). The image already ships python3 3.13.5; Debian only splits the venv module and pip into separate packages. The workflow now creates a venv and installs pytest into it.
The suite requires an ordinary user, and the job container is root with umask 000. install.sh is a per-user installer that refuses root, and files created under umask 000 are group/other-writable, so the host-actions policy loader (correctly) refuses the test's own policy: 27 failures of the form error: run as your user and is group/other-writable; refusing. The tests now run as a dedicated user with umask 022 and git's safe.directory for the root-owned checkout.
One test hardcoded the users troed/root when checking that sshd's %u token expands. It now derives the invoking user, so the suite passes for any username.

Verification

On the forge runner: 1146 passed, 44 deselected - identical to the local run. Earlier green run of the same workflow content: run 15.

The diagnostic branch that produced this (ci/probe, PR #9) is throwaway and will be deleted.

The `ci / unit` workflow has never passed: every run failed 3-4s in, before any test executed. ## Root causes (from the run logs) 1. **`actions/setup-python@v5` cannot install on the runner's job image.** The log: ``` Version 3.13 was not found in the local cache ::error::The version '3.13' with architecture 'x64' was not found for this operating system. -> Skipping step 'actions/setup-python@v5' ``` setup-python installs from GitHub's prebuilt-toolcache manifest, which has no asset for Debian 13 (the runner image is `node:24-trixie`). The image already ships `python3` 3.13.5; Debian only splits the venv module and pip into separate packages. The workflow now creates a venv and installs pytest into it. 2. **The suite requires an ordinary user, and the job container is root with umask 000.** `install.sh` is a per-user installer that refuses root, and files created under umask 000 are group/other-writable, so the host-actions policy loader (correctly) refuses the test's own policy: 27 failures of the form `error: run as your user` and `is group/other-writable; refusing`. The tests now run as a dedicated user with umask 022 and git's `safe.directory` for the root-owned checkout. 3. **One test hardcoded the users `troed`/`root`** when checking that sshd's `%u` token expands. It now derives the invoking user, so the suite passes for any username. ## Verification On the forge runner: **1146 passed, 44 deselected** - identical to the local run. Earlier green run of the same workflow content: [run 15](https://git.sync.wtf/troed/umwelt/actions/runs/15). The diagnostic branch that produced this (`ci/probe`, PR #9) is throwaway and will be deleted.

troed added 1 commit

2026-10-21 10:00:19 +02:00

ci: make the unit workflow work on the forge runner

ci / unit (pull_request) Successful in 52s

Details

5e0739044c

The workflow had never passed: every run since it landed failed 3-4s in,
before any test ran. Two independent defects, both about the runner's
environment rather than the suite:

- actions/setup-python@v5 fails on the runner's job image (Debian 13,
  trixie): it installs from GitHub's prebuilt-toolcache manifest, which has
  no asset for that release, so it reports "The version '3.13' with
  architecture 'x64' was not found for this operating system" and the job
  dies. The image already ships python3 3.13.5; Debian just splits the venv
  module and pip out, so create a venv and install pytest there.

- The suite assumes an ordinary user, because install.sh is a per-user
  installer that refuses root, and because the job container starts with
  umask 000, which makes the test-created host-actions policy
  group/other-writable and the policy loader (correctly) refuses it. Run the
  tests as a dedicated user with umask 022, and give that user git's
  safe.directory for the root-owned checkout.

One test also hardcoded the expected users `troed`/`root` for sshd's `%u`
token; derive the invoking user instead, so the suite passes for any
username.

Verified on the forge runner: 1146 passed, 44 deselected - the same counts
as the local run.

troed merged commit f1b61483a0 into main

2026-10-21 10:03:25 +02:00

troed deleted branch fix/ci-unit

2026-10-21 10:03:26 +02:00

troed referenced this pull request from a commit

2026-10-21 10:03:27 +02:00

ci: make the unit workflow work on the forge runner (#10)