Running Github Actions Efficiently
Cut GitHub Actions minutes and wall-clock time without losing coverage, the OS billing...
Install
npx skills add kajisho5/ffmpeg-skill --skill running-github-actions-efficiently -g -a claude-code -y- Repository
- kajisho5/ffmpeg-skill4.3k
- Category
- Git and review
- Updated
- 4d ago
- License
- MIT
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Cut GitHub Actions minutes and wall-clock time without losing coverage, the OS billing multiplier (macOS 10x / Windows 2x / Linux 1x), trigger hygiene that stops push+pull_request double-firing, concurrency that cancels superseded runs, dependency caching keyed on lockfiles, matrix discipline, and auditing scheduled crons that bill 24/7. Use when CI is burning included minutes, when runs feel slow, when setting up a new repo's workflows, or when reviewing an existing workflow for waste.
Running GitHub Actions Efficiently
Actions minutes on private repos bill against a monthly included quota; public repos are free. So cost concentrates in private repos, and a handful of workflows usually dominate the bill. This skill is the checklist for finding and fixing that waste. Every fix below preserves what CI actually verifies, none of them trade away coverage.
First, know the one number that dominates everything
Minutes are billed per job, rounded up to the minute, times a runner-OS multiplier:
| Runner | Multiplier |
|---|---|
Linux (ubuntu-*) | 1x |
Windows (windows-*) | 2x |
macOS (macos-*) | 10x |
A one-minute macOS job costs the same as ten Linux minutes. This single fact reorders every optimization: a repo with a few macOS jobs can outspend a repo with ten times as many Linux jobs. Before anything else, find your macOS jobs and ask of each: does this step genuinely need macOS?
- Xcode / Apple-platform builds and tests (
xcodebuild): yes, macOS is required. - Linters and formatters (even Swift ones like SwiftLint/SwiftFormat), pure
unit tests with no Apple frameworks, packaging, doc builds: usually no, move them to
ubuntu-latestand cut that job's cost ~10x.
Split the must-be-macOS work into its own job and push everything else to Linux.
If a single macOS job does both (e.g. runs SwiftLint and an Xcode build), split
it: a cheap Linux lint job plus the macOS build job. The tools only parse
source, so the Linux job just checks out and runs them, no toolchain build.
SwiftLint and SwiftFormat both ship self-contained prebuilt Linux binaries, so "Swift means macOS" is a myth for the linting half of the pipeline:
