awml
Sign in

chrismdp / issue-to-pull-request

An issue becomes a pull request

Public ·
Version 17 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.6Showing
  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.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 runsYAMLChecksNo mistakes
publicanyone who reads the repositorythe label[build]merges by itselfwaits for reviewfailedthe issue's threadthe issue and its people'scommentsthe issue[all pass][no Important finding in eitherreview][an Important finding]what the reviews foundthe redrawn examplesthe pictures' links[a check fails][a check fails, on the app's pullrequest][fewer than three][three, a check fails][three, findings open]the issue and why it failedwhy the last try failedthe branch[all pass, on the app's pullrequest][straightforward][needs a review]the review requestthe pull request and CI's resultthe merge, setthe result[passed]TriggerThe 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 · doPost the build's statuscomment on the issue, or on aretry edit it with the try andwhy the last one failedOne status comment per build. It carries a hidden marker, so a retry finds it again without passing anything between runs, and a new build label starts a new oneCode · doEdit the status comment: thepull request it opened andwhether it merges by itself orwaits for review, or why thebuild failedOutside actionPost or edit the build's statuscommentAllowCode · 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,AGENTS.md and REVIEW.md,which says what failure lookslike hereAI · 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 pictureonly those whose picturelooks different, before andafterOnly a change to what a drawing or a page shows is pictured, and a picture that looks the same before and after is left out, even when the renderer changed. A moving image only for something that moves. GitHub plays only video uploaded through its web page, so a moving change is pictured as an animated image, which it shows inlineAI · checkReview the patch for bugs,with fresh context, keepingonly the findings that survive asecond lookThe reviewers and the classifier never see the drafting session, and read the patch, not the issue's thread. Their read-only token can't push, comment or merge, and a finding is answered by a fix or by the maintainerAI · checkReview the patch for security,in a separate sessionDataThe reviews' record of theirfindings, each Important, Nitor Pre-existingAI · sortSort by risk: does a personneed to look at this change?DataThe classifier's verdict and itsreasonsDataThe 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, and what is still wrong?Code · doStart the build again, with whythis try failed or what thereviews foundCode · 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, with the classifier's reasons and any open findings, 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, leave a findingopen, or did the classifier askfor review?The classifier can send a change to review but can't skip one, and the agent that wrote the change has no say. The rule reads the patch itself: what it touches, its size and whether it deletes a test (awml #20, #26) CI finishing on a pull request the app opened starts this workflow again, so no review is asked for and nothing merges until CI has a result. CI's failure counts as a failed check, so it goes round again, up to three tries in all2Code · doSet the pull request to merge,saying in its message why itwas straightforwardCode · 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,whose CI has passed, andmerge itConnectionThe repository, through thereviewer's own accountCode · sortSort by main's rule: has CIpassed on the branch the appset to merge?Main's rule holds every merge, the app's and the maintainer's, until CI passes. The reviewer's merge button stays shut until it has. Only the maintainer may skip it, to push a release; the app may notCode · doMerge the change the app setto mergeOutside 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