Brimyr — patch-coverage gating for pull requests
Quality assurance for a pull request. Brimyr gates on the coverage of the lines that PR changed, and on the quality findings it introduced. Point it at any repo and it works out the rest.
Gate the change. Leave the backlog alone.
Requiring 80% coverage on a whole legacy codebase is a non-starter; ignoring new code lets it rot. Brimyr holds what a PR changed to a bar, twice over, and leaves the back-catalogue alone both times.
Two gates, one comment
Coverage and quality run in the same job and land in the same pull-request comment, updated in place. The job exits on the worse of the two.
Patch coverage, not project
The coverage gate is the executable lines this PR changed, diffed against the merge-base. A repo sitting at 61% never fails a well-tested change.
Net-new quality findings
Turn on quality: 'true' and the second gate counts the lint
findings this PR introduced, against that same diff. Pre-existing findings
are shown and never block.
Report-only until you say so
quality_fail_on defaults to none on purpose. A
first run that goes red with hundreds of findings is how a gate becomes
decoration. Measure a release cycle, then pick a level.
It detects the ecosystem and runs your tests
Python, JavaScript/TypeScript, .NET and Java. No bring-your-own coverage report: Brimyr picks the right command with instrumentation on, and merges one report per language for polyglot repos.
A broken run is never a pass
A failed or empty test run is a tool error, not 0%. A quality scan that did not finish is reported as an error rather than a clean row of zeros. Small diffs are exempt and say so.
Brimyr is quality assurance; Chargate is security assurance. Twins, not competitors, and the line between them is the subject rather than the tool: Chargate owns net-new security findings, Brimyr owns coverage and net-new quality. So Brimyr's quality half does not reimplement any of it, it calls Chargate as a nested step and reads what that run leaves behind. Chargate reports, Brimyr decides. A repo wants both.
One action. That is the whole config.
On PRs it runs your tests with coverage, gates on patch coverage, and posts one
comment updated in place. Add quality: 'true' and the same comment
carries the net-new quality findings too. On push to the default branch it runs
a non-gating baseline that still feeds the trend.
steps: # Brimyr checks out with fetch-depth: 0 by default; # patch coverage needs the merge-base. - uses: magmamoose/brimyr@v1 with: threshold: '80' # blocks on patch coverage quality: 'true' # adds the net-new quality gate # quality_fail_on: none (the default: report, do not block) # sonar_url: https://sonar.example.com (optional, non-blocking)
Gate the change. Not the debt.
Free and open source, Apache-2.0 licensed. Runs entirely on your runner, with no server to host and no SaaS account.