chore(ci): compute trunk merge-queue lanes from impacted targets

[gantoine]

Note

Stacked on #74065. Review that one first, this PR's base is chore/merging-prs-skill.

Problem

#74065 wires up the impacted-targets upload, but it reports "ALL" for every PR. "ALL" overlaps every other PR's lane, so the parallel merge queue stays effectively serial. That was the right starting point (it can never under-report), but it buys no parallelism.

Trunk assigns two PRs to parallel lanes only when their target sets are disjoint. Lanes aren't configured as a list, they emerge from the target names we upload. So the real task is designing a target vocabulary plus the path to target mapping that produces it.

Changes

.github/scripts/trunk-impacted-targets.js maps a PR's changed files onto lane targets. The workflow now computes the list instead of hardcoding "ALL".

The target vocabulary:

Namespace	Source
py:core, py:product:<name>	tach.toml reverse cascade, isolation via backend:contract-check
fe:core, fe:product:<name>	product frontend trees
rust:crate:<name>	rust Cargo manifests, with dependent cascade
node:ingestion, svc:<name>	nodejs/, services/
docs, agents	markdown, .agents/

Two design points worth review:

Targets come from the dependency graphs we already maintain, not a hand-written path table. A hand-maintained table is a second copy of the graph that drifts silently, and its failure mode is a broken master. So this reuses turbo-discover's tach parser and its backend:contract-check isolation signal.

The ci-*.yml path filters are deliberately not used as the source. They're tuned to over-run tests, where an over-broad match only wastes runner minutes. ci-frontend.yml's frontend filter matches **/*.md and **/*.yaml, so deriving lanes from it would put nearly every PR back in one lane while looking parallel.

Everything is biased toward over-reporting, because reporting extra targets only costs parallelism while reporting too few merges conflicting PRs side by side. Unrecognized paths, unparseable graphs, and a missing merge base all fall back to "ALL".

Measured against the current tree:

Changed path	Targets
products/metrics/backend/api.py	1
products/data_warehouse/frontend/Foo.tsx	1
rust/capture/src/main.rs	2 (pulls in capture-logs)
rust/common/types/src/lib.rs	18 (dependent cascade)
products/data_warehouse/backend/api.py	45 (widely depended on)
products/surveys/backend/api.py	81 (not isolated, widens)
pnpm-lock.yaml	ALL (tripwire)
terraform/main.tf	ALL (unmapped, fails safe)

Sizing note: of the last 400 commits on master, 273 (68%) touch a single coarse domain, so most PRs are single-lane candidates.

Warning

Accepted risk: fe:core and py:core are disjoint, so a frontend PR and a backend PR can merge in parallel. The E2E suite exercises both together and runs on either kind of change, so a combination neither PR's own run covered can still break master. This is inherent to parallel queues rather than specific to these rules. If it shows up in practice, the knob is an e2e target emitted for every change matching ci-e2e-playwright.yml's trigger paths, which puts all such PRs back in one lane. Documented in the script header.

How did you test this code?

Added .github/scripts/trunk-impacted-targets.test.js (18 cases, registered in ci-scripts.yml). Synthetic products, crates, and graphs throughout, so the tests don't break when a product or crate is added.

The regressions each group catches, none of which an existing test covered (this is new code):

• Unmapped path returns ALL. The one failure mode that silently breaks master: an unclaimed path yielding an empty target set reads to Trunk as "overlaps nothing", so the PR merges in parallel with everything.
• Tripwires force ALL, including when mixed with otherwise-narrow files. Drop a tripwire and conflicting lockfile bumps merge in parallel.
• Rust dependent cascade. A shared crate change that didn't pull in its dependents would let a lib change and a consumer change merge in parallel.
• Renamed dependencies. Guards the prost14 = { package = "prost" } shape, see below.
• Graph-unavailable paths widen rather than narrow, for both the tach and rust graphs.
• Core expands to every leaf in its domain, since set intersection is the only way Trunk can express "this can break anything downstream".

Two bugs the smoke run against the real tree caught, both now covered:

• The rust parser threw on any renamed dependency. The repo has legitimate ones (prost14 = { package = "prost" }), which killed the whole graph and collapsed every rust PR to ALL. It now resolves through the rename and only adds an edge when the real crate is in-workspace.
• The tach cascade widened to all 81 backend targets whenever a dependent product lacked a contract check. Only 14 of 86 products have one, so that fired almost every time. Naming the dependent's target is enough for lane purposes; isolation governs whether a product's own change can be tested alone, which is a different question.

Also ran: hogli lint:workflows (6/6 across 106 workflows), hogli ci:preflight --strict (0 failures), and verified the jq payload construction produces valid requests for both the "ALL" and array shapes against the documented API schema.

