chore(ci): route merges through the trunk merge queue - #74065
Merged
Conversation
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gantoine
added
the
skip-agent-review
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gantoine
changed the title
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Contributor
Prompt To Fix All With AI### Issue 1
.agents/skills/merging-prs/SKILL.md:91
**Failed queue check never terminates**
When Trunk fails the queue check while leaving the PR open, this loop records the failure but exits only for `MERGED` or `CLOSED`, causing failure handling to be delayed until the one-hour monitor timeout.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "Merge remote-tracking branch 'origin/mas..." | Re-trigger Greptile |
Piccirello
approved these changes
Jul 28, 2026
A PR that fails the queue check stays OPEN, so the watch loop's MERGED|CLOSED exit never fired and failure handling waited out the one-hour monitor timeout. Exit on a terminal non-success conclusion too, picking the newest queue check so a stale failed run from an earlier enqueue can't trigger a false exit. Also paginate the check-runs calls — a head SHA here carries 200-350 check runs and the unpaginated default returns only the first 30, which would hide the queue check entirely. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![veria-ai[bot]](https://avatars.githubusercontent.com/in/1723776?s=60&v=4){kind=small}
Contributor
PR overviewAll previously flagged issues have been addressed. No open security concerns remain on this pull request. Security reviewNo open security issues remain on this pull request. Fixed/addressed: 1 · PR risk: 0/10 |
Step 4 piped every recent comment body into context unfiltered, at the one point in the skill where the agent is primed to edit, push and re-enqueue. Anyone able to comment on a PR could forge a Trunk failure report and steer those actions. Filter to the trunk-io[bot] identity (GitHub forbids brackets in human usernames, so the login is not registrable by a person), and state that the body is diagnostic data rather than instructions, with the check run and workflow logs as the authority for what failed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The check run is the authoritative source: only an app with checks:write can write one, so it cannot be forged, while a PR comment can be posted by anyone with read access. Read conclusion, details_url and output off the queue check the monitor already polls, and assert the writing app is trunk-io. Note Trunk's MCP investigate-ci-failure as optional enrichment. It is not a dependency — it needs a workflow URL the check run already gives us, returns nothing when a job fails before tests run, and only has data while TRUNK_UPLOAD_ENABLED is on. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gantoine
added a commit
that referenced
this pull request
Jul 30, 2026
Master landed the merge-queue rollout (#74065, #74367) and the impacted-targets upload (#74266) in the meantime, so: - trunk-impacted-targets.yml now takes master's version wholesale; it supersedes this branch's standalone draft with a compute/upload split and real lane computation. - Kept master's removal of the labeled/unlabeled triggers on top of this branch's removal of ready_for_review. - Kept master's hogli-lint not-a-required-gate markers and the non-pytest-Python wording in ci-mcp.
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
We're turning on Trunk's merge queue. Two gaps to close before that's usable.
First,
gh pr mergeand the GitHub merge button become dead ends. Agents don't know that. Left alone they'll try to merge directly, hit the branch ruleset, and either give up or start improvising. And "merge it" is really two jobs: enqueue, then babysit the PR until Trunk lands it or kicks it out.Second, Trunk can't place a PR into a queue lane without an impacted-targets upload for its head SHA. Without one, PRs never enter the queue at all. This bit posthog/code, where fork PRs silently sat outside the queue and had to be merged by hand.
Changes
Impacted-targets upload.
.github/workflows/trunk-impacted-targets.ymlPOSTs to Trunk'ssetImpactedTargetson every PR event. It's a port of the workflow already running in posthog/code, including the fork-auth handling: forkpull_requestruns get no repo secrets, so they authenticate withx-forked-workflow-run-idand Trunk verifies the run id against the head SHA. Internal PRs usex-api-token.It reports
impactedTargets: "ALL"rather than a computed list. That's always correct - it can never under-report and let the queue merge conflicting PRs in parallel. It buys no parallelism, it just gets every PR into the queue. Narrowing it to real target names later is a follow-up, andci-paths-filter.ymlalready computes something close to what that would need.Two deviations from the posthog/code version, both because this repo's conventions differ:
workflow_callreusable workflow folded intopr-housekeeping.yml, not its own dispatch. That parent exists precisely to keep small always-fire PR workflows from each burning a run against the 500-runs/10s dispatch cap. The parent's concurrency group is already keyed on PR number, which also happens to be what the posthog/code version worked around by hand (fork PRs frequently share ahead_ref, so keying on branch name lets one PR cancel another's upload).TRUNK_API_TOKENis absent on an internal PR, so this can land before the secret does.The
merging-prsskill covers the whole merge loop: preflight the PR, enqueue with a/trunk mergecomment, confirm Trunk picked it up, watch until it lands, handle the kick-out case by reading the Trunk bot's comment. A failed impacted-targets upload is the first thing it checks when a PR doesn't appear in the queue.AGENTS.md gets the rule itself, since not every agent will load the skill, plus a line in the stacked-PRs section - restacking force-pushes, and that silently drops a queued branch.
Warning
Also worth confirming: the AGENTS.md line names the check run
Trunk Merge Queue (master)exactly. The skill matches on aTrunk Merge Queueprefix so it tolerates any suffix, but the AGENTS.md line is the thing to re-check against the real queue config.How did you test this code?
bin/hogli lint:workflowsandactionlint(1.7.12, the pinned CI version, withSHELLCHECK_OPTS=--severity=error) both pass on the two changed workflows.hogli ci:preflight --strictpassed on push.I did not exercise the upload or the merge flow end to end - the queue isn't wired up on this repo yet, and I'm not going to POST to Trunk's API from a local shell to find out. The payload shape and auth headers are copied from the workflow currently running in posthog/code, not written from the docs.
No tests added. There's nothing here a test would catch that the two linters don't.
Automatic notifications
Docs update
Not applicable - this is agent-facing repo documentation and CI wiring, not user docs.
🤖 Agent context
Autonomy: Human-driven (agent-assisted)
I (actually Claude, via Claude Code) started from a draft skill written against a
main-default repo, then ported the impacted-targets workflow off posthog/code once it came up that the queue needs it.Skills invoked:
/writing-skillsbefore writing the skill,/authoring-ci-workflowsbefore the workflow. The latter is why this is a reusable workflow underpr-housekeeping.ymlrather than a standalone dispatch, and why the fork handling is shaped the way it is.Decisions worth flagging for review:
/gating-production-deploysgates deploys onCD_DEPLOY_ENABLED. Rejected it: that skill notes gatingpull_requestbuilds on a variable breaks contributor CI, which suggests variables don't reach fork PR runs. Since forks are the case this workflow most needs to serve, a vars gate would defeat the point. Hence the token-presence check instead, which only covers internal PRs, and the merge-ordering warning above for the fork half.allowed-toolslist scoped to a handful ofghinvocations. I dropped it - it would have blocked the skill's own "fix the failure, push, re-enqueue" path, and most skills in.agents/skillsdon't restrict tools. Thegh pr mergeprohibition stays as a hard rule in the prose, and the ruleset backs it up regardless.sleep 60. Claude Code blocks foreground sleep, so it would have stalled. Rewrote it as a state-transition script for theMonitortool or background Bash, printing only on change and exiting on MERGED or CLOSED./writing-skillsturned out to be aimed at product skills underproducts/*/skills/, which get published to PostHog/skills for customer-facing agents. That's a different thing from the repo-engineering skills in.agents/skillsthis PR adds. Naming and description conventions still applied, but the tooling it describes (hogli lint:skills,hogli build:skills) doesn't cover.agents/skills. Might be worth splitting that guidance.