How it works

mrsentry runs as a job in your GitLab pipelines. Merge request pipelines review the change and fix it. Scheduled pipelines just fix.

Merge request pipeline

Runs on every push to a merge request. It takes about one to two minutes for a typical change.

1. 01Load the merge requestGitLab API

   Reads the MR and its latest diff version, so every comment lands on the right line.

   Details

   • The diff version supplies the base, start and head commits GitLab uses to position comments.
   • Every page of diffs is read. Files GitLab truncates as too large are diffed locally instead.
   • If a push has just landed, it waits for GitLab to finish computing the new diff.
2. 02Check out the exact commit

   Works from the full repository at the MR head, not just the diff.

   Details

   • In CI it reuses the job's checkout ($CI_PROJECT_DIR). Elsewhere it clones.
   • The token goes in an HTTP header, never in the URL or logs.
   • It confirms HEAD is the commit being reviewed.
3. 03Scan the container imageoptional

   Pulls High/Critical CVEs from ECR and traces each one to the dependency that brings it in.

   Details

   It reads how the repository is scanned (basic or enhanced, on push or continuous) and checks whether the results are fresh enough to trust. ECR scanning has the details.

4. 04Review the changeAI

   Reviews risky files first, checks claims with repository tools, and drops anything it can't back with evidence.

   Details

   • Auth, crypto, SQL, payment and I/O code goes first, then the largest changes.
   • The model can read files, grep and look up symbols, all read-only.
   • Each finding must quote the real line. A critic pass removes noise and duplicates.

   AI code review covers every step.

5. 05Publish to the MR

   Inline threads plus one overview note, posted in a single batch so watchers get one notification.

   Details

   • A comment GitLab can't place inline falls back to a file comment, then to the overview.
   • Threads whose issue is gone are resolved. The overview is edited in place, never reposted.
   • If someone pushed during the run, it stops (exit code 2) instead of commenting on old lines.
6. 06Hand off the fix

   If something is fixable, it starts a child pipeline that pushes the fix into this MR.

   Details

   It writes mrsentry-out/fix-pipeline.yml. That file holds either a mrsentry:fix job or a no-op job that states why nothing is needed.

Scheduled pipeline

Runs nightly, or whenever you schedule it. No review, just one fix MR that stays up to date.

1. 01Clone the target branch

   Starts from your default branch, or the one you choose.

   Details

   Set it with fix.target_branch or --target-branch.

2. 02Scan the latest image

   Without a tag, it picks the newest image for you.

   Details

   ecr.tag_strategy picks the most recently pushed image (default) or the highest semver tag. ecr.tag_filter limits the candidates.

3. 03Fix and verify

   Upgrades the dependencies, regenerates lockfiles and proves the vulnerable versions are gone.

   Details

   This is the same engine as the MR fix, including your build and tests. See Vulnerability fixing.

4. 04Open or refresh one MR

   One MR per set of CVEs. Re-runs update it, and a newer set closes the older MR.

   Details

   The branch is mrsentry/vuln-fix/<image>-<fingerprint>, so the same set of CVEs always maps to the same branch and MR.

Built in