Skip to content

Commit c52e3e0

Browse files
Add documentation on keeping CI evidence in repo
1 parent 5cadc96 commit c52e3e0

File tree

1 file changed

+25
-0
lines changed

1 file changed

+25
-0
lines changed

docs/ci_evidence.md

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,25 @@
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

Comments
 (0)