chore(ci): reduce Percy visual-snapshot usage

[claude]

Requested by Ganesh RK, Jennifer Shehane · Slack thread

• Closes [na] — CI cost work from the Percy-usage investigation (driven by Jennifer Shehane), greenlit by Ganesh RK in the R&D leadership thread linked above.

Additional details

This PR reduces how often we upload Percy visual snapshots in CI. It is config-only — no product, library, or test code changes, and every functional Cypress run keeps running exactly as before. Only the Percy snapshot layer is affected.

Before → After, in plain terms

1. Dev-server integration jobs no longer spin up Percy for nothing.

   • Before: run-webpack-dev-server-integration-tests and run-vite-dev-server-integration-tests wrapped their Cypress run in yarn percy exec and carried the test-runner:percy context — but their specs (and the projects they scaffold) never call cy.percySnapshot(), so they captured zero snapshots while still starting a Percy agent and joining the parallel build as empty shards.
   • After: the Percy wrapper/context is removed from both jobs. They run the same yarn cypress:run as before.

2. Percy snapshots are gated to UI-relevant changes on PRs.

   • Before: Percy snapshotting was tied to the same pipeline parameters that gate the functional UI test jobs. So a PR that only touched a non-UI package which happens to pull in a UI job (e.g. packages/data-context, packages/telemetry) still re-uploaded the full snapshot set.
   • After: a dedicated run-percy pipeline parameter (set by generate-pipeline-parameters.sh) turns Percy on only when a change touches front-end/UI code. On such PRs the UI jobs still run their Cypress tests — they just skip the percy exec layer and upload nothing.

How

• /.circleci/src/pipeline/@pipeline.yml
  • Removed the percy exec wrapper + PERCY_* env from run-webpack-dev-server-integration-tests and run-vite-dev-server-integration-tests.
  • Added a run-percy boolean pipeline parameter (default true).
  • Simplified percy-finalize to a single halt-if-skipped: run-percy guard (a Percy build now exists exactly when run-percy is true), and dropped the stale dev-server params from it.
• /.circleci/src/pipeline/workflows/@main.yml and pull-request.yml
  • The six app/launchpad/frontend-shared/reporter component & integration jobs now take percy: << pipeline.parameters.run-percy >> instead of a hard-coded true.
  • Dropped the two dev-server jobs from percy-finalize's requires/context.
• /.circleci/scripts/generate-pipeline-parameters.sh
  • Computes run-percy = true only for front-end paths: packages/{app,launchpad,reporter,frontend-shared,runner,web-config,icons,resolve-dist} and cli/ (for the static CLI visual snapshots). It stays true for emit_all_true (develop/release, API triggers, run-all-jobs, and global-trigger changes such as deps/config/.circleci).

Expected usage impact

• Removes the two always-empty dev-server Percy shards from every UI build (overhead cleanup; 0 billed snapshots removed — they weren't producing any).
• On PRs, skips the full snapshot upload when the change is not UI-relevant but would previously have triggered Percy (e.g. data-context/telemetry-only PRs). The existing halt-based path filtering already skips Percy for pure backend PRs, so this closes the remaining "non-UI change dragged in a UI job" gap.
• Honest caveat: path filtering only saves when a non-UI change would otherwise have triggered Percy. Front-end PRs, dependency bumps, and config/.circleci changes still snapshot (kept intentionally, so visual coverage is not lost when a change could plausibly affect rendering).
• develop is intentionally left running full Percy. The path-filter script cannot compute a meaningful changed-file set on a develop push (the merge-base with develop is HEAD), which is exactly why develop uses emit_all_true. Gating develop would need a different diff strategy and is out of scope here.

Steps to test

Because the config source lives in .circleci/src/, run yarn pack-ci --validate locally (or let this PR's own CI pack + validate). Then, to confirm the path-filter behavior of generate-pipeline-parameters.sh:

• CIRCLE_BRANCH=develop bash .circleci/scripts/generate-pipeline-parameters.sh → run-percy: true.
• On a PR branch, a change under packages/app (or launchpad/reporter/frontend-shared/runner/web-config/icons/resolve-dist/cli) → run-percy: true.
• On a PR branch, a change under only packages/server / packages/data-context / packages/telemetry → run-percy: false (functional UI jobs may still run, but take no snapshots), and percy-finalize halts.

How has the user experience changed?

No change — this is CI/Percy configuration only. No product or library code is touched.

PR Tasks

• [na] Is there an associated issue with maintainer approval for PR submission?
• [na] Have tests been added/updated?
• [na] Has a PR for user-facing changes been opened in cypress-documentation?
• [na] Have API changes been updated in the type definitions?

---

Generated by Claude Code

[cypress-app-bot]

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.