chrismdp / issue-to-pull-request

An issue becomes a pull request

Public ·
Version 12 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.4Showing
  13. #11 · chrismdp · · 0.4
  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

workflow.yaml has 1 mistake, drawn in red. See Checks.

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 failedthe branch[opened][straightforward][needs a review]the review requestthe pull request and CI's resultthe merge, setthe mergethe result[passed, set by the app][passed, by the reviewer]outside action "main" is Ask,but part "land" leads to it withno person in betweenTriggerThe build label is added to anissueOnly people with write access and the repository's app 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-buildTriggerA failed try starts the buildagainOnly this workflow starts a retry, and only for an issue a label already startedTriggerThe app pushes the pullrequest's branchUsed 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 tokenUsed by chrismdp/fix-review-findings, chrismdp/land-a-pull-request and chrismdp/rebase-conflicting-pull-requestsConnectionThe repository, through itsown GitHub AppGitHub starts other workflows from the app's pushes, merges and labels, so CI runs on the pull request and a merge starts CI on main and the rebase workflow. The app's key is a secret in each repository it's installed on, and each run's token reaches only its own repositoryCode · 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 requestAllowCode · checkCI runs every check on thebranchDataThe 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 · doSet the pull request to mergeonce CI passes, saying in itsmessage why it wasstraightforwardCode · doAsk the person who added thelabel to review the pull requestEach retry carries the name of the person who added the label. A build whose label the app added, with no such person, asks the repository's ownerOutside actionRequest a reviewAllowPerson · doReview the pull request andmerge itConnectionThe repository, through thereviewer's own accountCode · sortSort by main's rule: has CIpassed on the branch?Main's rule holds every merge, the app's and the maintainer's, until CI passes. Only the maintainer may skip it, to push a release; the app may notCode · doMerge the change the app setto mergeCode · doMerge the reviewer's changeOutside 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 mainOutside actionMerge a change that neededreview into mainAsk