chore(chromatic): do not run on changesets branch

[louis-bompart]

Changesets triggers rebuild sometimes, and overall we don't need chromatic here really.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 2af280e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[svcsnykcoveo]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[Copilot]

Pull request overview

This PR aims to prevent Chromatic visual tests from running on Changesets release PR branches, since they can trigger unnecessary rebuilds.

Changes:

• Added a branch check to skip the Chromatic run step when the PR head branch is changeset-release/main.

[Copilot]

This new condition only skips the chromatic-run step, but the fallback turbo chromatic -- --skip step will still run when chromatic-run is skipped (including on changeset-release/main). Since the chromatic turbo task depends on build:storybook (see packages/atomic/turbo.json), changeset-release PRs will still trigger the Storybook rebuild you’re trying to avoid. Consider also excluding the changeset-release branch from the --skip step (and/or gating the expensive setup/build steps), and using a broader match like startsWith(..., 'changeset-release/') instead of an exact branch name if you want to cover all changeset-release branches.

Suggested change

	if: contains(needs.affected.outputs.projects, '@coveo/atomic') && github.event_name == 'pull_request' && !contains(github.event.pull_request.labels.*.name, 'chromatic') && github.head_ref != 'changeset-release/main'
	- run: pnpm exec turbo chromatic --filter=@coveo/atomic -- --skip
	working-directory: packages/atomic
	if: steps.chromatic-run.outcome == 'skipped'
	if: contains(needs.affected.outputs.projects, '@coveo/atomic') && github.event_name == 'pull_request' && !contains(github.event.pull_request.labels.*.name, 'chromatic') && !startsWith(github.head_ref, 'changeset-release/')
	- run: pnpm exec turbo chromatic --filter=@coveo/atomic -- --skip
	working-directory: packages/atomic
	if: steps.chromatic-run.outcome == 'skipped' && (github.event_name != 'pull_request' || !startsWith(github.head_ref, 'changeset-release/'))

[pkg-pr-new]

Open in StackBlitz

@coveo/atomic

npm i https://pkg.pr.new/@coveo/atomic@7432

@coveo/atomic-hosted-page

npm i https://pkg.pr.new/@coveo/atomic-hosted-page@7432

@coveo/atomic-legacy

npm i https://pkg.pr.new/@coveo/atomic-legacy@7432

@coveo/atomic-react

npm i https://pkg.pr.new/@coveo/atomic-react@7432

@coveo/auth

npm i https://pkg.pr.new/@coveo/auth@7432

@coveo/bueno

npm i https://pkg.pr.new/@coveo/bueno@7432

@coveo/create-atomic

npm i https://pkg.pr.new/@coveo/create-atomic@7432

@coveo/create-atomic-component

npm i https://pkg.pr.new/@coveo/create-atomic-component@7432

@coveo/create-atomic-component-project

npm i https://pkg.pr.new/@coveo/create-atomic-component-project@7432

@coveo/create-atomic-result-component

npm i https://pkg.pr.new/@coveo/create-atomic-result-component@7432

@coveo/create-atomic-rollup-plugin

npm i https://pkg.pr.new/@coveo/create-atomic-rollup-plugin@7432

@coveo/headless

npm i https://pkg.pr.new/@coveo/headless@7432

@coveo/headless-react

npm i https://pkg.pr.new/@coveo/headless-react@7432

@coveo/shopify

npm i https://pkg.pr.new/@coveo/shopify@7432

commit: 2af280e

[alexprudhomme]

If we don't need chromatic, what do we really need ? We either run nothing or everything in this case imo. Just excluding chromatic isn't a good long term solution.

[louis-bompart]

If we don't need chromatic, what do we really need ? We either run nothing or everything in this case imo. Just excluding chromatic isn't a good long term solution.

@copilot, @alexprudhomme brought a very good point here. We probably can run nothing or close to nothing for changesets branch.

[Copilot]

If we don't need chromatic, what do we really need ? We either run nothing or everything in this case imo. Just excluding chromatic isn't a good long term solution.

@copilot, @alexprudhomme broug...

Implemented in 02004bb: the chromatic job is now fully skipped for PRs whose head branch starts with changeset-release/, so we run nothing for Chromatic on changeset branches (including setup and fallback steps).

If we don't need chromatic, what do we really need ? We either run nothing or everything in this case imo. Just excluding chromatic isn't a good long term solution.

Addressed in 02004bb: instead of only excluding one Chromatic step, the entire chromatic job is now skipped on changeset-release/* PR branches so we run nothing for Chromatic in that case.

[louis-bompart]

@copilot change the scope of the PR: instead of just skipping Chromatic, make it so all if not tests and so on are skipped so that we can expedite the merge of those PR.

[Copilot]

@copilot change the scope of the PR: instead of just skipping Chromatic, make it so all if not tests and so on are skipped so that we can expedite the merge of those PR.

Done in 2af280e (main change introduced in 5cd60ed): for changeset-release/* PRs we now skip the main CI entry jobs (pr-report, build-windows, build-missing, build, build-cdn), which in turn skips downstream tests/checks and speeds up merge. No UI changes in this PR.

[github-actions]

⚠️ Secrets Reference Detected in Workflow Changes

This pull request modifies GitHub Actions workflow files and includes references to secrets.

Please ensure:

• The secret is properly configured in the repository/organization settings
• The secret name follows naming conventions
• The secret is not being exposed in logs or outputs
• Access to the secret is appropriately scoped

Why am I seeing this?

This comment is automatically added when workflow changes include the word secrets to remind reviewers to verify proper secret handling.