Skip to content

docs(workflows): rename split-CI labels to github-runner/kkt-runner - #11

Merged
ocots merged 1 commit into
mainfrom
docs/workflows-runner-labels
Jul 30, 2026
Merged

docs(workflows): rename split-CI labels to github-runner/kkt-runner#11
ocots merged 1 commit into
mainfrom
docs/workflows-runner-labels

Conversation

@jbcaillau

@jbcaillau jbcaillau commented Jul 30, 2026

Copy link
Copy Markdown
Member

Closes #10.

Takes option 1 of issue #10 §2: standardise on a single vocabulary for the split-CI labels, named after the runner rather than the workload.

Was Now
run ci cpu github-runner
run ci gpu kkt-runner

Rationale recorded in §2: the GitHub-hosted job is not meaningfully "the CPU job", it is the job that runs on GitHub's runners (and happens to exercise CPU paths); the other job is defined by the self-hosted machine it lands on (kkt). The runner-based names keep the label, the runs_on value and the job name saying the same thing, and they extend to any future runner by the same rule (kkt-runner, mothra-runner, …) without inventing a new workload adjective.


⚠️ Migration required after merging — this PR is documentation-only

Merging this makes WORKFLOWS.md describe a state the fleet has not reached. Three repos still carry the old labels, and until they are migrated the handbook is aspirational for them. Current state verified against each repo's main on 2026-07-30:

Repo CI.yml job names Guard label names Repository labels Status
CTParser.jl test-github-runner, test-kkt-runner github-runner, kkt-runner already created ✅ done (#302, open)
OptimalControl.jl test-cpu-github, test-gpu-kkt run ci cpu, run ci gpu old ❌ to migrate
CTFlows.jl test-cpu-github, test-gpu-kkt run ci cpu, run ci gpu old ❌ to migrate
CTSolvers.jl test-cpu-github, test-gpu-kkt run ci cpu, run ci gpu old ❌ to migrate
CTLie single run ci job n/a — use the new names when it splits
CTDirect.jl GPU.yml, run GPU out of scope (historical pattern, §3.3)

Per-repo checklist (OptimalControl.jl, CTFlows.jl, CTSolvers.jl)

Each of the three needs the same four edits — the label name lives in two places per repo, and a renamed label with a stale guard silently stops triggering anything (this is exactly the failure mode the new §7 bullet warns about):

  • Rename the two repository labels, preserving existing PR assignments:
    gh label edit "run ci cpu" --name "github-runner" --repo control-toolbox/<repo>
    gh label edit "run ci gpu" --name "kkt-runner" --repo control-toolbox/<repo>
  • Update the four guard occurrences in .github/workflows/CI.yml — each job's if: mentions its label twice (once in the github.event.label.name == branch, once in the contains(...) branch).
  • Rename the two jobs test-cpu-githubtest-github-runner and test-gpu-kkttest-kkt-runner, to match CTParser.jl and keep job name, label and runs_on all saying the same thing. Cosmetic, but it is the point of the rename.
  • Verify by applying github-runner to a PR and checking exactly one run starts, and that test-kkt-runner stays skipped.

Two unrelated findings spotted while checking the above

  • OptimalControl.jl's CI.yml still has opened in its types: list (types: [labeled, opened, synchronize, reopened]). That is the duplicate-run bug §2 documents at length; CTFlows.jl and CTSolvers.jl have already dropped it. Worth fixing in the same PR that does the rename.
  • CTBenchmarks.jl uses a third spellingrun CI cpu / run CI gpu (capital CI), grepped from $LABELS in a hand-rolled guard job rather than an if: guard on a reusable caller. It is not in §4's split-CI group and its CI is structured differently, so I have left it alone; flagging it since it is one more variant of the same vocabulary in the wild.

What changed in WORKFLOWS.md

  • §2 — the two rows of the label table renamed; the section heading is no longer "The run … labels" (not every trigger label starts with run any more). Added two paragraphs: why the split is named after the runner, and that this vocabulary is fleet-wide, not a per-repo choice — which is the question WORKFLOWS.md: CTParser.jl misclassified as having no GPU code, and no guidance on split-CI label naming #10 said the handbook was silent on. run ci cpu/run ci gpu are marked deprecated.
  • §7 — new bullet: rename a label fleet-wide. The name lives in two places per repo (the repository label and the caller's if: guard) and they must move together, otherwise the label silently triggers nothing. Also narrowed the existing "per-repo trigger change" bullet: a repo chooses which labels it defines, never how they are spelled.
  • §3.1, §4, §5, §6, §8 — names propagated (split CI (cpu/gpu)split CI (`github-runner`/`kkt-runner`), checklist item, new-repo recipe step 7).

Also fixed (issue #10 §1)

CTParser.jl was listed under "no GPU-relevant code" in §3.1 and had no split-CI entry in the §4 table. That is factually wrong — it depends on CUDA, MadNLPGPU, KernelAbstractions and ExaModels, loads them unconditionally in test/runtests.jl, and ships the ExaModels backend in src/onepass.jl. Moved into the split-CI group in both places. This is bundled here because the same table rows and the same sentence carry both the classification and the label names.

Not addressed here

Issue #10's closing note — breakage matrices should be re-derived from actual downstream [deps] rather than maintained by hand — is worth a separate §4 note.

🤖 Generated with Claude Code

Closes #10.

The split `CI.yml` labels are now named after the *runner* rather than the
workload: `run ci cpu` -> `github-runner`, `run ci gpu` -> `kkt-runner`. The
GitHub-hosted job is not meaningfully "the CPU job", it is the job that runs on
GitHub's runners; the other is defined by the self-hosted machine it lands on.

- §2: rename the two rows in the label table, state that the runner-based
  vocabulary is fleet-wide (not a per-repo spelling choice), and mark
  `run ci cpu`/`run ci gpu` as deprecated.
- §7: add a "rename a label fleet-wide" recipe (repository label + caller `if:`
  guard must move together) and scope the per-repo licence to *which* labels a
  repo defines, not how they are spelled.
- §3.1, §4, §5, §6, §8: propagate the new names.
- §3.1/§4: CTParser.jl was wrongly listed as having no GPU-relevant code; it
  depends on CUDA/MadNLPGPU/KernelAbstractions/ExaModels and ships the ExaModels
  backend, so move it into the split-CI group.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@jbcaillau jbcaillau added the documentation Improvements or additions to documentation label Jul 30, 2026
@ocots
ocots merged commit bba1edf into main Jul 30, 2026
@ocots
ocots deleted the docs/workflows-runner-labels branch July 30, 2026 16:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

WORKFLOWS.md: CTParser.jl misclassified as having no GPU code, and no guidance on split-CI label naming

2 participants