Ho usato git flow per un paio di mesi e ha funzionato molto bene. Mi piacerebbe automatizzare l'operazione "bump version".Alla ricerca di un modo per automatizzare la "versione di bump" con git flow
Il progetto è PHP e il footer.php ha un token da sostituire con il tag di rilascio corrente. Sono certo che con alcuni awk'ing di git log e del file PHP tutto dovrebbe funzionare, ma presumo che qualcuno abbia fatto questo prima ...
Qualche idea?
Si potrebbe utilizzare the semver gem, che aggiunge un file .semver alla radice del vostro repository git. Semantic version numbers sono una raccomandazione per avere numeri di versione strutturati/coerenti/significativi, la gemma semplifica l'implementazione.
Quindi, tutto quello che avresti bisogno di fare è aggiungere:
semver inc major|minor|patch
nel flusso di lavoro (manualmente o tramite script) in modo che il .semver viene aggiornato durante un rilascio.
Se non si desidera la dipendenza da ruby, semere è piuttosto semplice, quindi un po 'di sperimentazione sed probabilmente produrrà una soluzione di lavoro.
Ecco il codice che utilizziamo per incrementare il numero di versione in constants.h:
constants='../Include/constants.h'
# Get the current build number
currentbuild=`grep PRODUCT_BUILD $constants|sed 's/[^0-9]//g'`
currentversion=`grep PRODUCT_VERSION $constants|sed 's/[^.0-9]//g'`
echo "currentbuild=$currentbuild and currentversion=$currentversion"
newver=$((1+$currentbuild))
# Update the build number on-disk:
cp $constants /tmp/constants
if sed -e "/PRODUCT_BUILD/ s/[0-9][0-9]*/${newver}/" </tmp/constants> $constants
then
echo "Updated build number from $currentversion.$currentbuild to $currentversion.$newver."
cd ../Include
# Check it into version control
svn ci -m "updated build number to ${currentversion}.${newver} for $buildid in $buildroot"
else
echo "There was a problem updating $constants to build $newver"
fi
Nel mio progetto biforcuto di git-flow ho effettivamente implementato ganci e filtri, una richiesta che molti hanno fatto nel progetto originale ma finora non è stata implementata. Con quelli puoi aggiornare automaticamente i numeri di versione nel tuo progetto. Il progetto biforcuta può essere trovato qui https://github.com/petervanderdoes/gitflow
Per alcuni script Bash sulla versione urtando è possibile controllare due GIST ho creato https://gist.github.com/2877083 o https://gist.github.com/2878492
C'è anche bumpversion (maggiori informazioni a https://github.com/peritus/bumpversion) che mira a sostituire quella magia sedata.
Installare con pip install bumpversion, indicare quali file contengono il numero di versione e se si desidera eseguire il commit e contrassegnarlo. È anche altamente configurabile (con versioni semantiche di default), quindi è possibile aggiungere un file di configurazione dichiarativo su come eseguire il bump delle versioni per questo progetto software sui propri vcs di scelta e altri possono anche eseguire il bump delle versioni.
Semver pagina web afferma:
Dato un numero di versione Major.Minor.Patch, incrementare il:
- versione principale quando si apportano modifiche API incompatibili,
- versione minore quando si aggiunge funzionalità in un modo compatibile con le versioni precedenti e
- PATCH versione quando si apportano correzioni di errori compatibili con le versioni precedenti.
Ulteriori etichette per i metadati di pre-release e di build sono disponibili come estensioni per MAJOR.MINOR.Formato PATCH.
Gitflow utilizza una convenzione di denominazione per le filiali, correzioni di bug vivono sui rami con prefisso hotfix/ e nuove funzionalità sono preceduti da feature/.
Quando un ramo di questo tipo viene unito nel ramo di rilascio, ciò causa l'aumento di PATCH. Se una funzione è stata unita, il campo MINORE dovrebbe essere aumentato.
Data una revisione specifica, dovresti essere in grado di capire se uno dei rami è stato unito e quale campo eseguire il bump.
La parte difficile è capire un cambiamento di rottura. In passato ho preso in considerazione l'uso della riflessione sul codice compilato per determinare se l'API è stata modificata, tuttavia, penso che sarebbe molto più semplice forse usare semplicemente una parola chiave nei messaggi di commit per designare modifiche di rottura.
È possibile automatizzare la versione eseguendo il bump di ogni commit. Qui si può trovare fatto usando lo script di shell e il gancio git built-in: https://github.com/addonszz/Galileo/tree/develop/githooks
Il guscio bisaccia da eseguire è: https://github.com/evandrocoan/.versioning/blob/master/scripts/updateVersion.sh
il problema circa automatizzare ogni cosa è come sapere se si stanno aggiornando Major, Minor, Patch o Build, quando stai commettendo tutto.
Voglio dire, per la build è possibile automatizzare ogni commit di ramo di sviluppo, come fatto nel link sopra.
La patch, è possibile agganciare ogni finitura hotfix del flusso git. Il collegamento sopra manca semplicemente per agganciare la correzione rapida per incrementare la versione della patch in esecuzione: ./githooks/updateVersion.sh patch
Ma il minore e il maggiore non ci sono trucchi, sono tutti fatti all'interno della versione finale.
ho trovato una soluzione per agganciando il pre-correzione-commette, è sulla domanda: How to pre-hook the gitflow hotfix finish?
Se ho capito bene la vostra operazione 'urto versione', allora vuol dire aumentare la numero di versione in un numero arbitrario di file dopo aver avviato una versione con git flow release start x.x.x, in cui la versione è rappresentata anche all'interno del tag git.
Poiché il flusso originale di Driessen è stato interrotto, il successore non ufficiale sembra essere Peter van der Does gitflow-avh (https://github.com/petervanderdoes/gitflow-avh/), che contiene un gran numero di ganci di flusso git. Vedere https://github.com/petervanderdoes/gitflow-avh/tree/develop/hooks per un elenco completo.
ho fatto sbattere la versione su post-flow-release-start con questo piccolo script:
VERSION=$1
# Get rid of version prefix
STRIPPED_VERSION=`echo $VERSION | cut -d'v' -f 2`
sed -i '' -E "s/^([ |#|[:alpha:]]*)\[.*\]$/\1[$STRIPPED_VERSION]/1" ./README.md
sed -i '' -E "s/^([\t| ]*\"version\":)\".*\"/\1\"$STRIPPED_VERSION\"/1" ./package.json
git commit -a -m "version $STRIPPED_VERSION"
exit 0
E 'un po' rigida, in quanto i due file sono fissi (README.md e package.json). È possibile eseguire una ricerca della versione precedente dall'ultimo tag e quindi sostituirla per tutti i file configurati all'interno di un ciclo.
Caveat:
OSX richiede un suffisso per sed -i, tuttavia è possibile utilizzare virgolette vuote.Inoltre, il parametro regex esteso per sed è denominato diversamente su Linux.
Si può anche dare un'occhiata al mio repo per bumpversion la sua attualmente fatto per i file di installazione di pitone, che possono essere modificati Using-bumpversion-package
Questo è un piccolo ingegnoso strumento. Grazie – Alex
'bumpversion' sembra essere stato abbandonato dallo sviluppatore originale, ma c'è una [fork] (https://github.com/c4urself/bump2version) che è più attivamente mantenuta e aggiunge alcune funzionalità come i tag anotated. – ostrokach