Context
While auditing GitHub Actions spend for dupmachine, I found that dupmachine/ground-control (private) burned ~2559 minutes of Actions Linux ($0.006/min) in August — the first month it went over the 2000 free-minute quota (net $0.732). The dominant cost is three cron workflows (collect-issues-agenda, collect-issues-clarification, collect-pull-requests-agenda) that call this repo's shared workflows every 2 hours.
Non-obvious billing fact, confirmed directly in the org billing usage export: even though starcast is public, minutes for a workflow_call job are billed against the calling repo, not the repo hosting the reusable workflow. So this repo's runner choice affects private callers' cost even though starcast itself never pays for its own Actions minutes.
Finding
collect-issues-shared.yml, collect-pull-requests-shared.yml, and route-issue-shared.yml each run a single composite step (shell: bash → python3 .../script.py), calling GitHub's API via gh/GraphQL. No Docker, no privileged filesystem operations, no matrix. That fits GitHub's new ubuntu-slim runner (1 vCPU / 5 GB RAM, $0.002/min vs $0.006/min — 3.33x cheaper), whose only real constraints are unprivileged mode (no Docker-in-Docker, no fs mounts) and a 15-minute job timeout.
Proposal
Switch runs-on: ubuntu-latest → runs-on: ubuntu-slim in:
.github/workflows/collect-issues-shared.yml.github/workflows/collect-pull-requests-shared.yml.github/workflows/route-issue-shared.yml
Alternative if you'd rather not force it org-wide: add a runner input to each (type: string, default: ubuntu-latest) so callers can opt into ubuntu-slim individually.
Caveat
I haven't measured actual runtime/memory footprint at scale (e.g. collecting issues across a large org with many repos) — worth a trial run to confirm it stays within slim's 5 GB RAM / 15-minute budget before merging, especially for orgs with a lot of open issues/PRs.
Context
While auditing GitHub Actions spend for
dupmachine, I found thatdupmachine/ground-control(private) burned ~2559 minutes ofActions Linux($0.006/min) in August — the first month it went over the 2000 free-minute quota (net $0.732). The dominant cost is three cron workflows (collect-issues-agenda,collect-issues-clarification,collect-pull-requests-agenda) that call this repo's shared workflows every 2 hours.Non-obvious billing fact, confirmed directly in the org billing usage export: even though
starcastis public, minutes for aworkflow_calljob are billed against the calling repo, not the repo hosting the reusable workflow. So this repo's runner choice affects private callers' cost even thoughstarcastitself never pays for its own Actions minutes.Finding
collect-issues-shared.yml,collect-pull-requests-shared.yml, androute-issue-shared.ymleach run a singlecompositestep (shell: bash→python3 .../script.py), calling GitHub's API viagh/GraphQL. No Docker, no privileged filesystem operations, no matrix. That fits GitHub's newubuntu-slimrunner (1 vCPU / 5 GB RAM, $0.002/min vs $0.006/min — 3.33x cheaper), whose only real constraints are unprivileged mode (no Docker-in-Docker, no fs mounts) and a 15-minute job timeout.Proposal
Switch
runs-on: ubuntu-latest→runs-on: ubuntu-slimin:.github/workflows/collect-issues-shared.yml.github/workflows/collect-pull-requests-shared.yml.github/workflows/route-issue-shared.ymlAlternative if you'd rather not force it org-wide: add a
runnerinput to each (type: string,default: ubuntu-latest) so callers can opt intoubuntu-slimindividually.Caveat
I haven't measured actual runtime/memory footprint at scale (e.g. collecting issues across a large org with many repos) — worth a trial run to confirm it stays within slim's 5 GB RAM / 15-minute budget before merging, especially for orgs with a lot of open issues/PRs.