获取提交次数的错误值
def generateVersion() {
def commitCount = sh(script: "git rev-list --count HEAD", returnStdout: true).trim() as Integer
echo "this is commitcount------------->>>>>>>>>>>>>>>> ${commitCount}";
def metadata = readJSON file: 'package.json'
def (major, minor) = metadata.version.tokenize('.')
def patch = commitCount
def prerelease = env.BRANCH_NAME == 'master' ? '' : "-${env.BRANCH_NAME}"
return "${major}.${minor}.${patch}${prerelease}"
}
这是我在 Jenkinsfile 中编写的常规代码。它应该返回给我一个独特的构建版本。该函数在发布库阶段被调用。
....
stage('Publish Libraries') {
dir('External') {
libVersion = generateVersion()
...
...
我无法获得正确的 commitCount 值,因此无法获得错误的 patch 值。无论我在分支中进行多少次提交,它都保持一致的值 5。我已经从另一个最初有 56 次提交的功能分支创建了一个分支。因此,当我创建一个分支时,它最初有 56 次提交。我在新创建的分支中添加了 11 个提交,因此该分支中总共有 67 个提交,但它显示的计数只有 5 个。我该怎么办?
我什至尝试过:
def commitCount = sh(script: "git rev-list --count ${env.BRANCH_NAME}", returnStdout: true).trim() as Integer
认为也许我的 HEAD 在我不知情的情况下被设置到了其他分支。但 commitCount 仍然是 5。
def generateVersion() {
def commitCount = sh(script: "git rev-list --count HEAD", returnStdout: true).trim() as Integer
echo "this is commitcount------------->>>>>>>>>>>>>>>> ${commitCount}";
def metadata = readJSON file: 'package.json'
def (major, minor) = metadata.version.tokenize('.')
def patch = commitCount
def prerelease = env.BRANCH_NAME == 'master' ? '' : "-${env.BRANCH_NAME}"
return "${major}.${minor}.${patch}${prerelease}"
}
This is a groovy code that I have written in my Jenkinsfile. It is supposed to return me a unique version of the build. This function gets called in a stage Publish Libraries.
....
stage('Publish Libraries') {
dir('External') {
libVersion = generateVersion()
...
...
I am not able to get the correct value of commitCount and therefore wrong value of patch. It stays consistent at value 5 no matter how many commits I make in my branch. I have created a branch off of another feature branch that initally had 56 commits. So when i created a branch it initally had those 56 commits. I added 11 commits of my own in the newly created branch so a total of 67 commits are there in the branch but it shows the count as only 5. What should I do?
I even tried:
def commitCount = sh(script: "git rev-list --count ${env.BRANCH_NAME}", returnStdout: true).trim() as Integer
thinking that maybe my HEAD gets set to some other branch without my knowledge. But still commitCount is 5.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
几乎可以肯定,您正在使用带有
--depth=5
(以及相应隐含的--single-branch
)的浅克隆。在这种情况下,git rev-list HEAD
计数的修订永远不会超过 5。要解决此问题,请告诉 Jenkins 使用非浅层克隆(请参阅 没有使用 SCM 历史记录的 git 克隆)。请注意,即使您进行了完整(非浅)克隆,
--count
也不是获取唯一修订说明符的可靠方法。原因很简单:从某个分支提示可到达的提交数量不一定会增加(例如,git reset
从分支提示中删除提交),并且例如,从feature/a
和feature/b
可以访问的提交可能是相同的:这里,假设从
main< 开始找到的修订计数/code> 向后计算是 200。每个功能分支上有两个不在
main
上的提交,以及 在main
上的 200 个提交。 ,因此两个分支上的计数将为 202。但是feature/a
上的提交与feature/b
上的提交不同。如果您想要为提交提供一个唯一的描述性名称,并且至少比原始哈希 ID 稍微好一点,请考虑使用
git describe
(可能与--always
和/或 <代码>--脏)。为了使其正常工作,请务必使用标签(最好是用于发布的带注释的标签),并且可能添加--tags
选项。You're almost certainly using a shallow clone with
--depth=5
(and the corresponding implied--single-branch
). In this case, the revisions counted bygit rev-list HEAD
will never exceed five. To fix the problem, tell Jenkins to use a non-shallow clone (see git clone without history using SCM).Note that
--count
is not a reliable way to get a unique revision specifier even if you make a full (non-shallow) clone. The reason is simple enough: the number of commits reachable from some branch tip does not necessarily increase (e.g.,git reset
removes commits from the branch tip), and the number of commits reachable from, e.g.,feature/a
and fromfeature/b
may be the same:Here, let's say that the revision count found by starting from
main
and working backwards is 200. There are two commits on each feature branch that are not onmain
, plus the 200 commits that are onmain
, so the count on both branches will be 202. Yet the commits onfeature/a
differ from the commits onfeature/b
.If you want a unique descriptive name for a commit that's at least marginally less ugly than a raw hash ID, consider using
git describe
(perhaps with--always
and/or--dirty
). To make it work well, be sure to use tags (preferably annotated tags for releases) and maybe add the--tags
option.