awml
Sign in

chrismdp / issue-to-pull-request

An issue becomes a pull request

Public ·
Version 11 of 23
  1. #23 · chrismdp · · 0.8Latest
  2. #22 · chrismdp · · 0.6
  3. #21 · chrismdp · · 0.6
  4. #20 · chrismdp · · 0.6
  5. #19 · chrismdp · · 0.6
  6. #18 · chrismdp · · 0.6
  7. #17 · chrismdp · · 0.6
  8. #16 · chrismdp · · 0.4
  9. #15 · chrismdp · · 0.4
  10. #14 · chrismdp · · 0.4
  11. #13 · chrismdp · · 0.4
  12. #12 · chrismdp · · 0.4
  13. #11 · chrismdp · · 0.4Showing
  14. #10 · chrismdp · · 0.4
  15. #9 · chrismdp · · 0.4
  16. #8 · chrismdp · · 0.3
  17. #7 · chrismdp · · 0.3
  18. #6 · chrismdp · · 0.3
  19. #5 · chrismdp · · 0.3
  20. #4 · chrismdp · · 0.3
  21. #3 · chrismdp · · 0.3
  22. #2 · chrismdp · · 0.3
  23. #1 · chrismdp · · 0.3
Fork
Who may see each partWhere each part runsYAMLChecksNo mistakes
publicanyone who reads the repositorythe label[build]the issue's threadthe issue and its people'scommentsthe issue[all pass][a check fails][fewer than three][three]the issue and why it failedwhy the last try failed[opened][straightforward][needs a review]the review requestthe pull requestTriggerThe build label is added to anissueOnly people with write access can add a label, and GitHub holds that, not a prompt, so a stranger's comment starts nothing. The draft step's token can only read, so it can't push (awml #26)Started by chrismdp/retry-a-buildTriggerAnother workflow starts abuild for an issueOnly someone with write access, or one of the repository's own workflows, can start a build, so the dispatch is as much a decision as the labelUsed by chrismdp/ci-a-commit, chrismdp/fix-review-findings, chrismdp/land-a-pull-request, chrismdp/rebase-conflicting-pull-requests, chrismdp/retry-a-build and chrismdp/review-a-pull-requestConnectionThe repository, through itsown Actions tokenCode · sortSort by rule: is the label build?Code · bring-inBring in the issue and thecomments of the repository'sown peopleAnyone can comment, but the bring-in step passes on only the comments of the owner, members and collaborators, so strangers' text never reaches the draft step. AWML can't mark this yet (awml #5)DataThe spec, guide, code andAGENTS.mdAI · draftWrite the change test firstDataThe change, as a patch, withClaude's note on itCode · checkRun the tests, vet, theexamples and wasm parityThe check runs where the draft step can't reach, and its verdict is in its own record (awml #13, #20)DataThe check's record of why itfailedCode · sortSort by rule: has it tried threetimes?Code · doStart the build again, with whythis try failedCode · doComment on the issue withwhy the build failedOutside actionComment on the issueAllowCode · doPush a branch and open a pullrequest that closes the issueOutside actionOpen the pull requestAllowDataThe build rules: what needs areviewCode · sortSort by rule: is the changestraightforward?Claude's note can send a change to review but can't skip one. The rule reads the patch itself: what it touches, its size and whether it deletes a test (awml #20, #26)Code · doMerge the pull request, sayingin its message why it wasstraightforwardA merge by the Actions token doesn't start CI or the rebase workflow, so the merge step starts both itselfOutside actionMerge a straightforwardchange into mainAllowAllow, because a merge is undone with git revert, everything in it is already public on its branch, and the maintainer would not be surprised by a change the rule finds straightforward. One the rule sends to review is where they would be, so that merge is Ask. Installs of the plugin pick up either only at a release, which stays the maintainer's yes, though a new install takes mainCode · doAsk the person who added thelabel to review the pull requestEach retry carries the name of the person who added the label. A build started by CI, with no such person, asks the repository's ownerOutside actionRequest a reviewAllowConnectionThe repository, through thereviewer's own accountPerson · doReview the pull request andmerge itOutside actionMerge a change that neededreview into mainAsk