Мы хотели бы, чтобы процесс развертывания происходил непосредственно из нашего репозитория git, но активировал новые изменения только в том случае, если они подписаны (через git
tag -s) с подписью GPG. Я нашел очень мало примеров рабочих процессов, в которых используется проверка тегов git GPG, поэтому я не уверен, есть ли «лучшая практика» для такого рода вещей.
То, что у нас есть, выглядит так:
# 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
Имеет ли это смысл? В частности, чтобы избежать ошибочных локальных изменений в процессе развертывания, git reset --hard
HEAD что делать? Кроме того, вспоминая FETCH_HEAD кажется необходимым, другие мудрые теги после HEAD не отображаются в выводе git describe. Есть другой способ сделать это?
В качестве альтернативы, если у вас есть документированный рабочий процесс развертывания, в котором для проверки используются подписанные теги, мне будет интересна ссылка на это.
Заголовок вопроса касается подписанных тегов в рабочем процессе развертывания, но то, что вы спрашиваете, имеет очень мало общего с подписанными тегами. И на самом деле единственный шаг, который будет отличаться, - это проверка тегов, и вы уже это делаете.
git reset --hard HEAD не будет удалять неотслеживаемые локальные файлы, которые вполне могут испортить ваш процесс сборки. После git reset --hard Вы можете также захотеть запустить git clean -d -x -f.
git fetch может получить несколько ветвей или не получить то, что вы ожидаете получить. Все выбранные ветки будут добавлены в .git/FETCH_HEAD чтобы избежать сюрпризов при использовании FETCH_HEAD ref, я бы рекомендовал явно получить вашу ветку выпуска. Что-то вроде git fetch $remote $branch.
Вы спрашиваете, есть ли «лучший» способ сделать это, но лично я думаю, что этого достаточно. Если ваша цель - избежать ненужной выборки, вы можете поиграть с выводом git ls-remote но это действительно не стоит усилий.
Лично для воспроизводимых сборок я бы просто каждый раз запускал сборку в чистом каталоге. dir=$(mktemp -d); cd $dir; git init; git remote add ... и так далее. Таким образом, вы также можете легко перенести этот скрипт на другой компьютер. Чтобы ускорить начальную выборку, вы можете указать временному каталогу найти объекты git из постоянного локального каталога с echo $permanent_git_directory/.git/objects > .git/objects/info/alternates (man gitrepository-layout для получения дополнительной информации).