I could not run actionlint (not on PATH in this environment), and I have not exercised this against a live Trunk queue. The first real signal will be the upload logs on this PR.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Claude Code (Opus 5) wrote this at my direction. I asked it to research how Trunk lanes work and recommend a set for this repo, then to implement the recommendation.

The research phase changed the design. My initial framing was "recommend a collection of lanes", but lanes are emergent from uploaded target names rather than configured, which reframes the whole thing as a safety problem: disjoint targets mean two PRs merge without ever being tested together. The TODO left in #74065 suggested deriving targets from ci-paths-filter.yml; that got rejected once we looked at what those filters actually match. Finding turbo-discover.js and rust/affected-services was the turning point, since the repo already maintains the graphs needed and already fails safe to "test everything".

Rust crate granularity was the main open call. Per-crate lanes need a dependency graph, and the guppy determinator that would give it properly needs a cargo build we don't want in a 5-minute job. Settled on parsing the Cargo manifests statically, degrading to "every rust crate" rather than to ALL when that fails, since the whole rust tree is still soundly disjoint from py and fe.

Skills invoked: /authoring-ci-workflows, /writing-tests, /writing-code-comments.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[greptile-apps]

Prompt To Fix All With AI

### Issue 1
.github/scripts/trunk-impacted-targets.js:225-228
**Multiline dependencies lose graph edges**

When a workspace dependency uses a table such as `[dependencies.personhog-coordination]`, this parser reads the following `path` assignment as the dependency name and omits `personhog-stateright` from the reverse closure. Changes to these dependent crates then receive disjoint targets and can land together without their combined state being tested.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "chore(ci): compute trunk merge-queue lan..." | Re-trigger Greptile}

[veria-ai]

PR overview

All previously flagged issues have been addressed. No open security concerns remain on this pull request.

Security review

No open security issues remain on this pull request.

Fixed/addressed: 2 · PR risk: 0/10

[trunk-io]

😎 Merged successfully - details.

[github-actions]

🤖 CI report

⚠️ Bundle size — 🔺 +13.3 KiB (+0.0%)

Uncompressed size of every built .js bundle, compared against the base branch.

Total: 65.20 MiB · 🔺 +13.3 KiB (+0.0%)

File	Size	Δ vs base
posthog-app/src/scenes/inbox/InboxScene.js	684.7 KiB	🔺 +4.8 KiB (+0.7%)
posthog-app/_parent/products/managed_migrations/frontend/ManagedMigration.js	27.4 KiB	🔺 +3.3 KiB (+13.6%)
posthog-app/src/scenes/onboarding/Onboarding.js	814.4 KiB	🔺 +3.0 KiB (+0.4%)
render-query/src/render-query/render-query.js	21.28 MiB	🔺 +1.8 KiB (+0.0%)

_{Posted automatically by build-bundle-size-report · uncompressed bytes from dist-report}

✅ Eager graph — within budget

How much code each root ships on the eager path — downloaded and parsed before the surface is interactive. Measured from the esbuild output chunks (post-tree-shake, static imports only); lazy import() / React.lazy chunks are not counted.

Root	Eager (shipped)	Δ vs base	Budget
entry (logged-out pages, app bootstrap) src/index.tsx	1.24 MiB · 22 files	🔺 +330 B (+0.0%)	███░░░░░░░ 27.6% of 4.51 MiB
authenticated shell (every logged-in page) src/scenes/AuthenticatedShell.tsx	8.09 MiB · 3,014 files	🔺 +1.8 KiB (+0.0%)	████████░░ 83.3% of 9.71 MiB

🟢 node_modules/monaco-editor/ stays out of src/index.tsx
🟢 src/lib/components/ActivityLog/describers stays out of src/index.tsx
🟢 [object Object] stays out of src/index.tsx
🟢 [object Object] stays out of src/index.tsx
🟢 node_modules/monaco-editor/ stays out of src/scenes/AuthenticatedShell.tsx
🟢 src/lib/components/ActivityLog/describers stays out of src/scenes/AuthenticatedShell.tsx
🟢 [object Object] stays out of src/scenes/AuthenticatedShell.tsx
🟢 [object Object] stays out of src/scenes/AuthenticatedShell.tsx

Largest files eagerly shipped from src/index.tsx

