chrismdp / ci-a-commitA commit is checkedPublic · Version 1 of 1ForkWho may see each partWhere each part runsYAMLChecksNo mistakespublicanyone who reads the repositorythe committhe committhe commit's code[pass or fail][its own people's]the patch and the pull request'stextits findingsits findings[both reviews passed, on theapp's pull request from afactory branch]both reviews' findingsship, show or ask, with itsreasonsTriggerA pull request from any branchbut main is opened or pushedto, or a commit is pushed tomainDecided in #160's follow-up: CI runs on pull_request for every branch but main, and on push only for main, so each commit has one run. The build pushes, then opens its pull request, so CI first runs when it opensLinked to chrismdp/issue-to-pull-request#tokenConnectionThe repository, through itsown Actions tokenData · untrustedThe commit as pushed, and itspull request's title anddescription, if it has oneCode · checkRun the tests, vet, theexamples and wasm parity, onGo 1.22 and on the newest GoA fork's pull request, or one a stranger opened between two branches here, gets no review: its author could steer the sessions, which hold the maintainer's login token. Its review jobs still run, and fail at the gate before any secret is given, since GitHub counts a skipped required check as passed. The test jobs hold no secret and a token that only reads. Keeping the check on who opened it was agreed in #160's follow-upCode · doRecord each test job's resultas its check on the commitCode · sortSort by rule, in a gate thatholds no secret: is this apull_request run from a branchof this repository, opened byits own people or the app? Ifnot, the review fails here. Apush to main runs the testsonlyCode · bring-inBring in the pull request'spatch against main as data,and list the binary files itchanges in a file of the job'sownThe list of binary files is written by this step to a file of its own, which the prompts point at, so text in the patch or the description can't forge it (#153)DataThe patch applied to thecommit of main the branchstarts from, made read-only,with the list of binary filesDataMain's review prompts,AGENTS.md and REVIEW.md,copied out before any sessionstartsMain's prompts, AGENTS.md and REVIEW.md are copied out before a session starts, so the patch can't rewrite what it's held to. GitHub runs the pull request's own ci.yml, so a person with write access could change how their pull request is reviewed: they're trusted, and the app never pushes .github/ (#160)AI · checkReview the patch for bugs,with fresh context, keepingonly the findings that survive asecond lookThe sessions read the patch as data and run none of the change's code. No job that holds the Claude token runs tests, make or go run, since the runner has sudo and its memory holds the job's secrets (#160)AI · checkReview the patch for security,in a session of its ownCode · doOnce a review is done, makeits findings the job's owncheck on the commit, failed onan Important findingA session's text is escaped before it's posted: < escaped, mentions broken, length capped. It carries no marker for a workflow to parse, and is refused if it holds anything like a token (#160 rule 5)AI · sortSort by risk, reading the patchand both reviews' findings:ship, show or ask?Classify moved here from the build, so land reads its verdict from a check on the commit rather than from the build's artifact. Its check always passes, so the verdict never wakes the fixer. Only the app's pull request from a factory branch is classified, and only once both gated reviews have passed, so it has no gate of its own (#160)Code · doMake Classify's verdict and itsreasons the job's own check,which always passesUsed by chrismdp/fix-review-findings and chrismdp/land-a-pull-requestData · untrustedThe head commit's checks:test (1.22), test (stable), Bugreview, Security review andClassifyOne judge: these checks on the commit as pushed. Nothing merges without the tests and both reviews passing on the head commit, and land and fix read only these, never a record a workflow passed on (#160 rules 1 and 2) The checks carry text from sessions that read a stranger's patch, so every workflow that reads them treats them as untrusted. Nothing here reaches an outside action: the checks are GitHub's record of this run2Flow only+−Fit