ci: required chromatic approvals on merges

[speaker-ender]

Ticket []

Description Of Changes

Adds a requirement to approve changes to storybook components before merging.

Code Changes

Steps to Confirm

Pre-Merge Checklist

• Issue requirements met
• All CI pipelines succeeded
• CHANGELOG.md updated
  • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
  • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change (i.e. potential for performance impact or unexpected regression) that should be flagged
  • Updates unreleased work already in Changelog, no new entry necessary
• UX feedback:
  • All UX related changes have been reviewed by a designer
  • No UX review needed
• Followup issues:
  • Followup issues created
  • No followup issues
• Database migrations:
  • Ensure that your downrev is up to date with the latest revision on main
  • Ensure that your downgrade() migration is correct and works
    • If a downgrade migration is not possible for this change, please call this out in the PR description!
  • No migrations
• Documentation:
  • Documentation complete, PR opened in fidesdocs
  • Documentation issue created in fidesdocs
  • If there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry
  • No documentation updates required

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
fides-plus-nightly	Ignored	Preview	Mar 26, 2026 6:59pm
fides-privacy-center	Ignored		Mar 26, 2026 6:59pm

[claude]

Code Review — Chromatic CI enforcement

This PR makes Chromatic a blocking check by setting exitZeroOnChanges: false and adds environment variables to help Chromatic correctly identify the branch/commit being tested. The goal is sound — keeping main visually clean by requiring approval of any storybook changes before merge.

Critical (Must Fix)

CHROMATIC_SHA uses github.ref as a fallback, which is not a SHA (see inline comment). For push-to-main and release branch runs, this passes a ref string like refs/heads/main to Chromatic instead of a commit hash, which will likely cause Chromatic to fail to associate the build correctly. Should be github.sha.

Suggestions

Checkout uses branch name instead of commit SHA (see inline comment). github.event.pull_request.head.ref is a branch name — checking out by name rather than by head.sha introduces a race condition where a concurrent push can cause the job to test a different commit than the one that triggered it. Using head.sha is the safer, deterministic approach Chromatic recommends.

Nice to Have

• The exitZeroOnChanges: false comment says "Fail workflow if changes are found" — it may be worth clarifying that this means unreviewed visual changes, not any diff changes, so future readers aren't confused about what triggers a failure.

[greptile-apps]

Greptile Summary

This PR updates the Chromatic visual-regression workflow to enforce story approvals before merging by setting exitZeroOnChanges: false, adds a ref to the checkout step for more explicit branch targeting, and supplies Chromatic-specific environment variables (CHROMATIC_BRANCH, CHROMATIC_SHA, CHROMATIC_SLUG) to improve build association.

• Visual enforcement – exitZeroOnChanges: false will cause the CI job to fail whenever unapproved visual changes are detected, requiring Chromatic sign-off before merge.
• Wrong fallback for CHROMATIC_SHA – On push events (e.g. direct commits to main or release-** branches), github.event.pull_request.head.sha is empty and the expression falls back to github.ref (a symbolic ref like refs/heads/main) rather than github.sha (the actual commit SHA). This will cause Chromatic to misidentify the commit for those runs and can break baseline tracking.
• Implicit empty ref on push events – github.event.pull_request.head.ref is empty on push events, leaving ref: as an empty string; while actions/checkout likely falls back to GITHUB_SHA silently, making the intent explicit with a || github.sha fallback would be cleaner.

Confidence Score: 3/5

The P1 CHROMATIC_SHA bug will cause Chromatic to receive a branch ref string instead of a commit SHA on push-to-main runs, breaking baseline association; fix the fallback before merging.

The core feature (enforcing approvals on PRs via exitZeroOnChanges: false) is sound, but the CHROMATIC_SHA fallback to github.ref instead of github.sha is a concrete logic error that will silently break Chromatic build tracking on every push to main and release branches.

.github/workflows/chromatic.yml — specifically the CHROMATIC_SHA environment variable fallback on line 75.

Important Files Changed

Filename	Overview
.github/workflows/chromatic.yml	Adds exitZeroOnChanges: false to enforce Chromatic approvals, adds checkout ref, and sets Chromatic env vars — but CHROMATIC_SHA falls back to github.ref (a branch ref string) instead of github.sha (an actual commit SHA) on push events.

_{Reviews (1): Last reviewed commit: "feat: required approvals on ci merges" | Re-trigger Greptile}

[gilluminate]

nice