Fedora CI

Fedora Continuous Integration Portal

Perché

Visione

Ci sono centinaia di pacchetti che costituiscono il Sistema Operativo. Assicurarsi che funzionino tutti insieme come un tutt’uno non è un compito facile. Questo diventa ancora più difficile con l’aumento del numero di pacchetti e delle loro interdipendenze. È necessario un testing estensivo prima che una nuova versione del sistema operativo venga rilasciata, per garantire che sia sufficientemente stabile. Questo è il passato.

Immagina un Sistema Operativo Sempre Pronto costituito da pacchetti che sono costantemente mantenuti in buono stato. Integrato e stabile grazie a un’ampia copertura di test che viene eseguita continuamente in seguito a modifiche nei singoli pacchetti, consentendo in questo modo di preparare una nuova versione in un tempo molto più breve, o addirittura in tempo zero.

Immagina una distribuzione di un sistema operativo che potresti rilasciare in qualsiasi momento. È verso questa direzione che ci stiamo dirigendo. Ecco che arriva la CI, Integrazione Continua, come uno strumento inestimabile per garantire che tutto funzioni insieme come previsto in ogni momento.

Manifesto

L’integrazione continua mira a garantire che le modifiche errate vengano rilevate il prima possibile e non influenzino altri sviluppatori, packager, maintainer o utenti. Il feedback fornito dall’integrazione continua è vitale per una consegna agile e rapida del software. Il testing tardivo, molto tempo dopo che una modifica è avvenuta, non si adatta al ritmo di Fedora. Impara gli obiettivi, la terminologia e le regole per una CI funzionante nel manifesto.

Come

Ci sono tre elementi principali del puzzle per far funzionare bene questo sistema: un processo che definisca chiaramente come scoprire ed eseguire i test, una serie di strumenti che aiutino a implementare in modo efficiente il processo e i test stessi.

Processo

Abilitazione dei Test

I test possono essere abilitati utilizzando le Specifiche dei Metadati dei Test implementate dal Test Management Tool, che fornisce numerose funzionalità per lavorare in modo efficiente con i test ed è ora il metodo consigliato. L'Interfaccia Test Standard è ancora supportata ma è considerata obsoleta.

Gating

Quando un test fallisce, la CI può impedire che la modifica difettosa influisca su altri pacchetti. Tale gating avviene in Bodhi. Greenwave viene utilizzato insieme a ResultsDB e WaiverDB per prendere la decisione di gating.

  • Gating …​ come abilitare la gating, istruzioni per la deroga (waiving)

  • Bodhi …​ Sistema di aggiornamenti di Fedora

  • Greenwave …​ servizio per valutare le politiche di gating in base ai risultati dei test

  • ResultsDB …​ motore di archiviazione dei risultati

  • WaiverDB …​ servizio per registrare le deroghe contro i risultati dei test

Notifiche

Le Notifiche Fedora sono state regolate per notificare per impostazione predefinita ogni packager quando un qualsiasi passaggio della pipeline CI fallisce su uno dei pacchetti che mantiene. Quindi se sei un maintainer del kernel e un commit effettuato nel repository dist-git del kernel fallisce nel comporre un OSTree, FMN ti notificherà di ciò.

Bodhi include i risultati della CI nella sua pagina di aggiornamento, proprio come include già i risultati dei test da taskotron.

Messaggi

Vari strumenti coinvolti nell’automazione della CI inviano aggiornamenti sull’andamento del testing al message bus. Il formato coerente dei messaggi della CI consente di costruire servizi più semplici che forniranno funzionalità utili per tutti.

Tool

Test Management Tool

Lo strumento tmt fornisce un modo semplice per lavorare con i test. Puoi comodamente creare nuovi test, eseguire test in modo sicuro e facile attraverso diversi ambienti, rivedere i risultati dei test, eseguire il debug del codice di test e abilitare i test nella CI utilizzando una configurazione coerente e concisa.

Ruoli Test Standard

I Ruoli Test Standard sono stati implementati per consentire sia agli strumenti di automazione che agli sviluppatori nei loro ambienti locali di eseguire facilmente i test. Questo insieme di ruoli ansible supporta vari framework e consente di eseguire test su diversi soggetti di test (come pacchetti rpm classici, container docker o Atomic Host). I Ruoli Test Standard sono stati resi obsoleti dallo Test Management Tool.

Frameworks

Poiché l’Interfaccia Test Standard non definisce quale framework di test dovrebbe essere utilizzato per il testing, è possibile scegliere il framework più adatto al proprio progetto. Ecco alcuni esempi:

Pipeline

La Pipeline di testing rileva i test per i pacchetti abilitati, esegue la copertura dei test e raccoglie i risultati.

Pagure

I risultati dei test dalla pipeline CI sono visualizzati nell’interfaccia web di Pagure. Vedi la pagina dei commit e le pagine delle pull request del rispettivo pacchetto per vedere i risultati. L’integrazione di Pagure con COPR fornisce la ricostruzione automatica e la segnalazione delle pull request/commit sulle nuove modifiche.

Test

Il nucleo del successo della CI sono test affidabili di buona qualità, ben selezionati, stabili, organizzati e mantenuti continuamente.

Tipi di test

In generale ha senso archiviare i test il più vicino possibile all’upstream. Quindi quali sono i tipi di test appropriati raccomandati per testare il Sistema Operativo Sempre Pronto?

  • Test di funzionalità di base

  • Test di integrazione

Per i test unitari di solito ha più senso archiviarli direttamente all’interno del repository del progetto upstream. Tuttavia, in alcuni casi potrebbe valere la pena recuperare i test per la CI di Fedora anche dal repository upstream.

Codice di Test

Il codice di test può essere memorizzato direttamente nel dist-git o recuperato da un altro repository. La configurazione minima per abilitare un semplice smoke test è la seguente:

execute:
    script: foo --version

I test da un repository condiviso possono essere abilitati in questo modo:

discover:
    how: fmf
    url: https://src.fedoraproject.org/tests/shell
execute:
    how: tmt

Vedi la documentazione dello Test Management Tool per ulteriori dettagli ed esempi.

Esecuzione dei Test

Eseguire i test è semplice come eseguire un singolo comando:

tmt run

Scopri di più nella sezione Esecuzione dei Test.

Responsabilità Condivisa

La proprietà e la manutenzione dei test dovrebbero essere condivise tra QE e Sviluppo (Devel). Per i test che risiedono nel namespace rpm, QE può utilizzare le pull request per creare/aggiornare i test. Allo stesso modo, nel namespace dei test, sia QE che Sviluppo avranno diritti di commit, e sia QE che Sviluppo dovrebbero rivedere e approvare ogni commit.

Altro

Contatto

Se hai domande o desideri partecipare:

Link

Ecco alcuni collegamenti aggiuntivi correlati:

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