The kit's own CI

What .github/workflows/self-test.yml runs, when, and what that costs. The workflow is the kit's own check; the reusable workflow games call is godot.yml. To see which self-test covers what, read coverage.md. A design for skipping a job whose inputs already passed (awaiting the owner's decision): ci-cache.md.

What runs when

On a pull request .github/scripts/Select-Jobs.ps1 (the changes job) lists the changed files against the base with plain git diff and decides, with no third-party action. If the base cannot be fetched, everything runs.

Alongside, every run measures an input hash per job and records which jobs went green on which hash (the record job and the cache-observations artifact; ci-cache.md, stage 0). It skips nothing yet.

Skipped jobs report as skipped, which satisfies a required check. The coverage job enforces its floors only on the full runs; on a pull request it reports what was reached, since a skipped job's records are missing by design. tests/Test-SelectJobs.ps1 holds all of this, and checks that every test a skippable job runs selects that job.

Kept for the full runs

A few steps run only when the event is not a pull request (if: github.event_name != 'pull_request'). Each had no failure in the sampled runs (below), is expensive, and is redundant with a cheaper or nearer check:

Measured

A full run before these changes (nick-vas/hyperdot#134, run 40360421024): 35 jobs, 513 runner-minutes, 84% of them in the 20 jobs of the game-programme matrix (C# pairs 27 minutes on average, GDScript 16). Estimated after, in runner-minutes (the jobs' own averages from that run; the pairs' from the sampled runs):

Before, every push to a pull request branch also started a second run (push and pull_request), which the shared concurrency group cancelled after both had queued: in the 100 sampled runs, 47 were cancelled.

Faster game jobs: measured, nothing shipped

A C# staged-programme task builds and tests three workspaces (the untouched game, the reference, the decoy). On this machine (4 cores, Godot 4.7.2 mono, .NET 8.0.131), cards in C# at the prototype stage, 6 checks: 8 min 3 s with a warm NuGet folder. One task, with a dotnet stand-in that logs each call:

A whole test on one workspace takes 57 s: the build 9 s (4.7 s of it start-up), the gdUnit4 run 27.5 s (Godot start-up and the 55 tests), the 11 other runners about 20 s. Restore from NuGet is paid once per job (the packages folder is shared by the job's workspaces), 15 s of a 25-minute job, so a cache saves less than restoring it costs. DOTNET_TieredPGO=0 and DOTNET_CLI_TELEMETRY_OPTOUT, DOTNET_SKIP_FIRST_TIME_EXPERIENCE, DOTNET_NOLOGO against the baseline, three runs each of the dotnet runner: 31.25 s, 31.12 s and 30.72 s, which is noise. The Roslyn compiler server is already shared. What would cut the time is running the three workspaces of a task at once, which collides on ports (the arena's ENet) and on the runner's four cores; that is not a safe change to a test harness here, so none of this was shipped.

Git background maintenance

Every job of self-test.yml and godot.yml runs with GIT_CONFIG_COUNT=3 setting gc.auto=0, gc.autoDetach=false and maintenance.auto=false: git 2.54 and later runs maintenance after a commit, which packs and deletes loose objects and has raced tests that commit and then clone or copy a repository (the staged programme's game workspaces, Test-UpdatePins.ps1). actions/checkout is unaffected.

Which tests ever caught anything

The 100 most recent completed runs of self-test.yml (23-26 October 2026): 32 succeeded, 21 failed, 47 were cancelled (82 were push events, 17 pull_request, 1 workflow_dispatch). Jobs and steps were read for 19 of the 21 failed runs (two requests failed) and 3 others, so a step's "runs" below counts those 22 runs, which are mostly failing ones: the failure rates are upper bounds, the zero counts are not. A run that failed shows its failing step; the coverage job's step failed 5 times only because a job before it had.

Steps that ran in the sample and never failed, by cost per run: the field-test job (1031 s, 0 of 14), the game benchmark's test programme (106 s, 0 of 16), the stand-in project sync (196 s as the board sync, 0 of 15), every documented error code (191 s, 0 of 11), the plan's gates (123 s, 0 of 15), Web export -Run (138 s, 0 of 16), audio -Mix (79 s, 0 of 11), the placement checker (66 s, 0 of 16), -GpuValidation (65 s, 0 of 16), Firefox under Xvfb (63 s, 0 of 16).

Three days in one burst of work is a small sample, so only three were moved to the full runs: the project sync (then the board sync) and the test programme (cheap to lose, redundant with a nearer check) and the field test for changes outside benchmark/ (the largest, with the least to say about a kit change). The rest stay, as the error codes, the plan's gates, the web and GPU checks guard contracts a pull request should not break, and a quiet sample is not a reason to stop looking.

Demoting more to the nightly run: the history, and a recommendation

The task was to move every job that never failed to the nightly run, and the first attempt had no history to decide on (a sample of 22 runs, mostly failing ones). This section is the history. Nothing was demoted: no workflow file changed, and the owner decides from the numbers below.

Coverage. Every run of self-test.yml there is: 842 runs from 5 October 2026 12:07 to 28 October 2026 22:43 UTC (23.4 days: the workflow is that young, so the 60 days the criterion asks for do not exist yet; the 100-run mark is passed by most jobs and steps). 305 were pull request runs (on 160 branches), 169 pushes to main, 365 pushes to other branches (the workflow ran on every push until 26 October, so a pull request used to have two runs), 2 nightly runs and 1 workflow_dispatch. Of the 842 runs 556 passed, 178 failed and 108 were cancelled; the jobs and steps of all 842 were read (14,092 job attempts, 160 of them second attempts of 7 re-run runs; no read failed). Raw JSON came from gh api repos/nick-vas/hyperdot/actions/workflows/<id>/runs and .../actions/runs/<id>/jobs and is not kept in the repository.

Method. A run of a job is an attempt that ended in success or failure (cancelled and skipped attempts are not outcomes; a cancelled attempt's minutes still count). Branch push is the old push-to-any-branch run. A failure is flaky when the same job at the same head commit and for the same event later succeeded in another run or attempt. Only 7 runs were re-run, so this finds few, and a failure nobody re-ran is "real" here only in the sense that it was not shown to be flaky; the logs were not read. A failure is only after merge when the job failed on the push to main, was not flaky, and the last run of that job on the pull request of that merge (found with the commit's pull request) had passed, or the job had not run on the pull request. The pull request's head is not the merge commit, so this is the closest the history allows. Minutes are a job's wall-clock duration (start to end of the job, not rounded up to the minute and not weighted: the Windows job bills at a higher rate), summed over all attempts including cancelled ones. Median is of the successful runs.

What the 23 days cost. 49,839 runner-minutes (831 hours): 23,290 (47%) on main, 14,174 (28%) on pull requests, 11,269 (23%) on branch pushes (the old double run), 1,106 (2%) in the nightly and manual runs. The 20 jobs of the game-programme matrix alone took 47% of all of it (23,412 minutes), and measure 11%.

"Runs" adds the nightly and manual runs, which the columns leave out (3 runs, one of them red: measure, one racing pair and coverage on 27 October, the same failures main had). zero-config and explicit-runners have Export and Release jobs that are skipped by design (0 runs), so they are not listed. game-programme is one row for its 20 pairs (22 minutes median, 15 to 36 by pair).

How the failures read.

• One burst makes the failure column look worse than it is. 175 of the 340 failed job attempts are on 22 October, when 57 pull requests were merged between 05:13 and 09:10. Three steps account for 134 of them (local-windows "Filtered run" 76, lint "A failed Godot download stops with download-failed" 35, init "bare-game" 23): they failed on the pull requests too (44 of the 65 failed job runs on main had failed on their pull request too), so a pull request run did show them. They say that merging on red was possible, not that a pull request run missed something.
• Of the 65 failed job runs on main, 44 had failed on their pull request too, 1 was flaky (csharp / Test), and 20 failed only after merge: 18 had passed on the pull request, 2 (the racing pair on 27 October, web on 27 October) had not run there. They come in 14 sequences. By job: measure 11 (the capture-mode step, 10 times in 22 October's burst, and soak once), coverage 3 (its floors are enforced only on full runs, by design), web 3 (Firefox under Xvfb once; the Playwright system packages twice), game-programme 2 (the racing pair in C#, in main on 26 and 27 October and in the nightly run), local-windows 1 (the C# example with coverage). The capture-mode step is intermittent: it failed 30 of 404 times (6 of 154 on pull requests, 11 of 114 on main) and passed in between, so it is flaky rather than missed.
• Pull request runs did catch things. Failures on pull request runs (flaky ones included): lint 22, local-windows 34, init 13, measure 15 (2 of them flaky), web 6, game-programme 4 (1 flaky), csharp / Test 2, csharp / Export 1, csharp / Release 1, coverage 2. Only field-test, zero-config / Test, changes, explicit-runners / Test, action and game-benchmark have none (0 of 40, 275, 56, 273, 270 and 49 pull request runs).
• Since the selection (26 October 19:55) a pull request runs what its change can affect. Of the 54 pull request runs since, measure was skipped in 21, init in 20, action in 20, local-windows in 19, game-benchmark in 13, and 24 pair jobs of game-programme (the sample). Job failures on those runs: 8 (lint 3, measure 3, coverage 1, game-programme 1). That is the history that shows what the selection costs, and it is too short to say much.

Where the time goes inside the slow jobs (steps, all runs of the 23 days; "PR / main" are runs on those events):

Steps that never failed. Steps with at least 100 runs, no failure in any of them and a median of 20 s or more, by what they cost on pull requests (the 15 steps cost 2,033 of the 14,174 pull request minutes, 14%; the stand-in project sync and the test programme are already full-run steps, and their pull request minutes come from before that):

None of the 20 failures that appeared only after merge came from one of these steps.

Recommendation. The criterion is zero failures in about 100 runs that included the job's files. What the history can show is zero failures in at least 100 runs of the step, whatever the change. It cannot show that a run "included its files", because that needs each run's changed files, which this collection did not read; before 26 October a pull request ran every job whatever it changed, so most of those runs were not about the step's files, and zero in 100 of them is weaker evidence than zero in 100 relevant ones. With that said:

May move to the full runs (pull request minutes saved of 14,174):

1. field-test (716 min, 5% of pull request minutes): 0 failures in 100 runs (40 on pull requests, 40 on main, 18 on branches), 18.7 minutes median, the largest step outside the pairs; pull requests already run it only for changes under benchmark/. game-benchmark (0 failures in 49 pull request runs, 4 on branch pushes) still runs on those pull requests, and a kit change that breaks the field test shows there and in the pairs.
2. measure: every documented error code (125 min): 0 failures in 115 runs, 193 s a run. It raises the codes no other self-test raises, and the earlier text kept it on purpose as a contract check; the history gives no case where it fired.
3. lint: the plan's gates (128 min) and init: test -Retry (101 min) and the placement checker (99 min): 0 failures in 249, 318 and 427 runs. The plan's gates and the retry check guard what a plan or a flaky test does to a game, which the earlier text also kept on purpose: the case for them is the numbers alone.
4. measure: shot, audio (files, buses, -Mix), bench -Sweep, the palette check and deck (about 243 min together): 0 failures in 104 to 677 runs each. They need a display, which is what makes measure slow (6.8 minutes median).
5. local-windows: Windows export and launch (242 min): 0 in 638 runs; Windows is the one job that runs the script as a developer runs it, so keep the GDScript example and the C# example with coverage (8 failures, 3 on pull requests) and move only the export.

Moving all of 1 to 5 would take about 1,650 of the 14,174 pull request minutes (12%) off the pull request and leave them on main and the nightly run.

Must stay on pull requests:

• lint (22 failures on pull requests, none flaky, none found only after merge; 2.2 minutes median): the cheapest job and the one that catches the most.
• init (13 on pull requests, 0 after merge), local-windows (34 on pull requests, 1 after merge), csharp, explicit-runners and action (the reusable workflow games call: 1 to 3 failures each, each in 2 minutes or less; these are the product), and coverage (floors are enforced only on full runs; it costs 0.3 minutes).
• measure minus the steps above (11 failures found only after merge, 15 on pull requests; soak, bench and capture mode are intermittent: 8 of 585, 10 of 688 and 30 of 404 runs failed). Moving more of it would make soak and capture mode fail for the first time on main, as they already did.
• web (export -Run: 4 failures in 494; Firefox, GPU validation and the Playwright system packages fail now and then: 6 on the packages step, 2 of them only after merge) and game-benchmark (the grading, 1 failure in 125; isolated sessions, 3 on branch pushes).
• game-programme already runs a sample of 3 pairs on a pull request (192 pair runs on pull requests against 735 on main, 47% of all minutes and 4,453 pull request minutes, mostly before the selection). Its failures: 4 on pull requests (1 flaky), 2 on main, 2 after merge. Nothing here argues for dropping the sample.
• changes, record, programme-pairs (plumbing; 0.1% of minutes). zero-config / Test (0 in 768 runs, 0.6 minutes, 1.1% of minutes) meets the criterion but saves almost nothing, and it is the same action as the three jobs beside it: leave it.

Before moving anything, Test-SelectJobs.ps1 needs the demotion added to its expectations. Re-collect when the history reaches 60 days (about 4 December 2026): the window is short, a burst of one day carries half the failures, and the logs of the 20 after-merge failures were not read.

Changelog fragments

CHANGELOG.md is edited only at release. Each change adds changelog.d/<slug>.md (format: changelog.d/README.md) and ci/godot/tools/Update-Changelog.ps1 assembles them; tests/Test-Changelog.ps1 runs in lint, and a change to the fragments is Markdown, so it runs lint alone. The repository has no rule that a pull request must change the changelog, so CI does not require a fragment.

Releasing

.github/workflows/release.yml ("Release") tags and publishes a release. Tags cannot be pushed from the cloud session (its git proxy answers 403 for tag pushes), so a workflow makes them. Run it from Actions > Release > Run workflow, or gh workflow run release.yml -f version=0.1.0 [-f sha=<commit>]:

It stops before changing anything unless: the commit is reachable from origin/main and has a successful Self-test run for a push to main (read with gh api; this needs read access to workflow runs, the default for a public repository, and on a private one the check fails closed until actions: read is added to the workflow's permissions); CHANGELOG.md has a ## <version> - section (.github/scripts/Get-ChangelogSection.ps1, held by tests/Test-ReleaseNotes.ps1). (.claude-plugin/plugin.json declares no version, so Claude Code treats every commit on main as a new version of the plugin; the release version lives in the tag and the changelog.) Then it creates the annotated tag v<version> (it fails if that tag exists at another commit: version tags are never moved; at this commit it is left alone, so a run can be repeated), creates or force-moves the moving tag (the one tag that moves, as games pin @v1; .github/scripts/Test-MajorTagMove.ps1 leaves it where it is, with a notice, when a tag of a greater version of the same major exists, so releasing 1.2.1 after 1.3.0 does not move v1 backwards; the repeated run of the version already tagged still moves it): v<major> by default, or the major_tag input, which a 0.x release sets to v1; it pushes both as github-actions[bot], and runs gh release create v<version> --verify-tag with the changelog section as the notes (cut near 120000 characters, the limit of a release body, with a link to the changelog). Tags pushed with the workflow's token start no other workflow. A change to release.yml or its scripts (Get-ChangelogSection.ps1, Test-MajorTagMove.ps1) runs lint alone. The version and the major tag are matched whole (\A[0-9]+\.[0-9]+\.[0-9]+\z): $ accepts a trailing newline and \d Unicode digits in .NET.

tests/Test-WorkflowLint.ps1 (in lint) reads the workflows as text for what cannot run here: a pull request's concurrency group is pr-<number> (the branch name alone made pull requests of two forks cancel each other), release: true with no exports fails the test job of godot.yml instead of ending green without a release, and canary.yml runs the upstream code (the try job) with read permission, no token and no stored credentials, while propose, which has the write permissions, applies the patch it made and runs none of that code. Every action from another repository is pinned to a commit SHA with its version in a comment (actions/checkout@<sha> # v7), the Claude Code CLI and uv are installed at a version, and .github/dependabot.yml proposes the weekly bumps of the actions; the lint fails on a tag.

Running everything locally

pwsh tests/Test-SelectJobs.ps1                                   # what a change would run (no Godot)
pwsh .github/scripts/Select-Jobs.ps1 -EventName pull_request -Base <sha> -Json   # for the current checkout
for t in tests/Test-*.ps1; do pwsh $t; done                      # every self-test (several need Godot, a display or ffmpeg: see docs/self-tests.md)

docs/self-tests.md has the table of what each self-test needs. gh workflow run self-test.yml starts the full run.