GPG在部署脚本中验证git标记

概述我们希望我们的部署过程直接从我们的git中提取 存储库,但只有在签名时才激活新的更改(通过git tag -s)带有GPG签名.我发现很少有例子 使用GPG验证git标签的工作流程,所以我不确定是否 对于这种事情,这是一种“最佳实践”. 到目前为止我们看到的是这样的： # discard erroneous local changesgit reset --hard HEAD# get ch 我们希望我们的部署过程直接从我们的git中提取
存储库,但只有在签名时才激活新的更改(通过git
tag -s)带有GPG签名.我发现很少有例子
使用GPG验证git标签的工作流程,所以我不确定是否
对于这种事情,这是一种“最佳实践”.

到目前为止我们看到的是这样的：

# discard erroneous local changesgit reset --hard head# get changesgit fetchstart=$(git rev-parse FETCH_head)# get new Tagsgit fetch --Tags# find most recent release tagtag=$(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的输出描述.还有另一种方法吗？

或者,如果您有使用的文档化部署工作流
已签名的标签用于验证我会对此链接感兴趣.

解决方法 问题的标题是关于部署工作流程中的签名标记,但您要求的内容与签名标记几乎没有关系.实际上,唯一不同的步骤就是验证标签,你已经在做了.

git reset –hard head不会清除任何未跟踪的本地文件,这可能会破坏你的构建过程.在git reset –hard之后你可能还想运行git clean -d -x -f.

git fetch可能会获取多个分支,或者它可能无法获取您希望它获取的内容.所有获取的分支都将添加到.git / FETCH_head中,以避免在使用FETCH_head引用时出现任何意外,我建议明确地获取发布分支.像git fetch $remote $branch这样的东西.

你在问这种方法是否有“更好”的方法,但我个人认为这已经足够了.如果你的目标是避免不必要的提取,那么你可以使用git ls-remote的输出,但它确实不值得努力.

就个人而言,对于可重现的构建,我只是每次都在一个干净的目录中启动构建. dir = $(mktemp -d); cd $dir; git init; git remote add …等等.这样,您还可以轻松地将此脚本移动到其他计算机.为了加速初始提取,您可以通过echo $permanent_git_directory / .git / objects>告诉临时目录从永久本地目录中查找git对象. .git / objects / info / alternates(man gitrepository-layout获取更多信息).

总结

以上是内存溢出为你收集整理的GPG在部署脚本中验证git标记全部内容，希望文章能够帮你解决GPG在部署脚本中验证git标记所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。