Come aggiungere un semplice test STI per un pacchetto
Test come singolo comando
Task
Esiste un pacchetto somepackage, che contiene un binario: /usr/bin/somebinary
Il modo più semplice e ovvio per testare questo binario è eseguirlo: somebinary --help e controllare lo stato di uscita del risultato.
Come aggiungere questo test per il pacchetto?
Il framework Ruoli Test Standard fornisce una soluzione per il task. È pienamente supportato in Fedora Rawhide.
Soluzione
Crea il file tests/tests.yml nel dist-git del pacchetto:
.
├── 0001-something.patch
├── somepackage.spec
├── sources
└── tests
└── tests.yml
tests.yml è un playbook ansible, in cui descrivi l’ambiente di test e i passaggi per eseguire i tuoi test.
Ci sono molte opzioni e esempi disponibili, ma concentriamoci sul compito attuale: vogliamo eseguire solo un comando.
Per questo caso, il contenuto del file dovrebbe essere il seguente:
- hosts: localhost
roles:
- role: standard-test-basic (1)
tags:
- classic
tests:
- simple:
dir: .
run: "somebinary --help" (2)| 1 | questo è un ruolo di test standard, si occupa dell’ambiente di test, del logging, dell’archiviazione dei risultati, ecc |
| 2 | questo è il tuo comando di test, il suo codice di uscita definisce l’esito del test |
Invia la tua modifica come pull request per vedere i risultati dei test nell’interfaccia di Pagure, oppure spingila direttamente in dist-git e ottieni nuovi risultati dei test ogni volta che costruisci il pacchetto in Koji.
| Il test verrà eseguito in modalità non bloccante fino a quando non configurerai la gating per esso. |
Test in un (sotto)pacchetto
Task
Esiste un pacchetto somepackage, e per esso esiste una suite di test di integrazione impacchettata in un pacchetto separato sometests, che fornisce il binario run_some_tests nel percorso di sistema.
L’obiettivo è attivare questo binario come test per il pacchetto principale.
Soluzione
Come sopra, è necessario creare un file di configurazione tests.yml con il seguente contenuto:
---
- hosts: localhost
roles:
- role: standard-test-basic
tags:
- classic
required_packages:
- sometests (1)
tests:
- integration_tests: (2)
dir: .
run: run_some_tests (3)| 1 | pacchetto aggiuntivo che deve essere installato nell’ambiente di test |
| 2 | qualsiasi stringa, verrà utilizzata come identificatore per gli artefatti e i risultati del test |
| 3 | comando di esecuzione del test |
Test in repository esterno
Task
Ora esaminiamo una configurazione leggermente più complessa.
Supponiamo che esista un pacchetto somepackage che stiamo per testare. Per esso esiste una suite di test di integrazione, che (purtroppo) non è ancora impacchettata e si trova in un repository git separato https://somewhere/sometests.git. La suite di test ha una dipendenza da uno strumento impacchettato sometool. E nel repository di test c’è uno script run_some_tests che attiva l’esecuzione dei test.
L’obiettivo è attivare l’esecuzione della suite di test per un pacchetto.
Soluzione
Dobbiamo creare un file di configurazione tests.yml con il seguente contenuto:
---
- hosts: localhost
roles:
- role: standard-test-basic (1)
tags:
- classic
required_packages:
- sometool (2)
repositories:
- repo: "https://somewhere/sometests.git" (3)
dest: "sometests" (4)
tests:
- integration_tests: (5)
dir: "sometests" (6)
run: "run_some_tests --all" (7)| 1 | stesso ruolo di test di base come al solito |
| 2 | pacchetto aggiuntivo che deve essere installato nell’ambiente di test |
| 3 | percorso al repository git remoto |
| 4 | percorso locale in cui il repository verrà scaricato |
| 5 | qualsiasi stringa, verrà utilizzata come identificatore per gli artefatti e i risultati del test |
| 6 | stessa cartella come in <4>, contiene il repository esterno scaricato |
| 7 | comando di esecuzione del test |
Domande
E se volessi eseguire non uno ma una sequenza di comandi?
Metti uno script bash nella cartella tests/scripts/ ed eseguilo dal playbook.
.
├── 0001-something.patch
├── somepackage.spec
├── sources
└── tests
├── scripts
│ └── run_tests.sh (1)
└── tests.yml
| 1 | il tuo scenario di test personalizzato |
Configura il test dist-git per eseguire questo script:
- hosts: localhost
roles:
- role: standard-test-basic (1)
tags:
- classic
tests:
- simple:
dir: scripts (2)
run: ./run_tests.sh (3)| 1 | stesso ruolo standard |
| 2 | passa alla sottocartella (il percorso è relativo alla cartella tests/) |
| 3 | questo è lo script di test, il suo codice di uscita è il risultato del test |
Cosa c’è sotto il cofano? (Ovvero, come funziona internamente?)
Per testare la build noi:
-
scarichiamo (checkout) il repository dist-git
-
prendiamo l’ultima immagine qcow di Fedora Rawhide
-
installiamo tutti i pacchetti della build di koji su di essa
-
eseguiamo il playbook ansible definito in tests.yml
Come verifico la mia configurazione?
È possibile eseguire e debug i ruoli di test standard localmente. Ma consigliamo vivamente di utilizzare il flusso di lavoro delle pull-request per questo: crea semplicemente una pull-request e attendi che la CI reagisca ad essa.
Attiviamo quasi la stessa infrastruttura CI per il testing delle PR come quella utilizzata per la gating delle nuove build.
E non appena il risultato del test è pronto, apparirà nella pagina della pull request su Fedora Pagure
Per riavviare il test aggiungi un commento alla PR in Pagure, con il seguente contenuto: [citest]
Want to help? Learn how to contribute to Fedora Docs ›