5 votos

GPG verificación de git etiquetas en una secuencia de comandos de implementación

Nos gustaría nuestro proceso de implementación para tirar directamente de nuestro git repositorio, pero sólo activar nuevos cambios si son firmado (a través de la git tag -s) con una firma GPG. He encontrado muy pocos ejemplos que hay de flujos de trabajo que usar GPG verificación de git etiquetas, de modo que no estoy seguro de si no hay una "mejor práctica" para este tipo de cosas.

Lo que tenemos hasta ahora se ve como esto:

# discard erroneous local changes
git reset --hard HEAD

# get changes
git fetch
start=$(git rev-parse FETCH_HEAD)

# get new tags
git fetch --tags

# find most recent release tag
tag=$(git describe --abbrev=0 --match "release-*" $start)

if git tag -v $tag; then
  git checkout $tag
  ...do stuff...
fi

¿Esto tiene sentido? En particular, con el fin de evitar erróneas los cambios locales que se fastidie el proceso de implementación, es git reset --hard HEAD la cosa correcta a hacer? También, recordando FETCH_HEAD parece de ser necesario, otros sabios etiquetas posterior a HEAD no se muestran en la salida de git describe. Hay otra manera de hacer esto?

Alternativamente, si usted tiene documentado la implementación del flujo de trabajo que utiliza firmado etiquetas para la verificación yo estaría interesado en un enlace.

2voto

chutz Puntos 4628

El título de la pregunta es acerca de firmado etiquetas en un flujo de trabajo de despliegue, pero lo que están pidiendo, que tiene muy poco que ver con la firma de las etiquetas. Y en realidad el único paso que sería diferente es la verificación de las etiquetas, y que ya están haciendo eso.

git reset --hard HEAD no va a limpiar sin marcar archivos locales, que muy bien puede arruinar su proceso de construcción. Después de la git reset --hard usted lo desea, puede también ejecutar git clean -d -x -f.

git fetch puede capturar varias ramas, o puede no obtener lo que usted esperaría de ti a buscar. Todos los recuperan las ramas serían agregados a .git/FETCH_HEAD así que para evitar sorpresas cuando se utiliza el FETCH_HEAD ref, yo recomendaría ir a buscar su liberación de la rama de forma explícita. Algo como git fetch $remote $branch.

Usted está preguntando si existe una "mejor" manera de hacer esto, pero personalmente creo que esto es lo suficientemente bueno. Si su objetivo es evitar la innecesaria ir a buscar, entonces usted puede jugar con la salida de git ls-remote pero es que realmente no vale la pena el esfuerzo.

Personalmente, para reproducible construye yo simplemente iniciar la construcción en un directorio limpio en todo momento. dir=$(mktemp -d); cd $dir; git init; git remote add ... y así sucesivamente. De esta manera usted puede mover fácilmente esta secuencia de comandos en una máquina diferente. Para acelerar la recuperación inicial, usted puede decirle al directorio temporal para encontrar git objetos de la permanente directorio local con un echo $permanent_git_directory/.git/objects > .git/objects/info/alternates (man gitrepository-layout para más información).

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: