|
| 1 | +# Why visible CI evidence matters |
| 2 | + |
| 3 | +Our repository already runs GitHub Actions and uploads coverage to Codecov. Those badges are useful because they point to the |
| 4 | +latest pipeline results, but they do not replace in-repo evidence of how the project is validated. Having local documentation of |
| 5 | +our automation brings several benefits: |
| 6 | + |
| 7 | +1. **Discoverability for contributors.** Newcomers who clone the repository often work offline or from mirrors where external |
| 8 | + dashboards are unavailable. A local reference helps them understand how to reproduce the checks without chasing links or |
| 9 | + needing network access. |
| 10 | +2. **Reproducible workflows.** When the CI definition files live only in external systems, it is impossible to guarantee that the |
| 11 | + codebase can be validated independently. Keeping the workflow files, scripts, and configuration versioned in the repo makes |
| 12 | + the project self-contained and allows reviewers to audit the exact commands that gate merges. |
| 13 | +3. **Traceability over time.** Badges surface only the most recent status. If the external pipelines change behaviour—or the |
| 14 | + external service goes away—we lose the historical context. Documenting the CI entry points (e.g. workflow YAML, coverage |
| 15 | + commands) in the repository ensures the validation story survives platform migrations. |
| 16 | +4. **Security and trust.** Reviewers and users can inspect in-repo CI definitions to verify that the advertised checks are the |
| 17 | + ones actually executed. This transparency is a core expectation for open-source projects; otherwise, the project depends on a |
| 18 | + third-party configuration that might drift without review. |
| 19 | +5. **Onboarding automation.** A repository-local description of the CI makes it trivial to run the same checks locally (for |
| 20 | + example via `make` targets or scripts). This keeps feedback fast and reduces breakages that only surface after pushing to the |
| 21 | + remote pipelines. |
| 22 | + |
| 23 | +In short: keeping CI evidence—workflow YAML, scripts, and documentation—inside the repository is not redundant with using |
| 24 | +GitHub Actions or Codecov. It is the foundation that makes those services trustworthy, reproducible, and accessible to every |
| 25 | +contributor. |
0 commit comments