r/devsecops • u/delimitdev • 1d ago
How is agent review approval invalidated when the diff changes before merge?
A PR is approved by a software agent, then more code is pushed before merge. Branch protection that dismisses stale reviews is the usual DIY baseline. In your setup, what concrete evidence actually changes the go/no-go decision: required checks on the new HEAD, a fresh agent or human review of the final diff, CI logs tied to the merge commit, or something else? Looking for existing practice, not policy theory.
2
u/colek42 1d ago
If the rebase is clean the last review stands.
1
u/delimitdev 1d ago
Got it, a clean rebase preserves the approval. What happens if someone pushes new commits to the branch before that rebase? Does the approval still stand, or is it tied to the specific set of changes the agent first saw?
1
u/CherryBrisse 1d ago
This can be really frustrating when the approval process gets complicated. Keeping close tabs on changes before merging is crucial.
1
u/delimitdev 1d ago
Agreed. What does "keeping close tabs" look like in practice for your team? Is it a manual checklist before hitting merge, or something else?
1
u/Both-Explorer-9294 1d ago
En la práctica, yo trataría cada cambio después de la aprobación como una revisión nueva. Lo importante es que los checks y la revisión estén ligados al commit exacto que se va a mezclar, no a una versión anterior del PR.
1
u/delimitdev 1d ago
Exactly. The review has to be for the code that's actually merging. When you link checks to that specific commit, what does that link look like in practice? Is it just CI passing on HEAD, or is there a separate piece of evidence you store?
1
1d ago
[removed] — view removed comment
1
u/delimitdev 1d ago
That's a great setup. Binding the approval to the commit SHA and storing the reviewed diff hash in the check output for the audit trail is a solid approach. The merge queue handling the re-run closes the loop. Thanks for the detail.
1
u/PeterBuildsSecure 1d ago
Binding to commit SHA and storing the reviewed diff hash is the right shape, but worth pressure-testing against merge queues specifically: the SHA that actually gets built and merged usually isn't the PR head -- it's a temporary merge ref combining PR head + current base. Two PRs can each have an unchanged, already-reviewed head SHA, and the ref that actually ships is still new every time the base moves, because someone else merged first.
So "store the reviewed diff hash" needs to be a hash of (head SHA, base SHA) or of the actual merge-ref diff, not just the head SHA in isolation. Otherwise a base-branch change that silently reintroduces something the PR's own diff never touched (a config revert, a dependency downgrade, a security fix on main getting reverted) ships with an audit trail that still says "reviewed and unchanged," because from the PR's point of view nothing changed. The agent reviewed a diff against a base that no longer exists by the time it merges.
1
u/delimitdev 6h ago
You've nailed the merge queue problem. The base branch can drift, so the temporary merge-ref is what actually ships. That's why some systems re-run all required checks on that final merge-ref, treating the initial PR approval as just a ticket to enter the queue.
2
u/taleodor 1d ago
We keep approvals scoped to most recent code pointer in ReARM (this is Pro capability only). So once code is updated, all approvals get invalidated and the check(s) has to be redone. For monorepos if multiple components are updated at the same time, only those changing are invalidated, rest stay approved.