PR-samtaler

En pull request er allerede stedet der samtalen om kode foregår. PR-samtaler gjør den til en flate i et Control Center-arbeidsområde, på samme måte som en chatbro gjør Slack til det: @-nevn serverens GitHub App-bot i en PR, svar inne i gjennomgangstrådene dens, eller legg til etiketten ai-review — og arbeidet skjer i PR-ens gjennomgangsområde, med samme tilskrivning og tillatelsesregler som for alt som skrives i appen. En kommentar er også betinget av medlemskap; det er ikke etiketten, fordi den ikke har noen forfatter. Botens svar kommer tilbake på GitHub, i samme spor som spørsmålet ble stilt i.

Tre beslutninger former funksjonen, og hver av dem er den samme beslutningen chatbroen tok for chat, formulert på nytt for en kodevert: hvilken retning tilkoblingen går i, hva som autoriserer en kommentar som kommer utenfra og hvem hver side tilskrives.

Polling er transporten

GitHubs eneste push-kanal for en app er en webhook, og en webhook trenger en innkommende URL — nettopp det denne flaten bevisst aldri krever. Derfor skjer oppdagelsen i en søkerunde: omtrent hvert minutt spør ett aliasert søk per appinstallasjon GitHub om PR-er som nevner boten (eller den korte slug-en dens) og om åpne PR-er som bærer gjennomgangsetiketten, PR-er som allerede har et gjennomgangsområde får kommentartrådene sine lest, og alt diffes på kommentar-id mot det som ble sett i forrige søkerunde.

Det er verdt å navngi designkonsekvensene:

Forsinkelsen er et søkerundeintervall, ikke en hendelse. 👀-bekreftelsen lander i løpet av omtrent et minutt. Ingenting kritisk hviler på den.
Nøyaktig én gang per kommentar. Kommentar-id-er er unike på tvers av GitHub; hver av dem registreres i det øyeblikket den klassifiseres som kvalifisert, før noe handler på den. Et krasj kan miste behandlingen av en kommentar, men aldri utløse den to ganger.
Etter nedetid tas det igjen, det spilles ikke av på nytt. Mengden av det som er sett, lagres, slik at en omstart leverer det som kom inn mens serveren var nede. Det ene unntaket er den aller første søkerunden: uten noe minne å diffe mot registreres alt utestående i stillhet — en operatør som merket tjue PR-er med etiketten før denne serveren fantes, må ikke komme tilbake til tjue kjørende gjennomganger.
Etiketten er en mengde, ikke en hendelse. Søket rapporterer tilstedeværelse av etiketten, så en merket PR utløser én gang, aldri mer. Å legge etiketten til igjen etter å ha fjernet den, er usynlig for søkerunden; en omtale er veien til å kjøre på nytt.

Søket kjører én gang per installasjonskonto på eierens egen klient, fordi et installasjonstoken bare ser repoene til sin egen installasjon — én felles legitimasjon for hele serveren ville i stillhet overse hver PR under appens andre installasjoner.

Medlemskap autoriserer, ikke kommentaren

En PR-kommentar kommer inn med lite annet enn en forfatterpålogging — en uautentisert ekstern identitet inntil det motsatte er bevist. Boten løser den opp mot en omvendt indeks over arbeidsområdets medlemmer og deres tilkoblede GitHub-kontoer, gjenoppbygd med en TTL fordi folk logger inn og blir invitert mens serveren kjører.

Å feile lukket ser ut som en stige, og hvert trinn svarer i tråden det avviste i:

En ukjent pålogging — ikke tilkoblet, eller tilkoblet av noen som ikke er medlem av dette arbeidsområdet — får beskjed om å logge inn og sørge for at de hører til
Et skrivebeskyttet medlem (viewer eller guest) får beskjed om at rollen deres ikke kan starte arbeid

De to tilfellene med ukjent pålogging deler ett svar: den omvendte indeksen returnerer bare et medlem av dette arbeidsområdet, så en ikke-tilkoblet konto og en tilkoblet ikke-medlem er samme bom. Ingen av dem går videre. En kommentar tilskrives aldri noen som ikke sendte den, og en fremmeds ord kommer aldri inn i et arbeidsområde de ikke kan se.

Etiketten ai-review har ingen forfatter å løse opp, så den klatrer ikke denne stigen. Å legge den til starter gjennomgangen i arbeidsområdet som allerede har repoet tilkoblet.

To identiteter, med vilje

Hver side av samtalen bærer en annen identitet, og forskjellen er selve funksjonen:

På GitHub er boten serveren. Hver kommentar, reaksjon og svar broen legger ut, går på appens installasjonstoken. Ingen har klikket på noe i en klient, så ingenting låner en persons konto — samme regel som holder webhooker og polling unna menneskelig legitimasjon.
I området er spørsmålet ditt. Meldingen tilskrives medlemmet forfatteren ble løst opp til, og agentkjøringen utføres på deres vegne: commits får dem som medforfatter, og områdets autonomiknott og tillatelsesregler for handlinger gjelder nøyaktig som for en melding skrevet i appen. Skrivinger til kodeverten fra kjøringen går fortsatt ut som appen — samme regel som kulepunktet over — ikke på medlemmets personlige token.

Å publisere gjennomgangsfunn tilbake til GitHub er fortsatt en persons beslutning, tatt i Control Center. En omtale kan starte en gjennomgang; bare et menneske publiserer en.

Løkkevernet, og kortnavnet

Alt som er skrevet av en botkonto, forkastes før noen port kjører — vår spesifikt, og enhver [bot]-endelse, slik at en annen apps gjennomgangsbot heller ikke kan vekke vår. Uten dette ville botens egne svar komme inn som nye kommentarer og utløse den på nytt i det uendelige.

[bot]-endelsen er også grunnen til at kortformen finnes. GitHub fastsetter en appkonto sin pålogging til <slug>[bot], tilbyr ingen autofullføring for den og løser aldri @slug opp til appen — så det å godta den bare slug-en er vår matchers beslutning, og å oppdage den krever en rå søkebane for kommentar-tekst i stedet for GitHubs omtaleindeks. Kostnaden sies som den er i stedet for å glattes over: en menneskelig bruker som deler appens slug, adresserer boten med hver kortform-omtale av seg selv. Særegne appnavn gjør kollisjonen hypotetisk.

Det som bevisst ikke tilbys

Ingen automatisk publisering. Funn lander i gjennomgangsområdet; publisering til GitHub er en egen handling utført av et menneske
Ingen uklar identitet. Forfatteren løses opp til nøyaktig ett medlem eller avvises — det finnes ingen tilskrivning basert på gjetting
Ingen GitHub App-webhook. Denne flaten registrerer aldri noen, så det finnes ingen innkommende URL å eksponere for PR-kommentarer. Andre produktwebhooker (pipelines, sakssynkronisering) er et separat, valgfritt oppsett.

Se også

Snakk med Control Center fra en GitHub-PR: slik gjør du det, steg for steg
Chatbroer: de samme tre beslutningene, tatt for chat
Opprett GitHub App: hvor botidentiteten kommer fra
Flerbruker — identitet, medlemskap og tilstedeværelse: partene og rollene en pålogging løses opp gjennom
Tillatelsesregler: hva agenten som svarer, har lov til å gjøre
Bruk AI-drevet gjennomgang: pipelinen en omtale eller etikett starter