Come suddividere i livelli di Yocto per l'integrazione continua?

6

Stiamo costruendo software embedded utilizzando una configurazione Linux basata sul progetto Yocto . Abbiamo un paio di configurazioni diverse che stiamo costruendo per scopi diversi (ma lo stesso obiettivo).

Ho lottato con il modo migliore per impostare l'integrazione continua per questo progetto. Idealmente, mi piacerebbe poter riutilizzare la maggior parte degli artefatti, in modo che qualcuno che lavora su un livello specifico possa ottenere un rapido riscontro.

Tuttavia, non ho trovato buoni suggerimenti su come rompere queste build a parte. C'è un modo per separare i vari livelli su cui stiamo lavorando in più build con artefatti condivisi in modo che ci vogliono un paio d'ore prima che gli sviluppatori ottengano feedback da ogni build?

    
posta Paul Becotte 28.04.2014 - 16:25
fonte

1 risposta

1

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:

  1. versione, "stabile" o ultima git HEAD
  2. include i ptest o meno
  3. include strumenti per sviluppatori o non
  4. 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.

    
risposta data 15.05.2014 - 22:36
fonte

Leggi altre domande sui tag