This is a "map" issue for the PR stack listed below. It should be closed when the final PR in the stack is merged.
This stack adds a repeatable --attach flag to six commands: gh issue comment, gh pr comment, gh issue create, gh pr create, gh issue edit, and gh pr edit.
The flag uploads a local image or video to GitHub and puts the asset into the markdown body. If the body already references the local file path, that reference is changed to point at the uploaded URL. If it does not, the file is appended to the end of the body. Alt text goes after a #.
gh issue comment 12 --attach './login.png#The login error state'
This stack resolves #13256.
The stack 🥞
Twelve pull requests, listed in reading order from the bottom. Each is based on the one below it. The total is about 2,100 lines of production code and 5,950 lines of tests across 44 files, so most of the bulk is tests.
| # |
PR |
What it adds |
| 1 |
#14177 |
Ask what kind of token is active, and select the repository id and viewer permission an upload needs |
| 2 |
#14178 |
What counts as an attachable file: nine extensions, size limits, and the rule that a video takes no alt text |
| 3 |
#14179 |
Find references in markdown and rewrite them to the uploaded URL |
| 4 |
#14180 |
Post the file to GitHub, and refuse early when an upload cannot work |
| 5 |
#14181 |
The flag itself, and the rule for when the rewritten body is safe to write |
| 6 |
#14182 |
Wire the flag into gh pr comment and gh issue comment |
| 7 |
#14183 |
Wire the flag into gh pr create and gh pr edit |
| 8 |
#14184 |
Wire the flag into gh issue create and gh issue edit |
| 9 |
#14200 |
Address review feedback across the first eight PRs, one commit per thread |
| 10 |
#14255 |
Move attachment flag conflict policy into commands |
| 11 |
#14261 |
Document attachment behavior in the installable gh agent skill |
| 12 |
#14262 |
Address the final review feedback on retry timing and path resolution |
How to read it
Start at 1. The first two are small and set up vocabulary used everywhere above them.
Number 3 is the hard one. It is the largest and the densest, 760 lines of production code in one file. Read its second commit first: it is a single markdown document and its expected output, and reading those two side by side is the fastest way to understand the behaviour without reading the scanner.
Numbers 1, 2 and 4 are quick. Each is small and self contained.
Nothing is reachable from a command until number 6. Numbers 1 to 5 add no behaviour a user can see. If you would rather see what the feature does before reading the groundwork, read 6 first and then come back down to 1.
Each diff shows only its own layer, because each pull request is based on the one below it. There is nothing to filter out.
The stack merges bottom to top.
This is a "map" issue for the PR stack listed below. It should be closed when the final PR in the stack is merged.
This stack adds a repeatable
--attachflag to six commands:gh issue comment,gh pr comment,gh issue create,gh pr create,gh issue edit, andgh pr edit.The flag uploads a local image or video to GitHub and puts the asset into the markdown body. If the body already references the local file path, that reference is changed to point at the uploaded URL. If it does not, the file is appended to the end of the body. Alt text goes after a
#.gh issue comment 12 --attach './login.png#The login error state'This stack resolves #13256.
The stack 🥞
Twelve pull requests, listed in reading order from the bottom. Each is based on the one below it. The total is about 2,100 lines of production code and 5,950 lines of tests across 44 files, so most of the bulk is tests.
gh pr commentandgh issue commentgh pr createandgh pr editgh issue createandgh issue editghagent skillHow to read it
Start at 1. The first two are small and set up vocabulary used everywhere above them.
Number 3 is the hard one. It is the largest and the densest, 760 lines of production code in one file. Read its second commit first: it is a single markdown document and its expected output, and reading those two side by side is the fastest way to understand the behaviour without reading the scanner.
Numbers 1, 2 and 4 are quick. Each is small and self contained.
Nothing is reachable from a command until number 6. Numbers 1 to 5 add no behaviour a user can see. If you would rather see what the feature does before reading the groundwork, read 6 first and then come back down to 1.
Each diff shows only its own layer, because each pull request is based on the one below it. There is nothing to filter out.
The stack merges bottom to top.