Un modo elegante per memorizzare il contatore delle build [chiuso]

3

Usiamo Git e Jenkins come sistema di generazione e rilascio e ad ogni build viene assegnato un numero di versione simile al seguente: 6.0.12345 . Qui, la parte 12345 è un contatore che aumenta a ogni build. Il contatore viene memorizzato sul server di build in un semplice file di testo, che viene riscritto ogni volta che si verifica una compilazione. Vale la pena notare che questo file non è sotto controllo di versione.

Stavo pensando a un modo più elegante di gestire i numeri di build, che consentirà una portabilità più semplice (ad esempio move build server su una nuova macchina) e scalabilità (l'aggiunta di un altro build server sarebbe molto complicata con la configurazione corrente).

L'unica cosa a cui riesco a pensare ora è usare il commit hash anziché il numero, ma questo renderà difficile dire quale delle due build sia arrivata prima, inoltre, non penso che i clienti saranno disposti ad accettare un tale cambiamento .

Qualche idea è apprezzata.

    
posta Dmitrii Erokhin 05.01.2016 - 11:12
fonte

1 risposta

5

Quando dici che ad ogni build viene "assegnato un numero di versione", intendi che il commit associato a quella build è anche taggato con quel numero di build in git? Se non lo fai, dovresti:

git tag -a 6.0.12345 -m "Successful build on 2016-01-04 23:09:01.441"
git push --tags

Se lo sei, dovresti semplicemente usare git per dirti quale sia l'ultimo tag invece di rintracciarlo separatamente:

git describe --tags $(git rev-list --tags --max-count=1)

Il tuo sistema di build quindi analizzerebbe quel tag per ottenere l'ultimo numero di build, incrementarlo e creare il nuovo tag di versione.

    
risposta data 05.01.2016 - 12:56
fonte

Leggi altre domande sui tag