Size	File
126.8 KiB	../node_modules/.pnpm/react-dom@18.3.1_react@18.3.1/node_modules/react-dom/cjs/react-dom.production.min.js
24.6 KiB	../node_modules/.pnpm/buffer@6.0.3/node_modules/buffer/index.js
6.3 KiB	../node_modules/.pnpm/react@18.3.1/node_modules/react/cjs/react.production.min.js
4.5 KiB	../node_modules/.pnpm/@jspm+core@2.1.0/node_modules/@jspm/core/nodelibs/browser/process.js
3.9 KiB	../node_modules/.pnpm/scheduler@0.23.2/node_modules/scheduler/cjs/scheduler.production.min.js
1.4 KiB	../node_modules/.pnpm/base64-js@1.5.1/node_modules/base64-js/index.js
1.3 KiB	src/RootErrorBoundary.tsx
912 B	../node_modules/.pnpm/ieee754@1.2.1/node_modules/ieee754/index.js
789 B	src/scenes/ChunkLoadErrorBoundary.tsx
762 B	src/index.tsx

Largest files eagerly shipped from src/scenes/AuthenticatedShell.tsx

Size	File
281.6 KiB	../node_modules/.pnpm/posthog-js@1.407.5/node_modules/posthog-js/dist/rrweb.js
267.7 KiB	../node_modules/.pnpm/@posthog+icons@0.38.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@posthog/icons/dist/posthog-icons.es.js
235.5 KiB	src/taxonomy/core-filter-definitions-by-group.json
226.5 KiB	../node_modules/.pnpm/posthog-js@1.407.5/node_modules/posthog-js/dist/module.js
154.3 KiB	../node_modules/.pnpm/re2js@0.4.1/node_modules/re2js/build/index.esm.js
126.8 KiB	../node_modules/.pnpm/react-dom@18.3.1_react@18.3.1/node_modules/react-dom/cjs/react-dom.production.min.js
105.2 KiB	src/lib/api.ts
94.0 KiB	../packages/quill/packages/quill/dist/index.js
93.3 KiB	../node_modules/.pnpm/prosemirror-view@1.40.1/node_modules/prosemirror-view/dist/index.js
90.6 KiB	../node_modules/.pnpm/@tiptap+core@3.20.6_@tiptap+pm@3.20.6/node_modules/@tiptap/core/dist/index.js

_{Posted automatically by check-eager-graph · sizes are eager output bytes (shipped, post-tree-shake) from the esbuild metafile · part of #32479}

✅ Toolbar bundle — eager 2.18 MiB within budget

What the toolbar ships to customer pages, measured from the esbuild output (minified, post-tree-shake). The eager set is the entry plus everything statically imported from it — fetched before any feature runs; deferred chunks load lazily. The eager guardrail is 5.72 MiB. Each output file must also stay below 10 MB, where CloudFront stops compressing it. The module boundary is enforced separately by check-toolbar-graph.

Metric	Size	Δ vs base	Budget
Eager (shipped) entry + static imports	2.18 MiB · 17 files	🔺 +330 B (+0.0%)	████░░░░░░ 38.2% of 5.72 MiB
Deferred (lazy)	2.07 MiB · 33 files	no change	n/a — loads on demand
Loader dist/toolbar.js	1.1 KiB	no change	█░░░░░░░░░ 5.8% of 19.5 KiB

Largest eagerly-shipped chunks

Size	File
717.2 KiB	dist/toolbar/toolbar-app-JFACJRNE.css
546.0 KiB	dist/toolbar/chunk-chunk-ZPQNFZXD.js
484.3 KiB	dist/toolbar/chunk-chunk-SMT7UAIH.js
133.6 KiB	dist/toolbar/chunk-chunk-V2BZAD6S.js
131.8 KiB	dist/toolbar/chunk-chunk-T5KY5WYR.js
71.0 KiB	dist/toolbar/toolbar-app-SJJ5SQBP.js
69.0 KiB	dist/toolbar/chunk-chunk-27JL52RE.js
35.6 KiB	dist/toolbar/chunk-chunk-5LXGT3CN.js
20.9 KiB	dist/toolbar/chunk-chunk-EK265TQY.js
12.2 KiB	dist/toolbar/chunk-chunk-PIK3PADE.js

_{Posted automatically by check-toolbar-size · sizes are toolbar output bytes (shipped, post-tree-shake) from the esbuild metafile}

✅ Dist folder size — 🔺 +112.2 KiB (+0.0%)

Total size of the built frontend/dist folder (all assets), compared against the base branch.

Total: 1363.16 MiB · 🔺 +112.2 KiB (+0.0%)

✅ Playwright — all passed

All tests passed.

View test results →

[gantoine]

/trunk merge

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-07-29 19:14 UTC	Run
prod-us	✅ Deployed	2026-07-29 19:34 UTC	Run
prod-eu	✅ Deployed	2026-07-29 19:36 UTC	Run