feat: patch Linear issues and projects - #475
Conversation
ianw-oai
changed the title
mldangelo-oai
left a comment
mldangelo-oai
left a comment
There was a problem hiding this comment.
Non-blocking QA notes on 4d3aeb5c. The adapter is already a good size. Pagination, credential precedence, error handling, and removing Linear credentials before starting the patch subprocess passed with the real Linear SDK against a synthetic service. The full local suite passed: 1,292 tests, 11 skipped. The current GitHub checks are green.
I'd keep the adapter small and retain the issue ID and URL when connecting it to the common patch result. This covers intake and patch handoff, not a live Linear-to-PR run.
| return issues.map( | ||
| ({ identifier, title, url, description }) => | ||
| `Linear issue: ${identifier}\nTitle: ${title}\nURL: ${url}\n\n${description ?? ""}`, | ||
| ); |
There was a problem hiding this comment.
Non-blocking: when this feeds the common patch result, could we retain the issue ID and URL alongside the text? A small { source, id, url, text } value, formatted at the prompt boundary, would save later stages from parsing this string. I'd keep the SDK adapter and pagination as they are.
zcrab-oai
left a comment
zcrab-oai
left a comment
There was a problem hiding this comment.
Found two input-handling issues affecting imported issue content and explicitly selected Linear workspaces.
| exitCode = await runSkill( | ||
| "fix-finding", | ||
| positionals, | ||
| [...positionals, ...imports], |
There was a problem hiding this comment.
[P1] Keep imported Linear issue content literal
Could imported Linear issues take a literal-only path into runSkill instead of sharing positional file-or-text resolution? User-selected local files and remotely supplied issue descriptions have different trust boundaries, and imported descriptions must never trigger local file lookup. Please add Unix and Windows regressions that ensure imported ticket content is always preserved literally.
| } | ||
| } else { | ||
| for (const input of options.issues) { | ||
| const id = linearIssueIdentifier(input); |
There was a problem hiding this comment.
[P2] Preserve the workspace selected by an issue URL
Could we retain the workspace from a supplied Linear issue URL and verify it against the fetched issue's canonical URL? Looking up only the team-and-number identifier can silently return a different workspace's issue when the configured credential belongs elsewhere, causing the patch to target something other than the issue the user selected.
| options: z.object({ | ||
| effort: effortOption(), | ||
| linear: z | ||
| .array(optionValue("--linear")) |
There was a problem hiding this comment.
noop comment, calling out so we are aware
earlier we did --to linear to make it more generic for publishing. but then I let codex add --linear-... to the prefix of things bc they were very linear specific. IMO we should either go full generic with --to and stuff like --ticket-api-key or more specific with --linear-... prefixed flags.
TL;DR I don't like how I did a mix of the 2.
There was a problem hiding this comment.
I think this is similar to the linear client I added for the publish workflow. We might want to put those together.
4 participants
Summary
Import Linear issues and patch them with the existing CLI workflow.
Changes
Testing
Risk and rollout
Linear access is read-only. Existing patch behavior is unchanged, and Linear credentials are not passed to Codex.
Public disclosure review