[EPAC-2011]: inherit Linear projectId from originating PR's EPAC issue#586
Merged
riddim-developer-bot[bot] merged 1 commit intoMay 25, 2026
Conversation
When the CI failure handler creates a new Linear issue, it now looks up the originating PR via head_sha, extracts the EPAC-XXXX identifier from the PR title, queries Linear for that issue's projectId, and sets it on the new CI-failure issue. A "Triggered by" footer with PR and issue links is appended to the description when both are available. The lookup is best-effort: GitHub or Linear API failures are logged and the issue is created without project inheritance.
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.
Why
CI-failure issues created by the handler landed unparented in Linear. When a workflow fails after a PR merge, the failure issue should inherit the originating PR's EPAC issue's Linear project so it appears in the same project view as the work that caused it.
What changed
GitHubPRClient: New thin client withfind_pr_for_commit(repo, sha)that callsGET /repos/{owner}/{repo}/commits/{sha}/pulls, preferring the PR whosemerge_commit_shamatches the head SHA and falling back to the first PR.PRInfo/OriginatingContext: Value objects carrying the originating PR metadata and optional Linear project inheritance.extract_linear_id(pr_title): Regex\bEPAC-\d+\bextracts the first EPAC identifier from a PR title. Non-EPAC prefixes are ignored.LinearClient.get_issue_project_id(identifier): GraphQL query returning the originating issue'sprojectId(orNoneif unparented/missing).resolve_originating_context: Orchestrates the lookup chain (GitHub PR → regex → Linear project). Best-effort: any failure is logged and falls through to unparented creation.report_ci_workflow_outcome: Accepts optionalgithub_client; on the create path, resolves originating context, setsprojectIdon the new issue, and appends a "Triggered by" footer linking back to the PR and originating EPAC issue.LinearIssueRequest.project_id: New optional field;create_issueincludesprojectIdin the mutation payload when set.pull-requests: readpermission andGITHUB_TOKENenv var.Trade-offs not taken
scripts/ci/github_pr_client.pymodule: kept inline with the existing single-file pattern since the client is thin (one method) and the script has no other modules.workflow_runevent is a single invocation.AUTO-XXX): out of scope per the issue.Test plan
Unit tests cover all 6 AC scenarios plus
extract_linear_idedge cases (22 tests, all passing):Verification evidence
Resolves EPAC-2011
Reviewer-Boundary: review-only