feat(preprod): Add snapshot auto-approval for repeated PR builds#112421
feat(preprod): Add snapshot auto-approval for repeated PR builds#112421NicoHinderling merged 9 commits intomasterfrom
Conversation
…of using empty strings
1f01f62 to
4023b4b
Compare
|
🚨 Warning: This pull request contains Frontend and Backend changes! It's discouraged to make changes to Sentry's Frontend and Backend in a single pull request. The Frontend and Backend are not atomically deployed. If the changes are interdependent of each other, they must be separated into two pull requests and be made forward or backwards compatible, such that the Backend or Frontend can be safely deployed independently. Have questions? Please ask in the |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 8a77ec7. Configure here.
…comparison Wrap _try_auto_approve_snapshot in try/except so an unhandled exception doesn't propagate to the outer BaseException handler, which would incorrectly mark an already-successful comparison as FAILED.
Replace raw tuple[str, ...] with a typed ImageFingerprint NamedTuple for better readability of the name, status, hash, and previous_image_file_name fields in snapshot auto-approval fingerprints. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…2421) Closes EME-976 Adds auto-approval logic for snapshot comparisons. When a snapshot build on a PR is approved and a subsequent build is uploaded for the same PR (e.g. after a rebase), the new build is automatically approved if its "interesting" images (changed, added, removed, errored, renamed) match the previously approved build — same image names, same categories, and same content hashes. This addresses a pain point where rebasing a PR would pull in new unchanged images from main, causing the snapshot comparison to lose its approval even though the PR's actual visual changes hadn't changed. Users were forced to re-approve identical snapshots after every rebase. The old Emerge implementation required an exact one-to-one match of ALL images between builds, which broke on rebases. The new approach only compares the non-unchanged subset, so new unchanged images from main don't affect auto-approval. Content hashes are still verified to ensure the PR's actual visual output hasn't changed. The matching scopes to the same project, app_id, build_configuration, PR number, and repo name to prevent cross-build false matches. how the UI looks for an auto-approved snapshot <img width="1726" height="1744" alt="CleanShot 2026-04-07 at 15 45 02@2x" src="https://github.com/user-attachments/assets/e9a01fc0-5a0f-47ef-880d-a4c69f963be2" /> --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

Closes EME-976
Adds auto-approval logic for snapshot comparisons. When a snapshot build on a PR is approved and a subsequent build is uploaded for the same PR (e.g. after a rebase), the new build is automatically approved if its "interesting" images (changed, added, removed, errored, renamed) match the previously approved build — same image names, same categories, and same content hashes.
This addresses a pain point where rebasing a PR would pull in new unchanged images from main, causing the snapshot comparison to lose its approval even though the PR's actual visual changes hadn't changed. Users were forced to re-approve identical snapshots after every rebase.
The old Emerge implementation required an exact one-to-one match of ALL images between builds, which broke on rebases. The new approach only compares the non-unchanged subset, so new unchanged images from main don't affect auto-approval. Content hashes are still verified to ensure the PR's actual visual output hasn't changed.
The matching scopes to the same project, app_id, build_configuration, PR number, and repo name to prevent cross-build false matches.
how the UI looks for an auto-approved snapshot
