当使用git checkout -f <hash>
检出存储库时,是否可以找到git标记信息?
我知道git describe --tags --abbrev=0
显示git标签号,但是在我的Jenkinsfile中,结帐是由git checkout -f <hash>
完成的。因此,我的jenkinsfile的git describe
的输出仅显示提交编号,但不显示标签名称。是否可以获取标签名称?我尝试了env.TAG_NAME
,它是空的。
答案 0 :(得分:2)
TL; DR:首先,查看升级Jenkins是否可行。如果没有,请尝试git tag --points-at HEAD
。
有两种方法可以解决这个问题。
一个人假设您正在尝试“向后移动”,即采用一个发现处于分离HEAD
模式的存储库,然后猜测它是如何到达那里的。第一个问题是它可能根本没有通过git checkout <tag-name>
到达那里。第二个原因是,即使这样做(在这种情况下,git describe --tags --abbrev=0
也会显示一个),而git describe
显示的那个可能并不是实际用于完成结帐的那个。
这样做的原因是,Git的标签主要是将人类可读的名称转换为哈希ID的机制。任何给定的提交哈希ID可能会有多个名称,如果是这样,git describe
只会选择一个并使用它。在Git versions 1.7.10 and later中,git tag --points-at HEAD
将列出指向当前提交的 all 标签;然后,您可以尝试猜测使用了其中哪些。
或者,您可以使用存储库的HEAD
reflog,如果使用了标记,则其中将有一行包含标记名称的行。在现代Git中,git status
命令执行此操作,并在这种情况下打印HEAD detached at tag-name
。这比git describe
输出更可靠,提供了相关的存储库已启用reflog,并且存在reflog条目。都不保证启用了reflog,如果启用了这两个选项,则没有合适的条目。因此,describe和point-at方法更加可靠。
查看此问题的另一种方式是假设您希望“前进”:Jenkins本身已经完成了git checkout
操作。在这种情况下,您要做的就是说服Jenkins为您生成传递给git checkout
的标签名称。
应该 是执行此操作的一种方法。确实,应该是您已经尝试过的方法,即使用env.TAG_NAME
。显然,这是claimed to work now。也许升级詹金斯会成功。
我很高兴能纠正有关Jenkins文档浪费大量时间的说法,因为找到了一些完整,全面和准确的文档,其中包括Jenkins支持的版本哪些功能,哪些管道阶段并行运行以及什么不是并行管道等等,但我从未发现过。 (Git至少要好一个 ,因为它可以搜索release notes来确定何时添加了特定功能,但是在这里,情况也可能会好得多。 Python文档,该文档尝试在特定功能(例如pathlib)是新增功能时进行标注。)