Integrating Repair Pull Requests into Your Release Cadence

Audits that stop at the report

Teams run static analysis, dependency scans, or custom rule sets. The tool produces a list of violations. The list lands in a ticket. No code changes follow.

The audit investment disappears at that point. The failure mode is a report‑only audit. The cost is a documented problem that never becomes a shipped fix.

From report to repair pull request

A repair pull request (repair PR) is a PR that contains only the changes required to satisfy the audit. It is generated automatically from the audit output. The PR is opened against the same branch that will be released.

The correct posture is to treat the repair PR as part of the same change set that the release pipeline already validates. When the PR merges, the audit’s finding disappears from the code base. The audit therefore becomes a source of continuous remediation, not a one‑off report.

Scheduling the repair PR before the next release

A release cadence is a predictable interval – weekly, bi‑weekly, or monthly. If a repair PR lands after the cut‑off, it will be deferred to the following cycle. That defeats the purpose of “audit‑to‑repair”.

The pipeline must enforce a repair window that ends a few hours before the release tag is created. During that window the CI system runs the audit, generates the repair PR, and waits for the PR to be merged. Only when the merge succeeds does the release job proceed.

Minimal CI changes to achieve continuous remediation

1. Add a dedicated audit stage

Insert a step that runs the audit tool and writes its findings to a known artefact directory. The step must exit with success even if violations are found – the next stage will handle them.

1. Generate the repair PR

Use the SHPBL library’s offline edition (or the HTTP API) to translate the artefact into a diff. A short script creates a branch, applies the diff, and pushes it. The script then calls the repository’s API to open a PR with a deterministic title, e.g. audit/repair‑2024‑09‑16.

   # Example snippet
   audit-output=/tmp/audit.json
   diff=$(shpbl generate-diff --input $audit-output)
   git checkout -b audit/repair-$(date +%F)
   echo "$diff" | git apply
   git commit -am "Repair audit findings"
   git push origin HEAD
   curl -X POST -H "Authorization: token $GH_TOKEN" \
        -d '{"title":"audit/repair","head":"audit/repair-$(date +%F)","base":"main"}' \
        https://api.github.com/repos/owner/repo/pulls

1. Gate the release on PR merge

The release job must depend on the merge status of the repair PR. A simple poll or a webhook can set a CI variable REPAIR_MERGED=true. If the variable is false when the release window closes, the pipeline aborts and raises a failure.

1. Record the outcome

Feed the certification harness (see the /harness page) with the merged commit. The harness will label the artifact as CERTIFIED if the repair PR resolves all reported violations, or PROVISIONAL if the audit still flags issues.

These four steps keep the pipeline linear. No separate “audit‑only” job runs after the release tag. All remediation happens before the tag, preserving the cadence.

What to do on Monday

Open your CI configuration. Add an audit stage that writes its output to a file. Add a script that calls the SHPBL offline tool to turn that file into a PR. Configure the release job to wait for the PR to merge, and to abort if it does not.

Commit the changes, push them to a feature branch, and run the pipeline manually. If the pipeline produces a repair PR and the release job proceeds, you have closed the audit loop for this cycle.

The next release will contain the repaired code, not a stale report. That turns the audit from a cost centre into a reusable asset.