Guides
How to run CI on a very large repository
Checkout, indexing and status reporting all degrade as the repository grows.
6 min read
Checkout, indexing and status reporting all degrade as the repository grows.
Why it happens
Git operations scale with object count and working-tree size, and CI repeats them on every job.
How to fix it
- Partial clone with blob:none and sparse checkout for the paths a job needs
- Cache the git object store between runs where the provider supports it
- Split the pipeline so only affected projects build
- Use local NVMe runners — git on network storage is painful at scale
Your next build could be twice as fast, at half the price
Start free. Migrating away is the same one line, and we publish that diff too.
Related
How to speed up GitHub ActionsYour pipeline takes longer than anyone wants to wait, and it is not obvious where the time goes.How to find the slow step in a workflowThe pipeline is slow but every individual step looks reasonable.How to reduce GitHub Actions cold startsJobs sit for 30 to 90 seconds before the first step runs.How to diagnose GitHub Actions queue timesJobs are queued for minutes before a runner picks them up.