Buscando una forma de automatizar la "versión de prueba" con git flow

Question

He estado usando git flow durante un par de meses y ha funcionado muy bien. Me gustaría automatizar la operación de "versión de prueba".

El proyecto es PHP y footer.php tiene un token para reemplazar con la etiqueta de lanzamiento actual. Estoy seguro de que con algunos awk'ing de git log y el archivo PHP todo debería funcionar, pero supongo que alguien ha hecho esto antes ...

¿Alguna idea?

Answer 1

Usted podría utilizar the semver gem, lo que añade un archivo .semver a la raíz de su repositorio git. Semantic version numbers son una recomendación para tener números de versión estructurados/consistentes/significativos, la gema simplemente hace que sea fácil de implementar.

lo tanto, todo lo que se necesita hacer es agregar:

semver inc major|minor|patch 

en su flujo de trabajo (manual o con guión) para que el .semver se actualiza en un comunicado.

Si no quieres la dependencia de ruby, semver es bastante simple, por lo que un poco de experimentación sed probablemente dará como resultado una solución funcional.

Answer 2

Este es el código que usamos para incrementar el número de versión en 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  

Answer 3

En mi proyecto bifurcado de git-flow, en realidad implementé ganchos y filtros, una solicitud que muchos hicieron en el proyecto original pero hasta ahora no se ha implementado. Con ellos puede actualizar automáticamente los números de versión en su proyecto. El proyecto en forma de horquilla se puede encontrar aquí https://github.com/petervanderdoes/gitflow

Para algunos scripts Bash en versión chocar se puede extraer dos GIST creé https://gist.github.com/2877083 o https://gist.github.com/2878492

Answer 4

También hay bumpversion (más información en https://github.com/peritus/bumpversion) que tiene como objetivo reemplazar esa magia sed.

Instalar con pip install bumpversion, indicarle qué archivos contienen su número de versión y si desea confirmarlo y etiquetarlo. También es altamente configurable (con versiones semánticas por defecto), por lo que puede agregar un archivo de configuración declarativa de cómo encontrar versiones para este proyecto de software a su vcs de elección y otras también pueden encontrar versiones.

Answer 5

Semver estados de página web:

un número de versión MAJOR.MINOR.PATCH, incremente el:

• versión mayor cuando se realizan cambios de API incompatibles,
• versión menor cuando se agrega funcionalidad de manera compatible con versiones anteriores, y
• versión de PATCH cuando realiza correcciones de errores compatibles con versiones anteriores.

etiquetas adicionales para pre-liberación y construir los metadatos están disponibles como extensiones a la MAJOR.MINOR.Formato PATCH.

Gitflow utiliza una convención de nomenclatura para las ramas, correcciones de errores viven en las ramas con el prefijo hotfix/ y nuevas características tienen el prefijo feature/.

Cuando cualquier rama de este tipo se fusiona en la rama de liberación, esto hace que PATCH aumente. Si una característica se ha fusionado, el campo MENOR debe aumentarse.

Dada una revisión específica, debería poder determinar si alguna de las ramas se ha fusionado y qué campo encontrar.

Lo difícil es descubrir un cambio de rotura. En el pasado, he considerado utilizar la reflexión en el código compilado para determinar si la API ha cambiado, sin embargo, me parece que sería mucho más fácil quizás solo usar una palabra clave en los mensajes de confirmación para designar los cambios de última hora.

Answer 6

Puede automatizar la versión topando cada confirmación. Aquí puede encontrar que se haga uso de la secuencia de comandos shell y el gancho git incorporada: https://github.com/addonszz/Galileo/tree/develop/githooks

La alforja shell para ejecutar es: https://github.com/evandrocoan/.versioning/blob/master/scripts/updateVersion.sh

El problema sobre Automatizar cada cosa es cómo saber si usted están actualizando Major, Minor, Patch o Build, cuando estás cometiendo todo.

Quiero decir, para la construcción puede automatizar cada compromiso de la rama de desarrollo, como se hace en el enlace de arriba.

El parche, puede enganchar cada acabado de hotfix de git flow. El enlace anterior solo falta para enganchar el final de la revisión para incrementar la versión del parche en ejecución: ./githooks/updateVersion.sh patch

Pero la menor y mayor no hay ningún truco, todas se hacen dentro de la versión de finalización de la función.

Obs

he encontrado una solución para enganchar el pre-revisión-comete, es en la pregunta: How to pre-hook the gitflow hotfix finish?

Answer 7

Si entiendo su operación 'bump versión' correctamente, entonces quiere decir el aumento de la número de versión en un número arbitrario de archivos una vez que comenzó una versión con git flow release start x.x.x, donde la versión también se representa dentro de la etiqueta git.

Dado que el git-flow original de Driessen se suspendió, el sucesor no oficial parece ser Peter van der Does gitflow-avh (https://github.com/petervanderdoes/gitflow-avh/), que contiene una gran cantidad de ganchos de flujo de git. Consulte https://github.com/petervanderdoes/gitflow-avh/tree/develop/hooks para obtener una lista completa.

lo hice versión chocar en post-flow-release-start con este pequeño 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 

Es un poco rígida, ya que los dos archivos están codificados (README.md y package.json). Puede hacer una búsqueda de la versión anterior desde la última etiqueta y luego reajustarla para todos los archivos configurados dentro de un bucle.

Advertencias:
OSX requiere un sufijo para sed -i, puede utilizar comillas vacías sin embargo.Además, el parámetro regex extendido para sed recibe un nombre diferente en Linux.

Answer 8

También puede echar un vistazo a mi repo para bumpversion su momento, hecho para los archivos de configuración de pitón que se pueden modificar Using-bumpversion-package