Le migliori pratiche per contrassegnare i tarball di costruzione come test unità / componente superato

7

Durante il nostro attuale processo di compilazione, abbiamo un codice C che viene compilato e archiviato insieme a qualche codice Python in un tarball. Quel tarball rappresenta un commit (che può essere o non essere un commit di rilascio).

In alcuni dei nostri flussi Jenkins, il codice è in fase di test e in alcuni non lo è. Ma le informazioni relative a ogni specifico tarball, sia che siano passati Test unitario o Component Test, rimangono solo nel lavoro di Jenkins, e sono perse dopo la fine del lavoro.

Guardando un tarball esistente, non posso dire se ha passato nessuno dei test, e non c'è modo che io sappia, di interrogare Jenkins su questo specifico build-flow e sui risultati dei suoi "lavori". / p>

Le migliori opzioni che potrei pensare di contrassegnare e salvare i risultati dei test sono:

  1. Aggiungi un file alla directory principale dei progetti (il file verrà salvato all'interno del tarball) che indica i test passati (ad esempio .passedunittest , .passedcomponenttest ).
  2. Aggiungi un file di testo nella directory in cui sono salvati i tarball, che fungerà da database per i tarball, riguardo ai test passati o falliti.
  3. Aggiungi un componente al nome file tarball che indica i test che ha superato.

Mi sento bene con tutte e 3 le opzioni, ma personalmente preferisco la 1a, ma mi succede che mi sento bene con soluzioni ridicole. C'è una buona pratica in questo caso? E se c'è, cos'è?

    
posta Quaker 26.02.2017 - 18:14
fonte

3 risposte

1

Dipende dal tuo flusso di lavoro. Cosa fai con i tarball di compilazione?

L'aggiunta del file dei risultati del test al tarball sembra più semplice per l'ispezione "manuale" / sul posto.

OTOH aggiungendo un componente name permette di usare ls , sort e head per scegliere l'ultimo tarball riuscito senza ispezionare il contenuto.

Se sposti gli artefatti di costruzione, puoi utilizzare git-annex per spostarli entrambi in modo controllato e associare un messaggio di commit (e magari una firma) con essi.

    
risposta data 07.05.2018 - 20:02
fonte
1

Potresti usare i codici dei caratteri per segnalare build in sospeso, passati o falliti.

app.SS.tar

La prima S indica che i test unitari hanno avuto esito positivo. La seconda S indica che i test dei componenti hanno avuto esito positivo.

I test sui componenti di unità e guasti che hanno avuto esito positivo sono:

app.SF.tar

Non sono stati ancora eseguiti test unitari di successo e test dei componenti:

app.SP.tar

Fondamentalmente ogni esecuzione di test ottiene una posizione di carattere prima dell'estensione del file. Poi:

  • P è in sospeso
  • S ha successo
  • F non è riuscito
risposta data 07.07.2018 - 15:38
fonte
-2

Utilizzare il log di commit per memorizzare i risultati del test sarebbe la migliore pratica:

Data are ideal for managing with Git. These include data manually entered via spreadsheets, recorded as part of observational studies, or ones retrieved from sensors (see also section on Managing large data). With each significant change or additions, commits can record a log those activities (e.g. “Entered data collected between 12/10/2012 and 12/20/2012”, or “Updated data from temperature loggers for December 2012”). Over time this process avoids proliferation of files, while the Git history maintains a complete provenance that can be reviewed at any time. When errors are discovered, earlier versions of a file can be reverted without affecting other assets in the project.

Riferimenti

risposta data 08.03.2018 - 14:17
fonte