# Brimyr — patch-coverage gating for pull requests

> Brimyr gates a pull request on the coverage of the lines it changed and on the quality findings it introduced. One action, one job, one comment. No SaaS.

Canonical: <https://www.magmamoose.com/brimyr/> · Last updated: 2026-09-23

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.

v1 · Marketplace · Apache-2.0 · two gates, one comment

- [Get it on the Marketplace](https://github.com/marketplace/actions/brimyr)
- [Quickstart](https://www.magmamoose.com/brimyr/#quickstart)

a Magma Moose product · Apache-2.0 open source

*what it does*

## 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](https://www.magmamoose.com/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.

*quickstart*

## 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.

1. Add the action · 2. Pick a threshold · 3. Turn on quality · 4. Open a PR

.github/workflows/coverage.yml:

```yaml
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.

- [Get it on the Marketplace](https://github.com/marketplace/actions/brimyr)
- [View the source](https://github.com/MagmaMoose/brimyr)

## Links

- [Brimyr: Docs](https://docs.magmamoose.com/brimyr/)
- [Company: Contact](mailto:hello@magmamoose.com)
- [Company: LinkedIn](https://www.linkedin.com/company/magmamoose)