Large Repositories, Monorepos, Search, Actions Cost Controls, and Platform Performance: Configuration, Design Choices, and Tradeoffs

1. Configuration begins with the boundary you want to own

There is no universal “monorepo is faster” or “multi-repo is cleaner” answer. Repository boundaries determine permission scope, ruleset scope, release independence, search scope, issue/PR workflow, dependency change coordination, and the failure radius of automation. The correct design is the one whose governance boundaries match the product.

2. Monorepo versus multi-repo

A useful heuristic: if components need hard confidentiality/administrative isolation or radically independent lifecycle, separate repositories are often more honest. If teams make frequent atomic cross-component changes and share one policy/release surface, a monorepo can be efficient—provided CI and ownership are engineered rather than improvised.

3. Normal Git blobs versus LFS, packages, releases, and external storage

The decision should answer “who consumes this, how is it versioned, how long is it retained, and what provenance must be verified?” before it answers “where can I upload it?”

4. Separate local, cross-cutting, and policy validation

Path-aware CI is safest when jobs are classified:

• Component-local: unit tests/lint for one directory.
• Cross-cutting: shared libraries, schemas, lockfiles, base images, global build config, workflow changes.
• Always-run policy gate: cheap router and aggregate signal that proves the routing decision itself executed.

Do not require a component workflow that sometimes never starts because a top-level path filter skipped it. Require the stable gate that starts on every relevant PR and understands intentional skips.

5. Choose checkout semantics per job

actions/checkout supports sparse checkout, configurable fetch depth, and optional LFS fetching. Use those controls because the job's data requirements justify them—not as a blanket “performance recipe.”

6. Runner size and concurrency: throughput is not the same as cost efficiency

A larger runner can shorten a CPU-bound job, but it can also cost more per minute and hide inefficient parallelization. Current GitHub larger runners are an organization/enterprise feature for Team/Enterprise Cloud and are billable; included standard-runner minutes do not apply to them. For the mandatory path, stay on standard public runners.

7. Cache and artifact retention are different policies

A cache exists to accelerate a future run and should tolerate eviction. An artifact exists because somebody needs an output or evidence. Confusing them creates expensive, unreliable designs. Cache keys should have controlled cardinality and useful hit rates. Artifacts should have an owner, consumer, and retention period.

Current GitHub defaults include a 10 GB cache allowance per repository and eviction for entries unused for more than seven days. Artifact/log retention defaults to 90 days, with public repositories configurable down to one day. Optional higher cache size/retention settings require eligible billing/plan configuration, so they are not part of the mandatory lab.

8. Feature and plan boundaries

9. Worked design: a 70-team product platform

Suppose one product platform contains 40 services, six client applications, shared schemas, and common build tooling. Teams need atomic schema migrations, but payroll and security components require separate confidentiality. A sensible design may be hybrid:

1. Keep ordinary product services sharing one release/governance cadence in a monorepo.
2. Keep confidential or independently administered components in separate repositories.
3. Model shared/, schema registries, lockfiles, and workflow changes as cross-cutting dependencies.
4. Use team-oriented CODEOWNERS for human review, not thousands of user lines.
5. Use one always-run router/gate and selective component jobs.
6. Store release binaries/packages outside Git history, with immutable identity/provenance.
7. Track cost per successful PR and storage growth, not raw workflow count alone.

This design accepts a little orchestration complexity to preserve real authorization and lifecycle boundaries.

10. Summary

Platform configuration is about aligning repository boundaries, artifact lifecycles, validation classes, checkout depth, runner choice, concurrency, and retention with actual requirements. Lesson 4 now deliberately breaks these assumptions and diagnoses the evidence.

Knowledge check

Further reading — current primary sources

• Repository limits
• About large files on GitHub
• About Git Large File Storage
• Triggering workflows and path-filter behavior
• Dependency caching reference
• GitHub Actions billing
• Understanding GitHub Code Search syntax
• REST API — rate limits