Sorry to hear that it broke your build. Can you provide a job definition or the necessary steps which show the problem to someone who doesn't have access to your Jenkins server?

Could you expand your description of the use case so that I can better understand it? You say that you depend on submodules, and that it is not able to find merge points against old tags. Are those tags inside the submodule repository, or are they in the repository which references the submodules?

Does your job definition include any settings which would prevent fetching of tags from the remote repository?

The use case is that we have a master repo called `system` which we use to run a full system integration test.  It has each of our project repos as a submodule, and whenever a PR runs against any of our projects it kicks off a build of the system repo.

The system repo runs with a Jenkinsfile.  It is the 'checkout' command that is failing-

checkout([
$class: 'GitSCM',
branches: scm.branches,
doGenerateSubmoduleConfigurations: true,
extensions: scm.extensions + [[
$class: 'SubmoduleOption',
recursiveSubmodules: true,
parentCredentials: true,
trackingSubmodules: true
]],
userRemoteConfigs: scm.userRemoteConfigs
])

The tags in question are from the submodules.  The tags listed in the error message from the ticket are from several years ago in our `backend` repository.  Deleting the tags got the build to move to the next submodule.  (it still failed, that one also had tags and we were actually using those tags!).  I don't really understand what is going on with the git command here to answer more intelligently, but would be happy to answer any questions you may have. 

Final note, reverting back to git-plugin 3.1.0 resolved the issue for us.

What settings are configured that are causing a merge? As far as I know, the default settings for a job perform no merge, and you have no extensions in that job definition which would cause a merge.

Sorry, I tried to answer this more quickly but JIRA was down when I tried!

That is an excellent question.  So far as I am aware, we haven't configured any settings that would cause that!  I attached a screenshot of the scm config for that pipeline job.  Not sure where else something like that may be hiding!

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?

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.

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?

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).

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

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

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.

Documented in the git plugin wiki

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