GitHub Actions config hardening across the five GPU-CI lecture repos

[mmcky]

Audit of GitHub Actions settings across the five repositories that run GPU CI on RunsOn, done 2026-07-30 while planning compute capability. Four config items came out of it — all hardening, none urgent.

Item 1 as originally written was wrong and has been corrected in place — it recommended reverting the on-demand decision from #330. See the correction comment for detail.

Repos in scope: lecture-jax, lecture-python.myst, lecture-python-programming, lecture-stats, iuj_feb_2026.

1. Spot pricing is switched off where most of the GPU volume is — CORRECTED, do not action

This item was wrong. See the correction comment below. spot=false is a deliberate org-wide reliability decision from #330 (spot reclamation was killing GPU builds mid-run), not an oversight. The correct action is the opposite: finish the #330 rollout by adding spot=false to the 7 GPU workflows that still lack it — all four in lecture-stats, both in iuj_feb_2026, and publish.yml in lecture-python-programming. The measurements below are accurate; the recommendation drawn from them was not.

Original text, kept for the record

spot=false is set in 10 of 17 GPU workflow files, across lecture-jax (4 of 4), lecture-python.myst (4 of 4) and lecture-python-programming (2 of 3 — publish.yml doesn't set it). lecture-stats and iuj_feb_2026 never set spot, and RunsOn defaults to spot, so those already get it.

Measured over 2026-01-31 → 2026-07-30, 98% of GPU CI wall-clock runs on spot=false — 245.9 of 251.3 hours. Flipping those 10 files to spot=true cuts that portion of the bill by roughly 58–61% at zero cost and with no downside I can see: RunsOn tries spot first and falls back to on-demand automatically when spot capacity is unavailable, at a 2–3 second launch penalty.

The single largest consumer is lecture-python.myst/ci.yml at 123.9 hours — about half of all GPU CI.

2. Fork-PR workflow approval is on GitHub's default rather than the strict setting

All five repos are set to first_time_contributors. The stricter option is all_external_contributors, which requires maintainer approval before any outside contributor's workflow runs rather than only a first-time one.

This is hardening rather than a live problem — it would start to matter if we ever attached a self-hosted runner to these repos, which we haven't. It's a five-click change and worth doing ahead of that rather than as part of it.

3. Actions can approve pull requests on four of five repos

can_approve_pull_request_reviews is true on all but iuj_feb_2026. We have no workflow that uses this, and we're planning triage and maintenance agents whose design says explicitly that a bot never approves or merges — so leaving the capability enabled makes that a convention rather than something actually enforced. Suggest turning it off so the guardrail is real.

4. Default workflow token permissions are write on four of five

default_workflow_permissions is write on all but iuj_feb_2026, which uses read. Broader than anything currently needs, and iuj_feb_2026 demonstrates read is workable. Per-workflow permissions: blocks can grant more where a workflow genuinely needs it.

Suggested order

	Item	Effort	Why now
1	Finish the #330 rollout — add spot=false to the 7 workflows still missing it	One PR	Closes a known reliability gap. Replaces the original item 1, which was wrong
2	Set approval policy to all_external_contributors	Five settings	Free, and cheaper before a runner exists than after
3	Disable Actions approving PRs	Four settings	Makes a planned agent guardrail enforceable
4	Default token permissions to read	Four settings	Needs a check that nothing breaks

Not established

The organisation-level Actions policy hasn't been read — that needs admin:org, which I don't have. It could constrain or override any of the repo-level settings above, so worth checking before acting on 2–4.

Also worth a sanity check by someone who knows the repos: whether runs-on accepts expressions and which contexts are available at job level isn't documented in GitHub's workflow-syntax reference, which matters if we later want conditional runner selection.

Context and working are in the private project-compute planning repo (research/2026-07-30-gpu-ci-settings-audit.md).

🤖 Generated with Claude Code

[mmcky]

Correction: item 1 was wrong — please don't action it as written

Item 1 above recommends flipping spot=false → spot=true. That is wrong and should not be done. I missed #330 when writing this.

spot=false is a deliberate org-wide decision, taken on 2026-06-26 in #330: AWS spot reclamation was interrupting GPU notebook builds mid-run — a lecture-jax cache build was killed at 91% of execution — and because these are single-GPU builds of 15–25 minutes that can't cheaply checkpoint, a late reclamation discards the whole run and any spot saving with it. Option 2 (on-demand for all GPU builds) was chosen explicitly over keeping spot. Reverting that would reintroduce a failure the org has already diagnosed and fixed.

I read the config value and inferred an oversight without checking whether a decision existed. Apologies for the noise.

What the audit actually found: the #330 rollout is incomplete

The measurements hold, they just mean the opposite of what I wrote. Read as rollout status against #330's own table:

Repo	Target workflows	spot=false set	Status
lecture-jax	cache, ci, collab, publish	4 / 4	✅ done (#327)
lecture-python.myst	cache, ci, collab, publish	4 / 4	✅ done since #330 was written
lecture-python-programming	cache, ci, publish	2 / 3	⚠️ publish.yml still missing
lecture-stats	cache, ci, collab, publish	0 / 4	❌ pending
iuj_feb_2026	ci, publish	0 / 2	❌ pending

RunsOn defaults spot to true, so those seven unset workflows are running on spot today and exposed to exactly the reclamation failure #330 describes. The action is to add spot=false, not remove it.

Volume context, measured from the Actions API over 2026-01-31 → 2026-07-30: the seven exposed workflows are only 2% of GPU wall-clock (5.4 of 251.3 hours), because lecture-stats and iuj_feb_2026 are both nearly dormant. So the reliability exposure is real but small, and the two repos with real volume are already correctly on on-demand.

One trap worth recording for whoever picks this up: RunsOn tries spot first and falls back to on-demand when spot capacity is unavailable, at a 2–3 second launch penalty. That is a launch-time protection and does nothing about mid-run reclamation, which is the actual failure mode. Reading that fallback as safety is part of how spot looked free to me.

Revised item list

	Item	Change
1	Flip spot=false → spot=true → Finish the #330 rollout: add spot=false to the 7 workflows above	Inverted
2	Fork-PR approval → all_external_contributors	unchanged
3	Disable Actions approving PRs	unchanged
4	Default token permissions → read	unchanged

Items 2–4 are unaffected — they're straightforward hardening and the reasoning above doesn't touch them.

Also flagging #330's own still-open follow-up, which is the durable fix and better than patching repos by hand: codify on-demand in QuantEcon/actions so new GPU-using repos inherit it. And #330 suggests tracking reclamation frequency under #328 — the audit numbers here would give that a baseline.

[mmcky]

Status 2026-08-05 — item 1 in PRs, item 4's check answered

Item 1 (finish the #330 rollout): PRs open covering all seven exposed workflows — QuantEcon/lecture-stats#52 (all four), QuantEcon/iuj_feb_2026#6 (both), QuantEcon/lecture-python-programming#603 (publish.yml). Each appends /spot=false to the runs-on string, matching the pattern already in lecture-jax and lecture-python.myst. Settings were re-read across all five repos first: nothing has moved since the 2026-07-30 audit.

Item 4 (default token → read): the "needs a check that nothing breaks" check is done, by reading every workflow file for permissions: blocks and default-token write usage.

Repo	Verdict	Why
lecture-jax	Safe to flip now	Every writing workflow already carries an explicit block; cache.yml/collab.yml without blocks only read
lecture-python.myst	Safe to flip now	Same — ci/publish/collab/linkcheck all carry blocks; cache.yml only reads
lecture-python-programming	Not yet	ci.yml uses the default token for Netlify PR feedback with no block — needs contents: read + pull-requests: write first (the block lecture-jax/ci.yml already has)
lecture-stats	Not yet	No permissions: block in any workflow. publish.yml pushes gh-pages on the default token (would break outright); ci.yml/collab.yml Netlify feedback would degrade; linkcheck.yml likely needs issues: write like its siblings

The missing blocks are transcriptions of what the sibling repos already carry, so the path is: add them, then flip all four repos to read.

Items 2 and 3 remain — the five-click settings changes (all_external_contributors, disable Actions-approves-PRs). The API endpoints are PUT /repos/{owner}/{repo}/actions/permissions/fork-pr-contributor-approval and PUT .../actions/permissions/workflow, so a qe gh sweep covers them; they could not be completed from this session's tooling.

Still unread: the org-level Actions policy (403 without admin:org) — worth a look before the item-4 flips in case it overrides repo settings.

Working notes: project-compute research/2026-08-05-meta347-execution-and-token-check.md. Incidental: pushing to lecture-stats surfaced its open high-severity Dependabot alert (dependabot/4).

🤖 Generated with Claude Code

[mmcky]

Item-4 preparation PRs are open: QuantEcon/lecture-stats#53 (blocks for ci, collab, publish) and QuantEcon/lecture-python-programming#605 (block for ci). One correction to the table above: lecture-stats/linkcheck.yml was verified and needs no block — unlike its siblings it creates no issues, only uploads a report artifact. Once these two merge, all four write-default repos are safe to flip to read. Item 1 is merged everywhere except lecture-stats#52, which completes the #330 rollout when it lands.

🤖 Generated with Claude Code