P9-REQUAL-01 hosted CI findings

Observed 2026-10-24 06:49 UTC. Verdict: BLOCKED (runner isolation and hosted database execution). This is an infrastructure prerequisite, not evidence of a MariaDB product regression or a production qualification.

Current evidence

Evidence	Verified result	Limit
Gitea `/api/v1/version`	1.26.0	Server version does not identify the runner binary.
Repository metadata	Existing Git credential can read Actions and reports repository admin/push/pull permissions.	`/user` and `/admin/actions/runners` return 403. Repository permission does not establish instance administration.
Repository runner listing	Runner 3 `pi-runner-1`, offline; `ubuntu-latest`, `ubuntu-22.04`; no version returned.	This is not the runner that ran the database lane.
Baseline run 844, job 1734	SHA `549b2cba5a791862ba3f854312ea819a86dc42a0`; job API identifies runner 5 `Live-Runner`, label `ubuntu-latest`; failure.	Instance-wide identity/configuration unavailable through the permitted API.
Run 844 raw log, lines 1, 12, 17	Runner reports v0.4.1; `node:20-bookworm`; merged job HostConfig has `NetworkMode:host`, `/var/run/docker.sock:/var/run/docker.sock`, `Privileged:false`, no published ports.	An earlier reading of custom HostConfig `Binds:[]` was incomplete. Effective merged configuration includes the host socket. Socket daemon ownership and production separation are unverified.
Run 844 raw log, lines 130-151	SDK 9.0.317 installed; five Python guard tests pass; `docker: command not found`, exit 127.	These are guard/unit tests, not the 32 MariaDB integration tests. Printed cleanup-failure/exit17/exit1 samples are mocked test cases; they do not show real database cleanup.
Run 844 raw log, line 152	No integration artifact files available for upload.	Hosted MariaDB tests did not run. Job API marks all steps failure despite the raw five-test `OK`; use the raw log for step outcomes.

Run 843 is historical corroboration of the same merged socket/host-network configuration. Run 844 is the baseline-SHA observation. No new hosted job, Docker command, database, or service was started in this investigation.

Version-specific native service research

The official act_runner source URL redirects to gitea/runner. The official v0.4.1 tag API resolves to 9aafec169b7ebf3d71df2b06780868fb552b435e. Read these pinned sources, not runner 2.x documentation:

Configuration example: an empty container network delegates network creation; docker_host: "-" prevents the Docker host mount in job and service containers. These are operator configuration choices, not settings changed here.
Runner implementation: passes network/socket/privilege configuration to its execution engine, sets ReuseContainers:false, AutoRemove:true.
go.mod: selects gitea.com/gitea/act v0.261.10.
Execution engine: networkNameForGitea reuses configured networks (including host); only an empty configured network generates a job network. Native service containers share that network, receive service aliases, and have explicit port bindings only from declared service ports. Normal cleanup attempts service and generated-network removal, logging cleanup errors. Services start before job steps, so a step preflight cannot make an unsafe services: declaration safe.

This establishes source capability only. The installed binary has not been matched to these source bytes, and normal-cleanup code does not prove cleanup after cancellation, runner crash or daemon loss. Nothing proves the effective Live-Runner uses an empty network or socket suppression; the observed job does the opposite. Private native services therefore remain NOT ENABLED.

Bounded workflow change

Retain the existing push branch and add fix/p9-ci-and-requalification. Add an unconditional failing isolation preflight as the first step, before checkout, SDK setup, repository scripts and all workflow Docker/Compose/database commands. It reports this handoff and requires a later reviewed workflow change after operator evidence; no self-attested repository variable bypass exists. Existing checkout, SDK, five guard tests, integration command and artifact action remain downstream. No services, socket mount, privileges, Docker CLI installation, deployment workflow or runner configuration was added.

Fresh hosted blocker verification

Owner-pushed commit 75cd04cfc2da0837b556bdcf1424846349c4c73d triggered run 847, job 1737, on runner 5 Live-Runner. The raw log records the first isolation step emitting explicit BLOCKED at 2026-10-24 06:56:14 UTC, then exit 1. Checkout and SDK main steps were skipped; no repository guard/integration script or workflow Docker/Compose command executed. The artifact action found no integration files. No MariaDB service was declared or started. This verifies fail-closed workflow behavior only; hosted MariaDB qualification remains BLOCKED.

Runner preparation still creates its job container with the existing host network/socket, pulls the job image and prefetches action repositories before the first step. The preflight cannot prevent runner-owned preparation. Its container and generated workspace volumes were removed afterward; this does not establish private database service lifecycle behavior. The job API again labels all steps failure, so raw logs distinguish the actual blocker from skipped downstream steps. Read-only follow-up refreshed .artifacts/mariadb/requal-ci-api.json; the JSON report carries its new hash and separate run-847 API/log hashes.

Do not remove the blocker merely because Docker becomes available. Under the observed configuration that could grant the job control of an unidentified host daemon. The desired future native service must use mariadb:12.2.2@sha256:42a27baaba3e8f3f0159d16381d5a7156661aa91dcc65f663cabb6a6f9503c00 on the already documented linux/amd64 platform, no published service ports, private job networking and verified disposable storage. No version upgrade is proposed.

The current fixture and --existing-server runner deliberately allow only explicit loopback TCP. A later private service transport must preserve those defaults and receive separately reviewed narrow endpoint validation; no fixture bypass is included here.

Sanitized API metadata, source/log hashes, precise blockers and next actions are in ci-findings.json and CI_OPERATOR_HANDOFF.md. Ignored raw files remain local; no credentials or full environment/configuration are copied into these tracked reports.

Source checkpoint recheck

Run849/job1739 at 1a1b7c82213c24fbbc9bd4e1553a92f4c76eabd9 was inspected at11:24:57UTC. Runner5 Live-Runner again prepares a host-network job with the existing merged Docker socket bind. The first isolation guard exits1; no MariaDB test executes. The API marks downstream steps as failed, while the raw log explicitly says the checkout/setup main steps were skipped. The raw log SHA-256 is 4aeee7452db935ecf01afad44d2812e7fb9160239317c87d6a3d429cbdd128de. This independently confirms the same BLOCKED disposition at the published harness checkpoint; it is neither a hosted MariaDB PASS nor an executed database-test failure.

7.7 KiB Raw Blame History