Onboarding di un Sistema CI

Testing in Fedora

È relativamente facile iniziare a testare gli artefatti di Fedora (build di Koji, aggiornamenti di Bodhi, ecc.) e contribuire con i risultati dei test in modo che possano essere successivamente utilizzati per il gating — ovvero per decidere se l’artefatto testato debba essere promosso o meno.

Qui descriviamo i passaggi necessari per aggiungere un nuovo sistema CI.

Che cos’è un Sistema CI (idoneo)?

Per fornire un buon flusso di lavoro e un’esperienza utente soddisfacente, ecco alcuni aspetti dei sistemi CI che si sono dimostrati efficaci:

  • I test sono affidabili (bassi tassi di falsi negativi e falsi positivi) e coprono scenari importanti

  • I test possono essere contribuiti (modello open source) e idealmente sono simili ad altri test, ad esempio utilizzando framework/linguaggi consolidati

  • Risultati/notifiche sono facili da comprendere e aiutano a identificare rapidamente gli errori

  • I test sono riproducibili, se necessario gli artefatti delle esecuzioni dei test vengono conservati per essere utilizzati dagli utenti, come le immagini delle macchine virtuali

In breve, i risultati dei test dovrebbero essere direttamente utilizzabili! Come sviluppatore, devo decidere rapidamente se è il test a essere rotto o il codice, e poi risolvere il problema.

Testing e Gating delle Build

Flusso di lavoro per il gating

Al livello più alto, il flusso di lavoro del gating consiste nei seguenti passaggi:

  • Invia una build di un pacchetto (Koji)

  • Attiva i sistemi CI per eseguire i test (Fedora CI, Il tuo CI, ecc.)

  • Raccogli i risultati dai sistemi CI (ResultsDB)

  • Prendi una decisione (Greenwave)

  • Se la decisione è "pass", allora lascia che la build superi il gate per il repository principale (Bodhi)

Messaggi di Gating

Il processo di gating è implementato come un insieme di servizi che interagiscono tra loro tramite un message bus (FedoraMessaging).

Quindi per aggiungere un componente (ad esempio un sistema CI) al processo, è essenzialmente necessario iniziare a ricevere e inviare messaggi tramite FedoraMessaging.

Scopri di più su gating in Fedora Rawhide — in particolare sugli aggiornamenti single e multi-build.

Come aggiungere un Sistema CI

I sistemi CI in Fedora sono entità autonome che tipicamente devono gestire le seguenti cose:

  • attivazione quando si verificano determinati eventi

  • testing effettivo

  • pubblicazione dei risultati dei test

Attivazione e Testing

I servizi in Fedora pubblicano messaggi quando si verificano vari eventi e pertanto i sistemi CI possono attivare il testing quando, ad esempio, viene creato un nuovo aggiornamento Bodhi.

Quando un aggiornamento Bodhi viene creato, un nuovo messaggio "koji-build-group.build.complete" viene pubblicato sul topic org.fedoraproject.prod.bodhi.update.status.testing.koji-build-group.build.complete.

Lo schema di questi messaggi "koji-build-group.build.complete" è definito nella Specifica dei messaggi CI.

Se il tuo sistema CI è Jenkins, puoi utilizzare il plugin jms-messaging per attivare i tuoi test quando si verificano gli eventi definiti. Ottenere la sintassi di attivazione corretta nelle pipeline Jenkins può essere complicato, ma puoi dare un’occhiata all’esempio esistente qui.

È certamente possibile attivare il testing su altri tipi di eventi, non solo sugli aggiornamenti Bodhi. Puoi trovare altri argomenti (topics) dei messaggi Fedora nella più vecchia documentazione fedmsg2. Tuttavia, fai attenzione: l’elenco è incompleto.

Condivisione dei Risultati dei Test

I sistemi CI dovrebbero pubblicare messaggi CI standardizzati in modo che l’andamento del testing possa essere osservato e i risultati possano essere utilizzati da altri servizi nell’infrastruttura Fedora. Sebbene la pubblicazione dei risultati dei test non sia obbligatoria, i sistemi CI che non pubblicano i messaggi CI standardizzati non possono far parte del processo di gating.

Esistono quattro tipi di messaggi che i sistemi CI dovrebbero inviare:

  • test.queued - quando c’è un artefatto (ad esempio un aggiornamento Bodhi) in una coda in attesa per essere testato

  • test.running - quando il testing è in corso

  • test.complete - quando il testing è terminato

  • test.error - quando il testing non può iniziare o non può terminare a causa di circostanze esterne (tipicamente un errore infrastrutturale)

Questi messaggi hanno schemi ben definiti. Gli schemi fanno parte di la specifica dei messaggi CI.

Per comodità, ecco i collegamenti agli schemi per artefatti koji-build semplici e artefatti koji-build-group:

Identificatori dei Test

Quando invii un messaggio "koji-build.test.complete" al message bus, il risultato del test viene memorizzato nel ResultsDB. Successivamente puoi fare riferimento al risultato del test memorizzato in una politcy Greenwave: "se il test XYZ è passato, lascia passare la build attraverso il gate".

Pertanto hai bisogno di identificatori unici per i risultati dei test.

Gli identificatori dei test sono costruiti da tre parti: namespace del test, categoria del test e tipo di test.

Nello schema "koji-build.test.complete", queste variabili sono rappresentate rispettivamente dai campi namespace, category e type.

Il namespace è sempre un identificativo del tuo sistema CI con il nome del tipo di artefatto, quindi ad esempio: fedora-ci.koji-build, oppure osci.pull-request.

La categoria puoi sceglierla da una lista predefinita:

  • static-analysis (analisi statica)

  • functional (funzionale)

  • integration (integrazione)

  • validation (validazione)

Il tipo è una stringa arbitraria, che puoi definire in base alle specifiche del tuo sistema CI.

È tua responsabilità, in quanto proprietario del sistema CI, mantenere una denominazione coerente dei test nel tuo namespace.

L’identificatore finale del test potrebbe apparire così: fedora-ci.koji-build.tier0.functional

Collegamenti Utili

Want to help? Learn how to contribute to Fedora Docs ›