chore: add --changedSince base SHA to Jest in CI

[JoshuaKGoldberg]

"Why run many unit test when few do trick?" – Kevin Malone, Senior Frontend Developer

Changes the Frontend > Jest jobs to use Jest's --changedSince option when possible. That has them only run test suites that are impacted by the changes in a PR based on the module dependency graph. Jest requires the commit history since the base commit, so this adds a second "run only necessary Jest tests" flow in frontend-optional.yml. Specifically, that:

1. Increases the frontend-optional fetch-depth in PRs to 100, which should get most PRs' commits pretty quickly
2. Tries to compute a MERGE_BASE using git merge-base
   • Note that this also clears MERGE_BASE if the PR touches any non-static/ files.
3. If MERGE_BASE could be computed, passes it as a process env var to test scripts for use as Jest's changedSince
   • If MERGE_BASE couldn't be computed, the new "run only necessary Jest tests" flow is skipped

My plan (thanks to reviewer feedback) is to keep this running as a secondary, optional test flow on master for a couple weeks. If all seems well, we can remove the original "run all Jest tests" logic and only run the "run only necessary Jest tests" logic.

The following PRs exercise different scales of changes:

PR	Source Files	Test Files	Interconnectivity	Ran Suites	/ 1,881 suites
#110624	0	1	⬜️ None	1	0.05%
#111073	0	6	⬜️ None	6	0.32%
#111122	0	100	⬜️ None	100	5.3%
#111074	1	0	🟦 Low	5	0.27%
#111075	4	0	🟦 Low	7	0.37%
#111076	3	3	🟦 Low	13	0.69%
#111110	20	20	🟦 Low	74	3.9%
#111111	100	100	🟦 Low	196	10.4%
#111119	1	1	🟨 Medium	30	1.6%
#111628	3	3	🟨 Medium	78	4.1%
#111629	10	10	🟨 Medium	167	8.9%
#111633	25	25	🟨 Medium	227	12.1%
#111652	100	100	🟨 Medium	549	29.2%
#111115	3	3	🟧 High	1,652	87.8%
#111083	20	20	🟧 High	1,660	88.3%
#111086	100	100	🟧 High	1,721	91.5%
#110568	0	0	🟥 Config (Full)	1,881	100%

For low-connectivity changes (isolated components, feature-specific views), --changedSince provides pretty great savings: even 100 low-connectivity files only trigger ~10% of suites. Medium-connectivity files still scale pretty well, with 100 files hitting ~29%. High-connectivity files (widely-imported utils, core components) sadly trigger 85-90% of suites, which is inevitable given Sentry's highly connected module graph.

Fixes ENG-7103

[linear-code]

ENG-7103 Narrow Jest tests in PRs' CI to just those changed in the PR

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Shard balancing uses unfiltered total, breaking distribution

Medium Severity

speculatedSuiteDuration is computed from the full testStats (all ~1,861 suites), but the new filtering at lines 143–146 correctly restricts the tests Map to only the allTests subset from --changedSince. Since targetDuration is massively inflated relative to the actual filtered tests' total duration, the balancing loop stuffs every test into the first shard while shards 1–3 get nothing. This defeats parallelization for any small-to-medium --changedSince result set.

Additional Locations (1)

• jest.config.ts#L139-L146

 

[JoshuaKGoldberg]

Hmm, interesting. I don't think parallelization at those result set scales really matters much, right? Running 10 suites vs 100 is pretty quick.

[scttcper]

on package.json or those kinds of changes would it know to run the entire suite?