cesnimda
4.0 KiB
Hosted CI metadata refresh — 25 October 2026
Hosted MariaDB CI remains BLOCKED. This refresh establishes API availability and run metadata, not a newly inspected live runner configuration or a hosted database execution.
Observation: 2026-10-24T22:14:53.076535Z, corresponding to 25 October2026 00:14:53 Europe/Paris (CEST). Existing Git credentials were used only in memory for bounded GET requests; credentials, headers and helper output are not retained. No job, runtime, build, browser, database, workflow or infrastructure operation was started or changed.
| Current API fact | Result |
|---|---|
/api/v1/version |
HTTP200, Gitea1.26.0 |
| Repository metadata | HTTP200; existing credential reports repository admin/push/pull |
| Repository runner listing | HTTP200; runner3 pi-runner-1 remains listed offline, non-ephemeral, labels ubuntu-latest/ubuntu-22.04 |
Instance-runner listing and /user |
HTTP403; actual runner5 host/instance configuration remains inaccessible |
| Latest-runs request | HTTP200; request limit100 returned50 rows, newest observed run853 at3727a72 |
| Remediation-branch query | HTTP200, zero returned rows for fix/p9-pdf-security-requalification; none of the50 observed latest rows matches that branch |
| Latest observed job metadata | Run853/job1743: runner5 Live-Runner, completed/failure,24October16:33:16–16:33:23UTC |
| Previous observed job metadata | Run852/job1742: same runner5, completed/failure,24October16:24:08–16:24:15UTC |
The branch query and observed latest window show no accessible hosted run for the remediation branch. This bounded read is not an exhaustive assertion about all historical runs or a guarantee that the provider honors every query parameter. Current .gitea/workflows/mariadb-integration.yml push filters retain only codex/rd21-mariadb-standardisation and fix/p9-ci-and-requalification; the remediation branch is excluded. Pull-request/manual triggers still exist. No new trigger or dispatch was added to manufacture another guard failure.
Distinguishing old runtime proof from current metadata
The earlier CI investigation inspected the actual 24October run853 log: reported runner v0.4.1, node:20-bookworm, effective merged host networking and host Docker-socket bind, non-privileged job; first isolation guard exited1 before checkout/SDK/MariaDB. Its SHA256 is 448df52f9c9cf3c156b5f742dbef6e3745844b25f968d4e9138c142437837134. That is retained historical runtime evidence at3727a72.
This25October refresh downloaded metadata only. It did not re-inspect live HostConfig, download a new runtime log, verify a daemon/host identity or observe private services. Therefore it does not claim that the live host configuration is unchanged merely because the latest visible run is unchanged. No new isolation or lifecycle proof is available, and no MariaDB test execution is established.
Remaining exact handoff
The operator implementation/verification plan remains the next action: dedicated nonproduction runner/daemon ownership; unique routing label and pinned supported binary/job image; effective private job/service networking; no job/service daemon socket, host networking, privilege, public database port or persistent database storage; least-privilege secret/token/PR trust and production egress separation; success/failure/cancel/interruption cleanup proof. Only after that evidence may a reviewed workflow/strict CI-service transport change enable actual pinned MariaDB12.2.2 execution.
Local MariaDB tests, an accessible API, unchanged run metadata, a runner label, or an expected guarded failure cannot satisfy hosted PASS. Production release/infrastructure gates and local RD21 closure remain independent. Sanitized values and hashes of these fresh metadata responses are recorded in ci-refresh.json; raw responses remain under .artifacts/p9-remed-02/ci-refresh-20261025/.