ci(playwright): tighten fixture-cache fingerprint to seed-affecting paths

[chirag-madlani]

Summary

Tightens the fixture-cache fingerprint (.github/scripts/playwright_cache_fingerprint.py) so runtime-only code changes stop invalidating a cache whose content they can't affect.

Measured on the last 100 merges to main:

Prefixes	Invalidations	Rate
Old	18 / 100	18.0%
New	14 / 100	14.0%
Diff	-4	-22%
New-only regressions	0	strictly a subset

Motivation

Investigation into why merge_group runs never hit the fixture cache found two independent problems:

1. Nothing populates main's cache scope — merge_group events are deliberately blocked from saving (ephemeral-ref cache-poisoning risk), no push trigger exists, and the "nightly" workflows only have workflow_dispatch. So merge_group runs always start cold. Fixed by a follow-up warmer PR.
2. The fingerprint invalidates on runtime-only changes — a search-query aggregator, a REST resource, or a Java util in openmetadata-spec/ all rolled the fixture key, forcing a rebuild for changes that couldn't affect what got seeded. This PR.

The two fixes compose: with a warmer + this tightened fingerprint, effective merge_group cache hit rate goes from 0% (today) to ~86% (100% − 14%). Estimated saving: ~15 min per merge × ~40 merges/day × 86% ≈ ~8-9 hours of merge-queue wall time per day.

What changed

Three overly-broad prefixes narrowed:

Old (broad)	New (narrow)	Why the old was wrong
openmetadata-spec/	openmetadata-spec/src/main/resources/json/schema/	The Java utils and generated code under this module are SDK inputs the tests use at runtime — not what shapes the seeded Postgres/OpenSearch rows.
openmetadata-service/src/main/resources/	.../resources/json/data/ + .../resources/applications/	The broad prefix hashed logback.xml, openapi.yml, monitoring/, META-INF/, dataInsights/, rdf/ — all runtime-only. Only json/data/ (test connections, bots, marketplace defs) and applications/ describe seeded content.
.../service/search/	.../service/search/indexes/ + .../service/search/models/	Query-time code (AggregationManagementClient, HighlightFieldClassifier, ColumnFilterMatcher, ...) doesn't decide what's seeded into the index. The mapping classes that shape indexed documents are all under indexes/ and models/.

Two whole subtrees dropped entirely as runtime-only:

• .../apps/bundles/searchIndex/ — the bulk reindexer, runs only on user-triggered reindex jobs; the fixture's initial seed doesn't invoke it.
• .../resources/search/ and .../resources/searchindex/ — REST endpoints (SearchResource, SearchReindexResource, VectorSearchResource). Servable behaviour, not seeded state.

Everything else in the fingerprint stays as-is (migrations, initialization, security/JWT/auth, seed-data prefixes, Docker, conf/openmetadata.yaml, UI auth utils, fixture scripts).

The 14 remaining invalidations

Sampled and categorized:

• Legitimately fixture-affecting — 5:
  • New connector schemas + seeded test-connection JSON (Salesforce Data360)
  • Real migration Java code (v159 backfill, v210 pipeline sourceConfig)
• Schema additions for new features — 4:
  • New entity types (aiContext, personaContext, mcpConnection, etc.)
  • Conservative-keep — a schema change may affect an existing seeded entity type
• pom.xml / package.json / yarn.lock bumps — 5:
  • Jetty, Jackson, js-yaml, babel, fast-uri
  • Conservative-keep — the ingestion Docker image is bundled into the fixture, so Java dep bumps could change its behaviour

All defensible. Tightening further would trade correctness for hit rate, which is the wrong direction — a stale fixture masks migration bugs.

Side effect

The fixture cache key changes on this PR (from ae713dbc… to 325a148e…) because playwright_cache_fingerprint.py is itself in FIXTURE_PREFIXES (intended safeguard against skew). Every merge_group run after this lands will miss the cache until the follow-up warmer PR re-populates main's scope with the new key. First few merge_group runs post-merge will be no worse than today; then everything gets much faster once the warmer lands and runs.

Test plan

• All 5 fingerprint kinds still compute (fixture, schema, seed, ingestion, distribution)
• 100-commit replay: 4 fewer invalidations, 0 new-only invalidations (strictly a subset)
• Merge to observe: after landing, verify the warmer PR (follow-up) restores hit rate under the new key

Non-goals

• Doesn't add the warmer — that's the follow-up PR that actually makes cache saving happen. Ship this first so the warmer builds against the tightened fingerprint from day one.
• Doesn't change the schema/distribution/ingestion fingerprints (kept intact for their own cache scopes).

🤖 Generated with Claude Code

[github-actions]

❌ PR checklist incomplete

This PR cannot be merged until the following are addressed on its linked issue:

• No GitHub issue is linked. Link an issue in the Development section of the PR (or add Fixes #12345 to the description). For a same-org cross-repo issue, add Fixes open-metadata/<repo>#123 to the description.

The fields live on the linked issue in the Shipping project (open the issue → right sidebar → Projects). After you set them, re-run this check (or push a commit) — issue/project changes do not re-trigger it automatically.

Maintainers can bypass this check by adding the skip-pr-checks label.

[gitar-bot]

Code Review ✅ Approved

Tightens the fixture-cache fingerprint by narrowing three overly-broad path prefixes (openmetadata-spec/, openmetadata-service/src/main/resources/, .../service/search/) and removing two runtime-only subtrees, reducing cache invalidations by 22% (4 fewer per 100 merges) without introducing new regressions. No issues found.

Options

Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source}

[github-actions]

✅ Playwright Results — workflow succeeded

Validated commit 8826c12b24cedac05db0ae56ae18a5be40bd79ac in Playwright run 34364047928, attempt 1.

✅ 557 passed · ❌ 0 failed · 🟡 0 flaky · ⏭️ 0 skipped · 🧰 0 lifecycle flaky

Performance

Blocking targets: ✅ met · Optimization targets: 🟡 in progress

Shard-job maxima below are not the full workflow wall time; the linked run includes build, fixture, planning, and reporting.

🕒 Full workflow signal wall (to summary) 49m 35s

⏱️ Max setup 4m 20s · max shard execution 17m 51s · max shard-job elapsed before upload 21m 38s · reporting 4s

🌐 236.16 requests/attempt · 2.82 app boots/UI scenario · 16.62% common-shard skew

Optimization targets still in progress:

• Common shard skew was 16.62% (convergence target: at most 15%).
• Browser traffic was 236.16 requests per attempt (convergence target: fewer than 200).
• Application boot ratio was 2.82 per UI scenario (1629 boots / 578 scenarios; convergence target: at most 1).

Shard	Passed	Failed	Flaky	Skipped	Lifecycle failed	Lifecycle flaky
✅ Shard chromium-01	133	0	0	0	0	0
✅ Shard chromium-02	140	0	0	0	0	0
✅ Shard chromium-03	126	0	0	0	0	0
✅ Shard data-asset-rules-01	65	0	0	0	0	0
✅ Shard domain-isolation-01	16	0	0	0	0	0
✅ Shard global-state-01	34	0	0	0	0	0
✅ Shard ingestion-01	1	0	0	0	0	0
✅ Shard reindex-01	2	0	0	0	0	0
✅ Shard search-01	11	0	0	0	0	0
✅ Shard search-rbac-01	29	0	0	0	0	0

📦 Download artifacts

How to debug locally

# Download playwright-test-results-<shard> artifact and unzip
npx playwright show-trace path/to/trace.zip    # view trace