fix(ci): pin runs-on to rpi5 + sync policy doc #13
No reviewers
Labels
No labels
agent:felinus
agent:human
agent:maximus
priority:p0
priority:p1
priority:p2
priority:p3
status:blocked
status:needs-review
status:wip
type:chore
type:docs
type:feat
type:fix
type:perf
type:refactor
type:test
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
jmz/matrix-bridge!13
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "maximus/fix/runs-on-arm64-rpi5"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Two-in-one bundle resolving the matrix-bridge CI wedge that ate four 30s-failure attempts on PR #12.
Root cause
Diagnosis from Maximus@nas's server-side Forgejo logs: matrix-bridge's `runs-on: self-hosted` matched both the rpi5 runner (`[self-hosted, arm64, rpi5]`) and the nas runner (`[ubuntu-latest, docker, self-hosted]`). Half the dispatches landed on nas, which runs jobs in `node:20-bookworm-slim` — a container with no cc. matrix-sdk-crypto / Olm / ring all have C deps that fail to build there. PR #11's TASK-1244 succeeded only because it happened to land on rpi5 by chance.
Changes
User impact
matrix-bridge's CI deterministically runs on the cc-bearing host runner. Future enrollments via `ensure-repo-policy.py --language rust` get the same fix automatically.
Verification
Related