Revisioni delle pull request
La maggior parte degli incidenti inizia con una modifica. Polylane revisiona ogni pull request in un repository collegato rispetto alle risorse di produzione su cui viene deployata, e pubblica un solo commento che dice pass o fail.
Cosa fa
Un agente legge il diff e le metriche live, i log e le issue aperte delle risorse su cui il repository viene deployato, poi decide se la modifica può danneggiare la produzione. Ricevi un commento sulla pull request, un check facoltativo Polylane production impact e un thread nella console con l'analisi completa.
Come funziona
- Aprire una pull request verso il branch predefinito, fare push su di essa o marcarla pronta per la revisione avvia una revisione del suo commit di testa. Le bozze non vengono revisionate.
- Un push successivo sostituisce la revisione in corso, così viene giudicato solo il commit più recente.
- Le modifiche che toccano solo documentazione, test o file di CI passano senza un'indagine.
- Polylane segue gli archi di deploy del repository fino alle sue risorse di produzione, oppure revisiona rispetto agli account cloud del workspace nel loro insieme quando non ne ha.
- L'agente indaga in un thread e registra un verdetto
passofail. - Un solo commento per pull request viene modificato a ogni revisione. Un fail recita Hold this merge con il livello di impatto e il risultato; un pass recita Production impact unlikely, oppure dice se ci si aspetta che una correzione per una issue rilevata la risolva. Quando un push successivo risolve un problema, il commento torna a un pass e lo dice.
L'agente può anche suggerire miglioramenti di osservabilità, come un'unica revisione raggruppata di commenti di suggerimento o come pull request impilata. Non influenzano mai il verdetto.
Agire su una revisione
Menziona @polylane in un commento sulla pull request e Polylane risponde nella stessa conversazione; i non membri ricevono invece una nota sull'accesso.
| Cosa chiedi | Cosa succede |
|---|---|
| Una domanda | L'agente risponde dal thread della revisione, con le evidenze davanti. |
| Un altro sguardo | L'agente revisiona di nuovo l'ultimo push e riconsidera il verdetto. |
| Una correzione | Polylane avvia un fix run e apre una pull request impilata sul branch della pull request, collegata dal commento. |
La scheda Changes del repository nella console elenca ogni revisione. Un fail offre Fix with Polylane, che avvia lo stesso fix run, e Dismiss quando il problema non si applica: la pull request continua a essere revisionata ma non riceve più commenti finché non la ripristini con Restore.
| Stato | Descrizione |
|---|---|
| In review | Polylane sta revisionando l'ultimo push. |
| Flagged | La revisione ha trovato un problema di produzione. |
| Passed | Nessun problema di produzione trovato. |
| Resolved | Un push successivo ha risolto i problemi. |
| Dismissed | Un membro ha scartato la revisione; la pull request non riceve più commenti. |
Configurazione
Le revisioni sono attive per ogni repository collegato. Settings > Pull request reviews le disattiva per tutto il workspace e stabilisce se i thread di revisione sono condivisi con chi vede la pull request. Sotto Settings > Repositories, la scheda Settings di un repository aggiunge tre campi.
| Campo | Descrizione |
|---|---|
| Review pull requests for production impact | Disattiva le revisioni solo per questo repository. |
| Pull request review instructions | Testo libero che l'agente legge a ogni revisione: percorsi critici per il deploy, o aspetti che altri gate già gestiscono. |
| Block merging on production concerns | Pubblica il check Polylane production impact su ogni pull request revisionata; fallisce in presenza di un problema. Attivo per impostazione predefinita. Rendilo obbligatorio nella branch protection per bloccare il merge. |
Il check si completa anche sui commit della merge queue, dato che la pull request è stata revisionata prima di entrare in coda. Un verdetto fail può inviare l'email Production Concern Found, disattivata per impostazione predefinita sotto Notifiche.
Note sui piani
Ogni piano include un numero mensile di revisioni delle pull request; la quota del piano Free è indicata in Fatturazione e utilizzo, e i membri ricevono un'email quando si sta esaurendo. Oltre la quota, la console registra la pull request come Production impact not verified e nulla viene pubblicato su GitHub.
Correlati
- Repository per collegare un repository e collegare le sue risorse.
- Fix run per come un thread di revisione raggiunge il suo verdetto.
- Autofix per le pull request che un fix run apre.
- Notifiche per l'email che una revisione fallita può inviare.
Issue
Ogni problema che Polylane rileva o riceve dal tuo alerting diventa una issue, lavorata da un solo fix run il cui thread racconta l'intera storia.
Advisories
Raccomandazioni per singola risorsa su configurazioni errate, rischi di resilienza e lacune di osservabilità, ciascuna con una correzione che puoi passare a un agente.