awml
Sign in

chrismdp / issue-to-pull-request

An issue becomes a pull request

Public ·
Version 14 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.4Showing
  11. #13 · chrismdp · · 0.4
  12. #12 · chrismdp · · 0.4
  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
Who may see each partWhere each part runsYAMLChecks1mistake

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]the redrawn examplesthe pictures' links[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 and itsdescription for the pull requestCode · 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)Code · doRedraw the examples thechange alters, and picturewhat changed, before andafterOnly a change to what a drawing or a page shows is pictured. GitHub plays only video uploaded through its web page, so a moving change is pictured as an animated image, which it shows inlineDataThe before and after picturesCode · doPush the pictures to thebranch kept for themOutside actionPush to the pictures branchAllowDataThe 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 issueThe description opens with why the change needs review, as bullets, then Claude's note as written, then what changed, the decisions the issue didn't settle, the pictures, and the issue it closesOutside actionOpen the pull requestAllowCode · checkCI runs every check on thebranchDataThe build rules: what needs areviewCode · sortSort by rule: does the changetouch a path that needsreview, delete a test, changeover 400 lines, or carryClaude's request for review?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