Red Checks, Green Tests, Then No Checks
Earfh's CI turned red on October 10 with every test passing, because 89 game builds filled the artifact quota. Two days later the Actions minutes ran out and the workflows went to manual dispatch. The suite still has to pass before a merge, and now only a person or a command makes it run.
On 2026-10-10 every automated check on Earfh went red, and the tests had not failed. The Windows build workflow uploads a build of roughly 90 MB on each run, and the repo held 89 of them under a 14 day retention. The artifact quota was full, so the next upload step failed and the run reported failure. A red mark on a pull request normally means the code is broken. This one meant the storage was.
The first fix
Build and test artifacts are now kept three days instead of fourteen, and 86 of the old builds were deleted. The commit message says what happened and not much else, and I won't guess at how the quota was first noticed. The arithmetic in the content log is simple: 89 builds at about 90 MB is a little over 8 GB.
The lesson that day was about what a check is measuring. A failing check carries a meaning, and the meaning had drifted from "the code is wrong" to "something in the pipeline is wrong". Telling the two apart meant reading the logs, and a habit of ignoring red marks would hide the next one that is real.
The second change
On 2026-10-12 the repo ran out of Actions minutes. The commit that follows switches the test, Windows build and horde benchmark workflows to manual dispatch, so they no longer run on pull requests or pushes to main. All three keep workflow_dispatch, and each file keeps a comment listing the exact triggers to restore. The publish workflow is unchanged, since it only fires after a Windows build and does nothing without its upload key.
The commit also records a check worth making. main has no branch protection or rulesets, so no required check is left waiting on a run that will never start. If it had one, every pull request would have sat in a pending state forever.
What replaces the gate
The commit message ends with the rule: "The suite still has to pass before a merge: run it locally or dispatch it." The test suite did not change, and neither did the requirement. What changed is who notices when it is skipped. A CI gate is a rule enforced by a machine, and this one is now a rule enforced by whoever is merging. My standing rule for merges is to run the full suite locally first, so the switch changed little in practice.
I'd treat that as a debt and not a decision. The triggers to restore are written next to the code, so turning CI back on is an edit of a few lines, and the next time the minutes reset it should be a conscious choice and not something that happens by default.
More on the game at /games/earfh, and the rest of this series at /notes.