Documentation
CIPatch finds waste in GitHub Actions, opens one conservative pull request, and then measures whether merging it actually saved anything.
How it works
- Read. With read-only access, CIPatch records billed minutes per run, per job, per runner from your Actions history.
- Analyse. Deterministic rules look for supported waste patterns. A rule must pass every precondition before it may propose anything, and an ambiguous repository abstains.
- Propose. One change, one workflow file, one draft pull request, with the evidence, a saving range, the risk and a rollback line.
- Measure. After you merge, CIPatch compares comparable runs and reports one of four honest verdicts.
The four verdicts
| Verdict | Meaning |
|---|---|
| Verified saving | The difference is outside the noise band and material. This is the only state that is billed. |
| No material change | Measurable, but smaller than the materiality threshold. |
| Regression | CI got measurably more expensive. It costs you nothing, and it teaches the rule set. |
| Insufficient evidence | Not enough comparable runs yet, or the runner or trigger changed so the windows cannot be compared. |
Comparison is on billed minutes per run, never dollars, so a GitHub price change can never be mistaken for a saving. A verdict needs at least 10 comparable runs over at least 14 days on each side of the merge.
What CIPatch reads
- Workflow files under
.github/workflows/and the dependency manifests needed to recognise a safe cache recipe. - Actions metadata: runs, jobs, runner labels, step names, timings and conclusions.
It does not read repository secrets, Actions logs, or application source code. See the privacy policy.
Permissions and why
| Permission | Why |
|---|---|
| Metadata (read) | Mandatory for any GitHub App; resolves repository identity. |
| Actions (read) | The cost baseline and the post-merge measurement. |
| Contents (read) | Workflow YAML and lockfiles. |
| Contents (write) | Commit one patched workflow file to a new branch. |
| Pull requests (write) | Open one draft pull request, and post the verdict on it. |
| Workflows (write) | GitHub requires this to commit anything under .github/workflows/. |
Write access is used by exactly one module (github-write.js): branch, one file, draft pull request. No force pushes, no merges, no deletions, no changes to any other file.
Frequently asked
Will it change my application code?
No. It edits workflow YAML only, one file per pull request, and never touches tests, secrets or deployments.
Why did it find nothing in my repository?
That is a normal result. A rule proposes only when every precondition passes, and a repository with no supported waste pattern correctly gets nothing rather than a speculative change.
Why is the saving a range?
Before a merge it is a projection from your history or from stated assumptions. After a merge it is measured, and the measurement is reported whatever it says.
How is the bill calculated?
A flat monthly price, and a period in which no saving is verified is not charged for. Every figure before a merge is an estimate, and every figure after it is a measurement from comparable runs, taken at the conservative end of the range. See pricing.
Can I export everything?
Yes. Every finding, outcome and payment is exportable. The first scan works without an account; a free account adds five public scans a month and three repositories analysed from their real run history.
No account for the first scan, no card, and it changes nothing.