ci: make Cleo primary and retain Over as an alternative

Open
#460 4 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@DeandreT is already working on this.

Since Oct 25, 2026.

Assessment

This issue has not been assessed yet.

Description

Make Cleo the primary Linux CI runner and rename the existing OVH alternative to Over.

Ownership: .github/workflows/{ci,codegen}.yml, scripts/ci runner provisioning/routing, and runner operations documentation. Host setup covers dedicated persistent CI containers on Cleo and the existing Ferrule runner on Over.

Exclusions: application/runtime behavior, Pages deployment, other hosts/services, and deleting retained test evidence. Preserve in-flight jobs and foreign pull-request isolation.

Dependencies: #454 and #458 supply disk recovery before each Ferrule job. This increment builds on #458 without changing its retention policy.

Acceptance:

  • Cleo is registered and online with Ferrule-specific labels, isolated graphical tests and persistent storage outside SteamOS's system partition.
  • Trusted CI defaults to Cleo; Over is automatically eligible only while every Cleo worker is offline; explicit choices remain available and fork PRs use GitHub-hosted runners.
  • The existing runner is renamed without interrupting active jobs or dropping queued work.
  • Routing and provisioning checks pass; real native/codegen qualification status is recorded separately.

Additional requested runner qualification:

  • Two Cleo Ferrule workers use separate homes, checkouts, writable caches and evidence, with a shared host memory budget.
  • A Vecta user service switches only fallback scheduling labels after confirmed offline/online observations, preserves other labels and active jobs, and leaves credentials on Vecta.
  • Outage, recovery, busy-primary, incomplete-inventory and failed-API cases are qualified without interrupting live jobs.
Dominant language
Rust
Stars
1
Forks
0
Avg merge
2h 50m
Merged PRs (30d)
571

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from DeandreT/ferrule

All issues in DeandreT/ferrule

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.