Question GPG vérifiant les tags git dans un script de déploiement


Nous aimerions que notre processus de déploiement tire directement de notre git référentiel, mais n’activez les nouvelles modifications que si elles sont signées (via git tag -s) avec une signature GPG. J'ai trouvé très peu d'exemples là-bas des flux de travail qui utilisent la vérification GPG des balises git, donc je ne suis pas sûr si il y a une "meilleure pratique" pour ce genre de chose.

Ce que nous avons jusqu'ici ressemble à ceci:

# 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

Est-ce que ça a du sens? En particulier, afin d'éviter des erreurs changements locaux liés au processus de déploiement, est git reset --hard HEAD la bonne chose à faire? En outre, rappelant FETCH_HEAD semble être être nécessaire, d’autres balises judicieuses postérieurement à HEAD ne se présente pas la sortie de git describe. Y a-t-il une autre façon de faire cela?

Sinon, si vous avez un flux de travail de déploiement documenté qui utilise étiquettes signées pour la vérification, je serais intéressé par un lien vers cela.


5
2017-07-31 04:09


origine




Réponses:


Le titre de la question concerne les balises signées dans un flux de travail de déploiement, mais ce que vous demandez a très peu à voir avec les balises signées. Et en réalité, la seule étape qui serait différente est la vérification des balises, et vous le faites déjà.

git reset --hard HEAD ne supprimera aucun fichier local non suivi, ce qui risquerait de ruiner votre processus de construction. Après git reset --hard vous voudrez peut-être aussi courir git clean -d -x -f.

git fetch peut aller chercher plusieurs branches, ou ne pas aller chercher ce que vous attendez d'elle. Toutes les branches récupérées seraient ajoutées à .git/FETCH_HEAD afin d'éviter toute surprise lors de l'utilisation du FETCH_HEAD ref, je recommanderais d'aller chercher explicitement votre branche de publication. Quelque chose comme git fetch $remote $branch.

Vous demandez s'il y a une "meilleure" façon de faire cela, mais personnellement, je pense que cela suffit. Si votre objectif est d’éviter les extractions inutiles, vous pouvez jouer avec la sortie de git ls-remote mais cela ne vaut vraiment pas la peine.

Personnellement, pour les constructions reproductibles, je commencerais simplement la construction dans un répertoire propre à chaque fois. dir=$(mktemp -d); cd $dir; git init; git remote add ... etc. De cette façon, vous pouvez également déplacer facilement ce script sur une autre machine. Pour accélérer la récupération initiale, vous pouvez indiquer au répertoire temporaire de rechercher des objets git à partir du répertoire local permanent avec echo $permanent_git_directory/.git/objects > .git/objects/info/alternates (man gitrepository-layout pour plus d'informations).


2
2018-01-01 05:54