Current phase: controlled migration. The isolated one-job pilot passed on 2026-07-15, and reviewed schema-v3 desired state is accepted for managed ordinary-CI controller lifecycle on isolated fleet hosts. Accepted design decisions define the authorized scope and remaining gates. This roadmap does not establish current host state or completion of downstream migrations.
Completed: initial read-only audit of two existing projects and their runner VMs.
Before each migration, verify:
- selected-repository runner-group authorization;
- remaining host update and firewall checks;
- monitoring and backup checks;
- privileged workflow separation decisions.
Exit condition: migration constraints are understood without changing working CI.
Accepted for the isolated pilot and managed ordinary-CI controller lifecycle. Production deployment and privileged delivery remain separately gated.
- Select the initial controller implementation.
- Define the runner image boundary.
- Define the reusable workflow contract.
- Define runner groups and trust boundaries.
- Define credential provisioning.
- Define cleanup and disk-pressure policy.
- Define unattended update and drain behavior.
- Define external logging and monitoring requirements.
Exit condition: accepted architecture decisions and a reversible proof-of-concept plan.
Completed on 2026-07-15. Issue #7 records the read-only one-job lifecycle proof, scoped cleanup, zero final job residue, controller health, and preservation of existing project runners.
The recorded proof covered:
- an organization-owned App and selected private runner group;
- an isolated controller with
MIN=0andMAX=1; - one manually dispatched job with
permissions: contents: read; - one-job ephemeral runner lifecycle and scoped cleanup;
- zero final job residue and controller health;
- preservation of existing project runners.
Failure, cancellation, timeout, repeated-run cleanup, disk usage, controller credential isolation, and rollback require retained evidence before migration cutover or broader adoption.
Current migration gate, assessed separately for each project through the migration guide and compliance checklist.
- Add a project-owned test image and thin calling workflow to one existing project.
- Run old and new CI paths in parallel.
- Compare results, runtime, resource use, and residual state.
- Repeat for the second project.
Exit condition: each participating project passes on the new fleet, completes its compliance checklist, and verifies rollback without removing the old path.
- Move approved read-only CI to the shared organization runner group.
- Keep release, deployment, schema-writing, and internal-network jobs separated.
- Preserve rollback instructions.
- Retire project-specific runners only after an observation period.
The schema-v3 contract and installer are available for reviewed ordinary-CI adoption. Additional hosts and capacity increases require their own evidence and approval.
- Manage runner pools and controllers through the schema-v3 private desired-state contract.
- Enroll or adopt hosts with the idempotent worker-controller installer.
- Add a second independently provisioned Docker host.
- Verify identical deployment and recovery.
- Add demand-based scaling.
- Validate host draining, rolling updates, and failure handling.
- Increase same-host concurrency only after collision, disk, and cleanup tests pass.
Tester and deployer components remain under review. Each role needs separate credentials, services, trust boundaries, validation, and rollback evidence. The completed CI pilot does not authorize production deployment or privileged delivery on ordinary-CI runners. Production readiness remains gated by per-project migration evidence and separate approval for production paths.