awml
Sign in

chrismdp / retry-a-build

A failed build tries again

Public ·
Version 3 of 3
  1. #3 · chrismdp · · 0.8ShowingLatest
  2. #2 · chrismdp · · 0.6
  3. #1 · chrismdp · · 0.6
Fork
Who may see each partWhere each part runsYAMLChecksNo mistakes
publicanyone who reads the repositoryCI's run and its branchthe build runs, the label'sevents and the issue's last edit[unedited, fewer than three]the issue's number[three][edited since the label][a commit since main isn't thefactory's]TriggerCI's tests fail on a pull_requestrun from a build/issue-*branch of this repository,whatever else failedDecided in #160's follow-up: only pull_request runs count, which run once per commit, and only from a branch of this repository, since a fork's branch can carry a build's name (#153) Decided in #160's follow-up: the tests own a run where both they and a review failed, so this acts and the fixer doesn't. A fix commit that breaks a test lands here too, redrafts and uses a try; the tries cap stops it2Linked to chrismdp/issue-to-pull-request#tokenConnectionThe repository, through itsown Actions tokenCode · sortSort by GitHub's record,passing on only the issue'snumber and a count: is the runat the branch's head, is theissue's lastEditedAt, fromGraphQL, older than the buildlabel's last labelled event, andhow many build.yml runs forthe issue have started since?Decided in #160's follow-up: a try is a build.yml run for the issue since the label was last added, found by the run's name. The fixer's and the rebase's pushes don't count. Nothing is carried from one run to the next (#160 rule 3)Code · doStart the build again, with onlythe issue's numberIt trusts nothing from inputs, and passes on nothing the build trusts: the build checks the label and the issue's last edit again, and reads CI's failed log itself (#160 rule 2)Starts chrismdp/issue-to-pull-request#dispatchOutside actionStart the build againAllowCode · doSay in a new comment on theissue, from fixed text, that thebuild failed three times andneeds a person, linking CI'srunNew comments, since a person must act. No status comment and no marker for a later run to find (#160 rule 5)Outside actionComment on the issueAllowCode · doSay in a new comment on theissue, from fixed text, that itwas edited since the labelwent on, so a person mustadd the label againDecided in #160's follow-up: a retry drafts from the issue as it reads now, so an issue edited since the label went on stops here until a person adds the label again (awml #120)Outside actionComment on the issue that itchangedAllowCode · doSay in a new comment on theissue, from fixed text, that aperson has taken the branchover, so the build won't tryagain over it, linking CI's runA commit since main that isn't the factory's, by the build rule's author and committer test, means a person has taken the branch over, so it's never built over again. Said once: unless an earlier CI run on a commit from the first such one on already failed its testsOutside actionComment on the issue that aperson took the branch overAllow