获取提交次数的错误值

发布于 2025-01-20 10:35:27 字数 1142 浏览 3 评论 0原文

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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

旧话新听 2025-01-27 10:35:27

几乎可以肯定,您正在使用带有 --depth=5(以及相应隐含的 --single-branch)的浅克隆。在这种情况下,git rev-list HEAD 计数的修订永远不会超过 5。要解决此问题,请告诉 Jenkins 使用非浅层克隆(请参阅 没有使用 SCM 历史记录的 git 克隆)。

请注意,即使您进行了完整(非浅)克隆,--count 也不是获取唯一修订说明符的可靠方法。原因很简单:从某个分支提示可到达的提交数量不一定会增加(例如,git reset从分支提示中删除提交),并且例如,从 feature/afeature/b 可以访问的提交可能是相同的:

          o--o   <-- feature/1
         /
...--o--o   <-- main
         \
          o--o   <-- 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 by git 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 from feature/b may be the same:

          o--o   <-- feature/1
         /
...--o--o   <-- main
         \
          o--o   <-- feature/b

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 on main, plus the 200 commits that are on main, so the count on both branches will be 202. Yet the commits on feature/a differ from the commits on feature/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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文