Downstream Migration Checklist
Use this guide when a downstream GitHub Actions repo is moving onto the current GloriousFlywheel runner and cache contract.
This is the shortest honest checklist for the tranche-1 migration lane tracked
in #210.
Who This Is For
- org repos that want to use shared
tinyland-*runner labels - user-owned canary repos such as
XoxdWM - downstream repos that want GloriousFlywheel composite actions without manual platform archaeology
Current Downstream Contract
Shared runner labels:
| Label | Use when |
|---|---|
tinyland-docker |
general CI, lint, test, and non-Docker builds |
tinyland-nix |
Nix builds and reproducible flake workflows |
tinyland-nix-heavy |
memory-heavy Rust/Nix jobs when the additive heavy lane is available |
tinyland-dind |
Docker-in-Docker or privileged container build paths |
Composite actions:
| Action | Use when |
|---|---|
tinyland-inc/GloriousFlywheel/.github/actions/setup-flywheel@main |
you only want cache/runtime auto-configuration |
tinyland-inc/GloriousFlywheel/.github/actions/docker-job@main |
you want a simple shared-runner job with Bazel cache configured |
tinyland-inc/GloriousFlywheel/.github/actions/nix-job@main |
you want a Nix job with cache setup handled for you |
Default stance:
- prefer shared runner labels first
- use composite actions when you want the cache/runtime setup packaged for you
- do not depend on legacy
Jesssullivan/GloriousFlywheel/...paths
Checklist
-
Inventory your workflows. Identify which jobs are general CI, Nix builds, or container builds.
-
Map each job to one shared runner label.
For Nix jobs, choose explicitly between:
tinyland-nixfor the ordinary8Gibaseline lanetinyland-nix-heavyfor recurring memory-heavy jobs when that additive lane is deployed
-
Decide whether the repo needs composite actions. If plain shell steps are enough, labels alone are acceptable.
-
Remove or replace any stale personal upstream references. Prefer
tinyland-inc/GloriousFlywheel/.github/actions/...@main. -
Validate cache expectations.
tinyland-nixgets Attic defaults;tinyland-dockerandtinyland-nixget Bazel cache defaults on self-hosted runners. -
Validate self-hosted Nix bootstrap. For raw
nixcommands ontinyland-nix, useDeterminateSystems/determinate-nix-action@v3or thenix-jobcomposite action instead of assuming Nix is preinstalled on the runner forever. -
Run one canary workflow on the shared runner path before converting the full repo.
-
Keep a rollback path ready. A job can temporarily return to
ubuntu-latestor another GitHub-hosted runner while the shared-runner contract is being stabilized.
Canonical Consumer Pattern
This is the reference downstream shape for a repo that wants one general CI job and one Nix job:
name: CI
on:
push:
pull_request:
jobs:
test:
runs-on: tinyland-docker
steps:
- uses: actions/checkout@v4
- uses: tinyland-inc/GloriousFlywheel/.github/actions/docker-job@main
with:
command: make test
build:
runs-on: tinyland-nix
steps:
- uses: actions/checkout@v4
- uses: tinyland-inc/GloriousFlywheel/.github/actions/nix-job@main
with:
command: nix build .#default
push-cache: "false"
Why this is the reference pattern:
- it uses stable shared labels
- it uses the current public GloriousFlywheel action path
- it avoids assuming push-cache credentials are present by default
Verification
After the first shared-runner migration:
- confirm the job lands on the expected runner label
- confirm the workflow still passes without hidden repo-local assumptions
- confirm Nix jobs see the expected cache environment
- compare runtime against the previous GitHub-hosted baseline
Rollback
If the shared-runner path is not ready yet:
- move the affected job back to
ubuntu-latest - keep the repo-specific workflow change small and reversible
- leave the rest of the repo on the previous runner path until the shared contract is fixed