chrismdp / systems / factory

The AWML factory

System · Public ·
Version 2 of 4
  1. #4 · chrismdp · Latest
  2. #3 · chrismdp ·
  3. #2 · chrismdp · Showing
  4. #1 · chrismdp ·

How an issue on chrismdp/awml becomes a merged pull request. A maintainer labels an issue build; Claude drafts the change, the checks run, two fresh sessions review it for bugs and security, and a classifier weighs its risk before the pull request opens. Every pull request from the repository's own people is then reviewed again as GitHub checks. Once CI has run, a rule merges a straightforward change or asks for review. A failed try starts the build again, up to three times.

What waits on a person

  • The build label is the yes of someone with write access to the issue as it reads then · a review
  • The maintainer's standing approval: the app's pushes to the issue's own branch only, up to three builds an issue, accepted by the maintainer in #160, under rule 4 · a person's step
  • The maintainer's standing approval: one open pull request an issue, from its own branch, accepted by the maintainer in #160, under rule 4 · a person's step
  • Review the pull request, whose CI has passed, and merge it · a person's step

Where untrusted text reaches

Text from a part marked untrusted follows an outside action into the workflow it starts.

  • The issue and its comments, which anyone can open or write · reaches no outside action · stopped by The build label is the yes of someone with write access to the issue as it reads then, Sort by GitHub's record, passing on only the issue's number: was the build label last added by someone with write access, by their permission, or by the app's bot, and, on a retry's dispatch, does the issue still carry it, and is its lastEditedAt, from GraphQL, older than the label's last labelled event?, Keep only the issue's text, unedited since the label was last added, and the comments of people with admin, maintain or write permission on the repository, by each author's collaborator permission
  • Why the last try failed: the failed tests' log of CI's latest run on the branch · reaches Push the issue's branch and its pictures: Ask, Open the pull request: Ask · stopped by Offer the draft in a new comment on the issue from fixed text: gh run download <run> -n change, the git apply command, and that the artifact lasts 30 days, quoting none of it, Say in a new comment on the issue, from fixed text, that the build stopped before its change reached a pull request, linking the run · risk accepted for Push the issue's branch and its pictures: Ask, by The maintainer's standing approval: the app's pushes to the issue's own branch only, up to three builds an issue, accepted by the maintainer in #160, under rule 4 · risk accepted for Open the pull request: Ask, by The maintainer's standing approval: one open pull request an issue, from its own branch, accepted by the maintainer in #160, under rule 4
  • The head commit's checks: test (1.22), test (stable), Bug review, Security review and Classify · reaches no outside action · stopped by Sort by rule, passing on only the commit's sha, the outcome, the labeller's login and the rule's own reasons from fixed text: Classify's verdict, ship, show or ask, moved towards ask by the rule's tests, a commit that isn't the factory's, a fix commit or Nits left unfixed
  • The pull request's head commit and the branch's commits since main, from git · reaches no outside action · stopped by Sort by rule, passing on only the commit's sha, the outcome, the labeller's login and the rule's own reasons from fixed text: Classify's verdict, ship, show or ask, moved towards ask by the rule's tests, a commit that isn't the factory's, a fix commit or Nits left unfixed

Shared between workflows

  • The repository, through its own Actions token · An issue becomes a pull request, A pull request lands once CI has run, A failed build tries again, A pull request is reviewed
  • The repository, through its own GitHub App · An issue becomes a pull request, A pull request lands once CI has run