Non testiamo i singoli livelli. Costruiamo e testiamo l'intera base di codice yocto che usiamo.
Abbiamo uno script di build che accetta alcuni argomenti:
- versione, "stabile" o ultima git HEAD
- include i ptest o meno
- include strumenti per sviluppatori o non
- architettura da costruire (ad es. qemu, x86, x86_64)
Ora abbiamo più build nel nostro sistema di build:
- Se si costruisce contro l'ultimo git HEAD, non si esegue una compilazione pulita e si aggiornano semplicemente i meta * layer (rsync -a --delete). A volte dobbiamo cancellare la cartella di questa build. Queste sono build veloci.
- Se realizziamo una build "release", facciamo una build pulita
- Se facciamo una build "stabile", facciamo una build pulita
Crea ulteriori build in base alle esigenze (ad esempio con ptest o strumenti per sviluppatori).
Lo script di compilazione ci consente anche di copiare i file scaricati nelle versioni o definire di avere una build 'senza rete' che recupera i file di origine da una cartella.
Per quanto riguarda i test automatici non siamo ancora così lontani (non è possibile eseguire qemu sulla VM di compilazione). Ma il ptest è un buon inizio e vogliamo automatizzarlo in futuro. Yocto stesso fornisce anche alcune opzioni qui, ma non le ho ancora esaminate.
Per quanto riguarda i ptest ci sono alcuni problemi aperti di dipendenze mancanti (come perl ptest), quindi abbiamo creato uno script di esecuzione ptest indivuale che verifica solo i pacchetti con il nome xy- (dove xy è la nostra scorciatoia aziendale, tutti i pacchetti da noi sono separati in questo modo). C'è anche un pacchetto addizionale che contiene solo ptest per software da livelli pubblici aperti e yocto che vogliamo testare.