Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-43308

doGenerateSubmoduleConfigurations causes merge error for non-existent tags

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • git-plugin
    • Jenkins 2.53 git-plugin 3.2

      Upgrading the git plugin to version 3.2 broke our pipeline build that depends on submodules.

      The build complains about not being able to find merge points against old tags.  This appears to be related to the PR for https://issues.jenkins-ci.org/browse/JENKINS-9713

      https://github.com/jenkinsci/git-plugin/pull/340

       

      This appears to be the pertinent part of the logs

      *14:05:51*  > git tag -l # timeout=10
      *14:05:52*  > git rev-parse refs/tags/cookbook-site-imported-sudo-2.7.1^\{commit} # timeout=10
      *14:05:52*  > git rev-parse refs/tags/v0.2.0-posthackerati^\{commit} # timeout=10
      *14:05:52*  > git rev-parse refs/tags/v0.3.0-alpha^\{commit} # timeout=10
      *14:05:52*  > git rev-parse refs/tags/old-product-system^\{commit} # timeout=10
      *14:05:52*  > git rev-parse refs/tags/cookbook-site-imported-td-agent-1daa7273d4921986ecf4efc71340c101493df611^\{commit} # timeout=10
      *14:05:52*  > git rev-parse refs/tags/cookbook-site-imported-users-1.7.0^\{commit} # timeout=10
      *14:05:52*  > git rev-parse refs/tags/v0.2.9-prealpha-talis^\{commit} # timeout=10
      *14:05:52*  > git rev-parse refs/tags/demo-stable-preblink^\{commit} # timeout=10
      *14:05:52*  > git rev-parse refs/tags/v0.3.5-chef-from-scratch-works^\{commit} # timeout=10
      *14:05:52*  > git rev-parse refs/tags/stats-elasticsearch-being-replaced-by-redshift^\{commit} # timeout=10
      [Pipeline] }
      [Pipeline] // stage
      [Pipeline] }
      [Pipeline] // wrap
      [Pipeline] }
      [Pipeline] // timestamps
      [Pipeline] }
      [Pipeline] // node
      [Pipeline] End of Pipeline
      hudson.plugins.git.GitException: Error computing merge base
      	at hudson.plugins.git.util.GitUtils.filterTipBranches(GitUtils.java:213)
      	at
      

          [JENKINS-43308] doGenerateSubmoduleConfigurations causes merge error for non-existent tags

          This bug affected me too. Git Plugin 3.0.5 working perfectly, but 3.2 caused the error:

          Checking out Revision 88d1b774e39237311579eb82843365520a70874f (develop)
           > git config core.sparsecheckout # timeout=10
           > git checkout -f 88d1b774e39237311579eb82843365520a70874f
           > git rev-list 88d1b774e39237311579eb82843365520a70874f # timeout=10
           > git remote # timeout=10
           > git submodule init # timeout=10
           > git submodule sync # timeout=10
           > git config --get remote.origin.url # timeout=10
           > git submodule init # timeout=10
           > git config -f .gitmodules --get-regexp ^submodule\.(.*)\.url # timeout=10
           > git config --get submodule.luna-playbooks.url # timeout=10
           > git remote # timeout=10
           > git config --get remote.origin.url # timeout=10
           > git config -f .gitmodules --get submodule.luna-playbooks.path # timeout=10
          using GIT_ASKPASS to set credentials universal bot account for BB and Stash
           > git submodule update --init --recursive --remote luna-playbooks # timeout=1
           > git ls-tree -r HEAD # timeout=10
          Seen 0 remote branches
           > git tag -l # timeout=10
           > git rev-parse refs/tags/1.0.0^\{commit} # timeout=10
           > git rev-parse refs/tags/1.0.1^\{commit} # timeout=10
           > git rev-parse refs/tags/1.0.2^\{commit} # timeout=10
          [Bitbucket] Notifying commit build result
          [Bitbucket] Build result notified
          hudson.plugins.git.GitException: Error computing merge base
          	at hudson.plugins.git.util.GitUtils.filterTipBranches(GitUtils.java:213)
          	at hudson.plugins.git.SubmoduleCombinator.createSubmoduleCombinations(SubmoduleCombinator.java:42)
          	at hudson.plugins.git.extensions.impl.SubmoduleOption.onCheckoutCompleted(SubmoduleOption.java:118)
          	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1170)
          	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109)
          	at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:130)
          	at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:107)
          	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:232)
          	at hudson.model.ResourceController.execute(ResourceController.java:98)
          	at hudson.model.Executor.run(Executor.java:405)
          Caused by: org.eclipse.jgit.errors.MissingObjectException: Missing unknown 3d8833680d73f91044b0d23dce80f33f8cb81f6c
          	at org.eclipse.jgit.internal.storage.file.WindowCursor.open(WindowCursor.java:158)
          	at org.eclipse.jgit.lib.ObjectReader.open(ObjectReader.java:227)
          	at org.eclipse.jgit.revwalk.RevWalk.parseAny(RevWalk.java:859)
          	at org.eclipse.jgit.revwalk.RevWalk.parseCommit(RevWalk.java:772)
          	at hudson.plugins.git.util.GitUtils$1.invoke(GitUtils.java:184)
          	at hudson.plugins.git.util.GitUtils$1.invoke(GitUtils.java:157)
          	at org.jenkinsci.plugins.gitclient.AbstractGitAPIImpl.withRepository(AbstractGitAPIImpl.java:29)
          	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.withRepository(CliGitAPIImpl.java:65)
          	at hudson.plugins.git.util.GitUtils.filterTipBranches(GitUtils.java:157)
          	... 9 more
          Finished: FAILURE
          

          Anton Markelov added a comment - This bug affected me too. Git Plugin 3.0.5 working perfectly, but 3.2 caused the error: Checking out Revision 88d1b774e39237311579eb82843365520a70874f (develop) > git config core.sparsecheckout # timeout=10 > git checkout -f 88d1b774e39237311579eb82843365520a70874f > git rev-list 88d1b774e39237311579eb82843365520a70874f # timeout=10 > git remote # timeout=10 > git submodule init # timeout=10 > git submodule sync # timeout=10 > git config --get remote.origin.url # timeout=10 > git submodule init # timeout=10 > git config -f .gitmodules --get-regexp ^submodule\.(.*)\.url # timeout=10 > git config --get submodule.luna-playbooks.url # timeout=10 > git remote # timeout=10 > git config --get remote.origin.url # timeout=10 > git config -f .gitmodules --get submodule.luna-playbooks.path # timeout=10 using GIT_ASKPASS to set credentials universal bot account for BB and Stash > git submodule update --init --recursive --remote luna-playbooks # timeout=1 > git ls-tree -r HEAD # timeout=10 Seen 0 remote branches > git tag -l # timeout=10 > git rev-parse refs/tags/1.0.0^\{commit} # timeout=10 > git rev-parse refs/tags/1.0.1^\{commit} # timeout=10 > git rev-parse refs/tags/1.0.2^\{commit} # timeout=10 [Bitbucket] Notifying commit build result [Bitbucket] Build result notified hudson.plugins.git.GitException: Error computing merge base at hudson.plugins.git.util.GitUtils.filterTipBranches(GitUtils.java:213) at hudson.plugins.git.SubmoduleCombinator.createSubmoduleCombinations(SubmoduleCombinator.java:42) at hudson.plugins.git.extensions.impl.SubmoduleOption.onCheckoutCompleted(SubmoduleOption.java:118) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1170) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109) at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:130) at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:107) at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:232) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:405) Caused by: org.eclipse.jgit.errors.MissingObjectException: Missing unknown 3d8833680d73f91044b0d23dce80f33f8cb81f6c at org.eclipse.jgit.internal.storage.file.WindowCursor.open(WindowCursor.java:158) at org.eclipse.jgit.lib.ObjectReader.open(ObjectReader.java:227) at org.eclipse.jgit.revwalk.RevWalk.parseAny(RevWalk.java:859) at org.eclipse.jgit.revwalk.RevWalk.parseCommit(RevWalk.java:772) at hudson.plugins.git.util.GitUtils$1.invoke(GitUtils.java:184) at hudson.plugins.git.util.GitUtils$1.invoke(GitUtils.java:157) at org.jenkinsci.plugins.gitclient.AbstractGitAPIImpl.withRepository(AbstractGitAPIImpl.java:29) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.withRepository(CliGitAPIImpl.java:65) at hudson.plugins.git.util.GitUtils.filterTipBranches(GitUtils.java:157) ... 9 more Finished: FAILURE

          Mark Waite added a comment -

          pbecot01, when I look more closely at your screen shot of your job configuration, it appears that you have the "do not fetch tags" option checked in the advanced clone options. Is that setting critical to your workflow? Does the problem resolve itself if you clone with tags?

          strangeman, have you also disabled fetching tags in your clone? I see from your clone that you're using JGit. The submodule support in the JGit portion of the Jenkins git plugin is incomplete. It does not support submodule authentication, nor does it support several of the more exotic cases (like the Submodule Combinator that is throwing the exception in Paul's case). Does it behave better if you switch from using JGit to using command line git?

          Mark Waite added a comment - pbecot01 , when I look more closely at your screen shot of your job configuration, it appears that you have the "do not fetch tags" option checked in the advanced clone options. Is that setting critical to your workflow? Does the problem resolve itself if you clone with tags? strangeman , have you also disabled fetching tags in your clone? I see from your clone that you're using JGit. The submodule support in the JGit portion of the Jenkins git plugin is incomplete. It does not support submodule authentication, nor does it support several of the more exotic cases (like the Submodule Combinator that is throwing the exception in Paul's case). Does it behave better if you switch from using JGit to using command line git?

          Paul Becotte added a comment -

          We added the "do not fetch tags" setting to try and fix this (seemed like a logical fix, if its fetching tags that don't exist, just disable fetching the tags?) - however, the problem persisted.

          Paul Becotte added a comment - We added the "do not fetch tags" setting to try and fix this (seemed like a logical fix, if its fetching tags that don't exist, just disable fetching the tags?) - however, the problem persisted.

          Mark Waite added a comment -

          The stack trace has an odd mix of jgit and command line git calls. It appears that the command line git method "withRepository" is using a call to GitUtils which then invokes jgit. Since the jgit libraries are always available, it should work, but it is surprising to have jgit called from command line git. Not infeasible, and not inexplicable, but surprising.

          I assume that you are using command line git, not JGit as your git implementation. Can you confirm that?

          Is the commit mentioned in the stack trace (3d8833680d73f91044b0d23dce80f33f8cb81f6c) actually available in other copies of your repository?

          Mark Waite added a comment - The stack trace has an odd mix of jgit and command line git calls. It appears that the command line git method "withRepository" is using a call to GitUtils which then invokes jgit. Since the jgit libraries are always available, it should work, but it is surprising to have jgit called from command line git. Not infeasible, and not inexplicable, but surprising. I assume that you are using command line git, not JGit as your git implementation. Can you confirm that? Is the commit mentioned in the stack trace (3d8833680d73f91044b0d23dce80f33f8cb81f6c) actually available in other copies of your repository?

          Paul Becotte added a comment -

          We re-updated to the latest version (lots of cascading dependencies) of the git plugin, which brought this back.  I decided to try and resolve it instead of backing everything out.

          Eventually, from many readings of the git plugin and logs, we figured out that

          `doGenerateSubmoduleConfigurations: true,` is what was causing the merge- it was trying to create build combinations for every set of tags (including non-existent tags).  Setting that to false resolved our issue (not sure why it was set true in the first place).

          Paul Becotte added a comment - We re-updated to the latest version (lots of cascading dependencies) of the git plugin, which brought this back.  I decided to try and resolve it instead of backing everything out. Eventually, from many readings of the git plugin and logs, we figured out that `doGenerateSubmoduleConfigurations: true,` is what was causing the merge- it was trying to create build combinations for every set of tags (including non-existent tags).  Setting that to false resolved our issue (not sure why it was set true in the first place).

          Jean Mertz added a comment -

          Setting `doGenerateSubmoduleConfigurations` to `false` was the solution for us as well.

          Jean Mertz added a comment - Setting `doGenerateSubmoduleConfigurations` to `false` was the solution for us as well.

          Oskari Petas added a comment -

          Hi,

          That fixed our issue as well.

          However I think the documentation around this is non-existent. What does that flag even do? Could someone who knows about this add some docs? Maybe markewaite

          Oskari Petas added a comment - Hi, That fixed our issue as well. However I think the documentation around this is non-existent. What does that flag even do? Could someone who knows about this add some docs? Maybe markewaite

          Mark Waite added a comment -

          aop I consider the "autogenerate submodule configurations" behavior to be deprecated. The default setting is "false", which does no harm to users. When somieone sets it to true, I assume that was a conscious choice. I haven't taken the effort to remove it from the plugin because I'd rather spend time reviewing useful pull requests, rather than removing outdated use cases.

          I'm not sure there is a way to do a clean removal of that feature from the plugin. Removing features tends to be a compatibility challenge.

          There are no automated tests to check its behavior, and I have no interactive tests which check its behavior. It remains in the plugin on the assumption that if there are users who value it, they will report if it is ever broken.

          It is documented in the git plugin wiki page. It has become more visible through the benefit of the pipeline syntax generator. The pipeline syntax generator is a very, very helpful part of pipeline development. Unfortunately (in this case) it also exposes some old, rough portions of the git plugin.

          Mark Waite added a comment - aop I consider the "autogenerate submodule configurations" behavior to be deprecated. The default setting is "false", which does no harm to users. When somieone sets it to true, I assume that was a conscious choice. I haven't taken the effort to remove it from the plugin because I'd rather spend time reviewing useful pull requests, rather than removing outdated use cases. I'm not sure there is a way to do a clean removal of that feature from the plugin. Removing features tends to be a compatibility challenge. There are no automated tests to check its behavior, and I have no interactive tests which check its behavior. It remains in the plugin on the assumption that if there are users who value it, they will report if it is ever broken. It is documented in the git plugin wiki page . It has become more visible through the benefit of the pipeline syntax generator. The pipeline syntax generator is a very, very helpful part of pipeline development. Unfortunately (in this case) it also exposes some old, rough portions of the git plugin.

          Mark Waite added a comment -

          Documented in the git plugin wiki

          Mark Waite added a comment - Documented in the git plugin wiki

          Mark Waite added a comment -

          doGenerateSubmoduleConfigurations was removed from git plugin 4.6.0 in July 2020. Argument may be used, but its value is ignored.

          Mark Waite added a comment - doGenerateSubmoduleConfigurations was removed from git plugin 4.6.0 in July 2020. Argument may be used, but its value is ignored.

            Unassigned Unassigned
            pbecot01 Paul Becotte
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: