[JIRA] (JENKINS-53004) checkout fails due to issue with JGit 5.0.2 (in 3.0.0.beta-5)

33 views
Skip to first unread message

sa_git@strukton.com (JIRA)

unread,
Aug 13, 2018, 3:15:02 AM8/13/18
to jenkinsc...@googlegroups.com
sa_git Strukton created an issue
 
Jenkins / Bug JENKINS-53004
checkout fails due to issue with JGit 5.0.2 (in 3.0.0.beta-5)
Issue Type: Bug Bug
Assignee: Mark Waite
Components: git-client-plugin
Created: 2018-08-13 07:14
Environment: 3.0.0.beta-5
Priority: Minor Minor
Reporter: sa_git Strukton

when running checkout scm I get the error:

java.lang.NoSuchMethodError: org.eclipse.jgit.lib.Repository.getRef(Ljava/lang/String;)Lorg/eclipse/jgit/lib/Ref;
at jenkins.plugins.git.GitSCMFileSystem$1.invoke(GitSCMFileSystem.java:117)
at jenkins.plugins.git.GitSCMFileSystem$1.invoke(GitSCMFileSystem.java:114)
at jenkins.plugins.git.GitSCMFileSystem$3.invoke(GitSCMFileSystem.java:193)
at org.jenkinsci.plugins.gitclient.AbstractGitAPIImpl.withRepository(AbstractGitAPIImpl.java:28)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.withRepository(CliGitAPIImpl.java:75)
at jenkins.plugins.git.GitSCMFileSystem.invoke(GitSCMFileSystem.java:189)
at jenkins.plugins.git.GitSCMFileSystem.<init>(GitSCMFileSystem.java:114)
at jenkins.plugins.git.GitSCMFileSystem$BuilderImpl.build(GitSCMFileSystem.java:353)
at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:196)
at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:172)
at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:108)
at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:67)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:303)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Finished: FAILURE

 

I suspect this is related to introducting JGit5.02 in 3.0.0.beta-5 When I step back to 2.7.3 it all works fine.

 

I'd like to use the  new beta because shallow clone of submodules is supported.
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 13, 2018, 10:10:03 AM8/13/18
to jenkinsc...@googlegroups.com
Mark Waite commented on Bug JENKINS-53004
 
Re: checkout fails due to issue with JGit 5.0.2 (in 3.0.0.beta-5)

A new beta release of the git plugin is needed, both to resolve that NoSuchMethodError and to provide shallow submodule update support in the git plugin. The current git plugin beta does not include shallow submodule update support and still contains a reference to a symbol that JGit 4.x deprecated and JGit 5.x removed.

You'll need to use the plugin pull request build that incorporates shallow submodule support. When you've evaluated that build, please describe your results on the pull request.

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 13, 2018, 10:10:04 AM8/13/18
to jenkinsc...@googlegroups.com
Mark Waite assigned an issue to Unassigned
 
Change By: Mark Waite
Assignee: Mark Waite

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 13, 2018, 10:11:02 AM8/13/18
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-53004
A new beta release of the git plugin is needed, both to resolve that NoSuchMethodError and to provide shallow submodule update support in the git plugin.  The current git plugin beta does not include shallow submodule update support and still contains a reference to a symbol that JGit 4.x deprecated and JGit 5.x removed.

You'll need to use git client plugin 3.0.0-beta5 and the [ git plugin pull request build|https://github.com/jenkinsci/git-plugin/pull/610] that incorporates shallow submodule support.  When you've evaluated that build, please describe your results on the [pull request|https://github.com/jenkinsci/git-plugin/pull/610].

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 13, 2018, 10:12:02 AM8/13/18
to jenkinsc...@googlegroups.com
Mark Waite updated an issue
 
Change By: Mark Waite
when running checkout scm I get the error:
{noformat}
java.lang.NoSuchMethodError: org.eclipse.jgit.lib.Repository.getRef(Ljava/lang/String;)Lorg/eclipse/jgit/lib/Ref;
at jenkins.plugins.git.GitSCMFileSystem$1.invoke(GitSCMFileSystem.java:117)
at jenkins.plugins.git.GitSCMFileSystem$1.invoke(GitSCMFileSystem.java:114)
at jenkins.plugins.git.GitSCMFileSystem$3.invoke(GitSCMFileSystem.java:193)
at org.jenkinsci.plugins.gitclient.AbstractGitAPIImpl.withRepository(AbstractGitAPIImpl.java:28)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.withRepository(CliGitAPIImpl.java:75)
at jenkins.plugins.git.GitSCMFileSystem.invoke(GitSCMFileSystem.java:189)
at jenkins.plugins.git.GitSCMFileSystem.<init>(GitSCMFileSystem.java:114)
at jenkins.plugins.git.GitSCMFileSystem$BuilderImpl.build(GitSCMFileSystem.java:353)
at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:196)
at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:172)
at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:108)
at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:67)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:303)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Finished: FAILURE
{noformat}
 

I suspect this is related to introducting introducing JGit5.02 in 3.0.0.beta-5 When I step back to 2.7.3 it all works fine.

 

 I'd like to use the  new beta because shallow clone of submodules is supported.

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 13, 2018, 10:21:02 AM8/13/18
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-53004
A new beta release of the git plugin is needed, both to resolve that NoSuchMethodError and to provide shallow submodule update support in the git plugin.  The current git plugin beta does not include shallow submodule update support and still contains a reference to a symbol that JGit 4.x deprecated and JGit 5.x removed.

You'll need to use git client plugin 3.0.0-beta5 and the [git plugin pull request build|https://github.com/jenkinsci/git-plugin/pull/610] that incorporates shallow submodule support.  When you've evaluated that build, please describe your results on the [pull request|https://github.com/jenkinsci/git-plugin/pull/610].   That will be one more step to speed the merge of that pull request into the git plugin.

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 13, 2018, 10:22:01 AM8/13/18
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-53004
A new beta release of the git plugin is needed, both to resolve that NoSuchMethodError and to provide shallow submodule update support in the git plugin.  The current git plugin beta does not include shallow submodule update support and still contains a reference to a symbol that JGit 4.x deprecated and JGit 5.x removed.

You 'll need to can use git client plugin 3.0.0-beta5 and the [git plugin pull request build|https://github.com/jenkinsci/git-plugin/pull/610] that incorporates now to evaluate shallow submodule support clone of submodules .  When you've evaluated that build, please describe your results on the [pull request|https://github.com/jenkinsci/git-plugin/pull/610].  That will be one more step to speed the merge of that pull request into the git plugin.

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 26, 2018, 5:48:02 PM12/26/18
to jenkinsc...@googlegroups.com
Mark Waite updated Bug JENKINS-53004
 

git client plugin 3.0.0-beta6 and git plugin 4.0.0-beta4 resolve this problem. Released Dec 15, 2018
Change By: Mark Waite
Status: Open Fixed but Unreleased
Resolution: Fixed
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 26, 2018, 5:48:02 PM12/26/18
to jenkinsc...@googlegroups.com
Mark Waite closed an issue as Fixed
Change By: Mark Waite
Status: Resolved Closed

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 26, 2018, 5:48:02 PM12/26/18
to jenkinsc...@googlegroups.com
Change By: Mark Waite
Status: Fixed but Unreleased Resolved

johannes@perceivon.net (JIRA)

unread,
Feb 5, 2019, 3:06:02 AM2/5/19
to jenkinsc...@googlegroups.com
Johannes Meixner commented on Bug JENKINS-53004
 
Re: checkout fails due to issue with JGit 5.0.2 (in 3.0.0.beta-5)

Please note that with Jenkins 2.150.2, git client 3.0.0-rc and git 4.0.0-rc, this is still a problem.

 

Downgrading to git client 2.7.2 and git 3.9.0 fixed issues.

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 5, 2019, 7:46:02 AM2/5/19
to jenkinsc...@googlegroups.com

Johannes Meixner please provide more details why you believe this is still a problem with git client plugin 3.0.0-rc and git plugin 4.0.0-rc. After you installed those two new versions of the plugin, did you restart your Jenkins server? They are working for me and for other users as well.

johannes@perceivon.net (JIRA)

unread,
Feb 6, 2019, 6:13:02 AM2/6/19
to jenkinsc...@googlegroups.com

What I did was

  • Upgraded Jenkins from 2.138.3 to 2.150.2
  • Upgraded git client to 3.0.0-rc
  • Upgraded git plugin to 4.0.0-rc
  • Restarted Jenkins
  • Restarted Jenkins nodes
  • Nodes wouldn't be able to run most jobs

I then downgraded to 2.138.3 again, to see if it was the Jenkins version update gone wrong ... it wasn't.

Then did some back and forth (including multiple restarts) until I noticed this issue on Google.

hamza.boulaares@gmail.com (JIRA)

unread,
Feb 6, 2019, 11:35:02 AM2/6/19
to jenkinsc...@googlegroups.com

I am having the same issue as Johannes Meixner. I am running Jenkins 2.150.2  and today I upgraded:

  • Git client to 3.0.0-rc
  • Git plugin to 4.0.0-rc

I had the following behavior:

  • Bitbucket Build Status Notifier Plugin no longer updating branches with build status. This plugin depends on Git plugin and after downgrading Git plugin to 3.9.1, build status started showing on branches again
  • Some builds started failing with the following error. Downgrading Git client plugin to 2.7.6 fixed the issue

java.lang.NoSuchMethodError: org.eclipse.jgit.lib.Repository.getRef(Ljava/lang/String;)Lorg/eclipse/jgit/lib/Ref;
at jenkins.plugins.git.GitSCMFileSystem$1.invoke(GitSCMFileSystem.java:117)
at jenkins.plugins.git.GitSCMFileSystem$1.invoke(GitSCMFileSystem.java:114)
at jenkins.plugins.git.GitSCMFileSystem$3.invoke(GitSCMFileSystem.java:193)

at org.jenkinsci.plugins.gitclient.AbstractGitAPIImpl.withRepository(AbstractGitAPIImpl.java:29)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.withRepository(CliGitAPIImpl.java:81)


at jenkins.plugins.git.GitSCMFileSystem.invoke(GitSCMFileSystem.java:189)
at jenkins.plugins.git.GitSCMFileSystem.<init>(GitSCMFileSystem.java:114)
at jenkins.plugins.git.GitSCMFileSystem$BuilderImpl.build(GitSCMFileSystem.java:353)

at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:198)
at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:174)


at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:108)
at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:67)

at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:293)


at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Finished: FAILURE

hamza.boulaares@gmail.com (JIRA)

unread,
Feb 6, 2019, 11:36:02 AM2/6/19
to jenkinsc...@googlegroups.com
Hamza Boulaares edited a comment on Bug JENKINS-53004
I am having the same issue as [~xmj]. I am running Jenkins [2.150.2|https://jenkins.io/]  and today I upgraded:
* Git client to 3.0.0-rc
* Git plugin to 4.0.0-rc


I had the following behavior:
* Bitbucket Build Status Notifier Plugin no longer updating branches with build status. This plugin depends on Git plugin and after downgrading Git plugin to 3.9.1, build status started showing on branches again
* Some builds started failing with the following error. Downgrading Git client plugin to 2.7.6 fixed the issue

 {noformat}

java.lang.NoSuchMethodError: org.eclipse.jgit.lib.Repository.getRef(Ljava/lang/String;)Lorg/eclipse/jgit/lib/Ref;
at jenkins.plugins.git.GitSCMFileSystem$1.invoke(GitSCMFileSystem.java:117)
at jenkins.plugins.git.GitSCMFileSystem$1.invoke(GitSCMFileSystem.java:114)
at jenkins.plugins.git.GitSCMFileSystem$3.invoke(GitSCMFileSystem.java:193)
at org.jenkinsci.plugins.gitclient.AbstractGitAPIImpl.withRepository(AbstractGitAPIImpl.java:29)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.withRepository(CliGitAPIImpl.java:81)
at jenkins.plugins.git.GitSCMFileSystem.invoke(GitSCMFileSystem.java:189)
at jenkins.plugins.git.GitSCMFileSystem.<init>(GitSCMFileSystem.java:114)
at jenkins.plugins.git.GitSCMFileSystem$BuilderImpl.build(GitSCMFileSystem.java:353)
at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:198)
at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:174)
at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:108)
at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:67)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:293)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Finished: FAILURE


{noformat}

david.rutherford.dev@gmail.com (JIRA)

unread,
Feb 7, 2019, 11:43:02 AM2/7/19
to jenkinsc...@googlegroups.com

I'm getting the same issue using the Artifactory plugin.  Upgraded Jenkins to latest LTS (2.150.2) & updated all my out of date plugins and all of a sudden the rtGradleRun pipeline task just hangs eternally with no logs in job console or Jenkins logs indicating anything wrong.  Downloaded & debugged the artifactory plugin source & managed to uncover this same NoMethodFoundError. 

This ticket is marked fixed but I see no commits in the Git-client-plugins github repo that reference it and the 3.0.0-rc version of the plugin was published to https://plugins.jenkins.io/git-client on Jan 30.  Rolling back the Git & Git-client plugins to the non-rc versions fixed the issue.

Is there a timeline for when we can expect the fix to actually get built & pushed to the https://plugins.jenkins.io?

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 7, 2019, 2:56:02 PM2/7/19
to jenkinsc...@googlegroups.com

David Rutherford, the problem you're seeing is a problem in the artifactory plugin, not a problem in the git client plugin.

The artifactory plugin depends on JGit version 3. Git client plugin 2.x delivered JGit version 4 which was largely compatible with JGit version 3 but deprecates some API's that were part of JGit 3. Git client plugin 3.x will deliver JGit 5 which removes at least one of the deprecated APIs.

The artifactory plugin developers have created a pre-release of their plugin that uses the JGit 4 and JGit 5 API instead of the JGit 3 API.

Your best near term solution is to downgrade to git client plugin 2.7.x. The git client plugin 3.0.0-rc and git plugin 4.0.0-rc were intended to be release candidate builds for further testing in the experimental update center. They were not intended to be production releases for general availability. I made a serious mistake when I chose the "-rc" suffix for the release.

The update center will soon hide the git client plugin 3.0.0-rc and git plugin 4.0.0-rc release

david.rutherford.dev@gmail.com (JIRA)

unread,
Feb 7, 2019, 3:12:02 PM2/7/19
to jenkinsc...@googlegroups.com

My apologies Mark Waite, I naturally should have thought about the problem from the "opposite direction".  I made the mistake of updating my test Jenkins instance plugins wholesale without taking a backup of the plugins dir first and went into panic-mode once my pipeline job started hanging without any sort of logs indicating errors.  Then I managed to crater my entire install & had to restart from a completely clean install making it even harder to figure out where the problem plugin was.  I was certain the issue was somewhere in the recently updated Pipeline: step api plugins until I encountered this error in the debugger.  On the plus side, this was just a test instance running on my local machine & it forced me to learn how to debug Jenkins plugins but I was definitely pulling my hair out for a bit there. 

ogondza@gmail.com (JIRA)

unread,
Mar 24, 2020, 9:53:04 AM3/24/20
to jenkinsc...@googlegroups.com

Mark Waite, we have a customer running into this with git-client 3.0.0 and git-plugin 3.12.0. The way I understand your analysis here is, an older jgit is leaking from some other plugin so git-(client-)plugin built against jgit5 is invoking signatures that was not present in the older version that is leaking in - so the fix is to get all those plugins to versions using more or less same (major) version of jgit. I tend to agree this might be the case have, as my Jenkins has loaded 2 older versions of jgit:

$ ls -l /proc/9972/fd/ | grep jgit
lr-x------. 1 jenkins jenkins 64 Mar 24 13:30 333 -> /var/lib/jenkins/plugins/git-client/WEB-INF/lib/org.eclipse.jgit.lfs-5.5.1.201910021850-r.jar
lr-x------. 1 jenkins jenkins 64 Mar 24 13:30 334 -> /var/lib/jenkins/plugins/git-client/WEB-INF/lib/org.eclipse.jgit.http.apache-5.5.1.201910021850-r.jar
lr-x------. 1 jenkins jenkins 64 Mar 24 13:30 337 -> /var/lib/jenkins/plugins/git-client/WEB-INF/lib/org.eclipse.jgit.http.server-5.5.1.201910021850-r.jar
lr-x------. 1 jenkins jenkins 64 Mar 24 13:30 338 -> /var/lib/jenkins/plugins/git-client/WEB-INF/lib/org.eclipse.jgit-5.5.1.201910021850-r.jar
lr-x------. 1 jenkins jenkins 64 Mar 24 13:30 548 -> /var/lib/jenkins/plugins/blueocean-events/WEB-INF/lib/org.eclipse.jgit-4.5.4.201711221230-r.jar
lr-x------. 1 jenkins jenkins 64 Mar 24 13:30 549 -> /var/lib/jenkins/plugins/blueocean-events/WEB-INF/lib/org.eclipse.jgit.http.server-4.5.4.201711221230-r.jar
lr-x------. 1 jenkins jenkins 64 Mar 24 13:30 553 -> /var/lib/jenkins/plugins/blueocean-events/WEB-INF/lib/org.eclipse.jgit.http.apache-4.5.4.201711221230-r.jar
lr-x------. 1 jenkins jenkins 64 Mar 24 13:30 764 -> /var/lib/jenkins/plugins/gitlab-plugin/WEB-INF/lib/org.eclipse.jgit-3.5.2.201411120430-r.jar

However, I was under assumption that Jenkins hierarchical classloading is here to prevent dependencies to leak from plugin to plugin (so in this case, git-plugin would get the version it requires and so will the other plugins). What makes this situation special?

Thanks for any pointers!
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
Atlassian logo

mark.earl.waite@gmail.com (JIRA)

unread,
Mar 24, 2020, 10:20:03 AM3/24/20
to jenkinsc...@googlegroups.com

Oliver Gondža sorry for the confusion caused by not having the same major version number on git client plugin and git plugin releases.

Git client 3.x bundles JGit 5.x and is intended to be used by git plugin 4.x and later. Git client 2.x bundles JGit 4.x and is intended to be used by git plugin 3.x. In the case for your customer, the preferred change is probably to switch them either from git client plugin 3.0.0 to git client plugin

You're correct that the JGit project made API breaking changes between JGit 4.x and JGit 5.x. Those API breaking changes required that we "lock-step" release the git plugin 4.x release and the git client plugin 3.x release.

I'm not expert enough with the Jenkins class loader or with Java class loading to know if it is possible to have git client plugin 3.x loaded in memory with its bundled copy of JGit 5.x and still have git plugin 3.x cause the loading of JGit 4.x into memory. The git plugin depends on git client and does not declare a dependency on JGit. The git plugin relies on the git client plugin's commitment to always provide a JGit implementation.

I think in your case that you want to either downgrade from git client plugin 3.0.0 to git client plugin 2.9.0 or upgrade from git plugin 3.12.0 to git plugin 4.2.2. In terms of functionality change, the downgrade from git client plugin 3.0.0 to git client plugin 2.9.0 is smaller than the change from git plugin 3.12.0 to git plugin 4.2.2.

mark.earl.waite@gmail.com (JIRA)

unread,
Mar 24, 2020, 10:21:02 AM3/24/20
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-53004
[~olivergondza] sorry for the confusion caused by not having the same major version number on git client plugin and git plugin releases.  


Git client 3.x bundles JGit 5.x and is intended to be used by git plugin 4.x and later.  Git client 2.x bundles JGit 4.x and is intended to be used by git plugin 3.x.  In the case for your customer, the preferred change is probably to switch them either from git client plugin 3.0.0 to git client plugin

 2.9.0.

You're correct that the JGit project made API breaking changes between JGit 4.x and JGit 5.x.  Those API breaking changes required that we "lock-step" release the git plugin 4.x release and the git client plugin 3.x release.

I'm not expert enough with the Jenkins class loader or with Java class loading to know if it is possible to have git client plugin 3.x loaded in memory with its bundled copy of JGit 5.x and still have git plugin 3.x cause the loading of JGit 4.x into memory.  The git plugin depends on git client and does not declare a dependency on JGit.  The git plugin relies on the git client plugin's commitment to always provide a JGit implementation.

I think in your case that you want to either downgrade from git client plugin 3.0.0 to git client plugin 2.9.0 or upgrade from git plugin 3.12.0 to git plugin 4.2.2.  In terms of functionality change, the downgrade from git client plugin 3.0.0 to git client plugin 2.9.0 is smaller than the change from git plugin 3.12.0 to git plugin 4.2.2.

mark.earl.waite@gmail.com (JIRA)

unread,
Mar 24, 2020, 10:57:05 AM3/24/20
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-53004
[~olivergondza] sorry for the confusion caused by not having the same major version number on git client plugin and git plugin releases.  

Git client 3.x bundles JGit 5.x and is intended to be used by git plugin 4.x and later.  Git client 2.x bundles JGit 4.x and is intended to be used by git plugin 3.x.  In the case for your customer, the preferred change is probably to switch them either from git client plugin 3.0.0 to git client plugin 2.9.0 or from git plugin 3 . 12.0 to git plugin 4.2.2.

You're correct that the JGit project made API breaking changes between JGit 4.x and JGit 5.x.  Those API breaking changes required that we "lock-step" release the git plugin 4.x release and the git client plugin 3.x release.

I'm not expert enough with the Jenkins class loader or with Java class loading to know if it is possible to have git client plugin 3.x loaded in memory with its bundled copy of JGit 5.x and still have git plugin 3.x cause the loading of JGit 4.x into memory.  The git plugin depends on git client and does not declare a dependency on JGit.  The git plugin relies on the git client plugin's commitment to always provide a JGit implementation.

I think in your case that you want to either downgrade from git client plugin 3.0.0 to git client plugin 2.9.0 or upgrade from git plugin 3.12.0 to git plugin 4.2.2.  In terms of functionality change, the downgrade from git client plugin 3.0.0 to git client plugin 2.9.0 is smaller than the change from git plugin 3.12.0 to git plugin 4.2.2.

ogondza@gmail.com (JIRA)

unread,
Mar 24, 2020, 3:09:03 PM3/24/20
to jenkinsc...@googlegroups.com

Thanks, Mark. Provided both git-plugin and git-client-plugin depend on jgit passing its objects between the codebases, I doubt any amount of classloader isolation is going to save us. I have not realized it is this 2 plugins that are clashing. Thanks for your recommendations.

ogondza@gmail.com (JIRA)

unread,
Mar 24, 2020, 3:09:04 PM3/24/20
to jenkinsc...@googlegroups.com
Oliver Gondža edited a comment on Bug JENKINS-53004
[~markewaite], we have a customer running into this with git-client 3.0.0 and git-plugin 3.12.0. The way I understand your analysis here is, an older jgit is leaking from some other plugin so git-(client-)plugin built against jgit5 is invoking signatures that was not present in the older version that is leaking in - so the fix is to get all those plugins to versions using more or less same (major) version of jgit. I tend to agree this might be the case have here , as my Jenkins has loaded 2 older versions of jgit:

{noformat}

$ ls -l /proc/9972/fd/ | grep jgit
lr-x------. 1 jenkins jenkins 64 Mar 24 13:30 333 -> /var/lib/jenkins/plugins/git-client/WEB-INF/lib/org.eclipse.jgit.lfs-5.5.1.201910021850-r.jar
lr-x------. 1 jenkins jenkins 64 Mar 24 13:30 334 -> /var/lib/jenkins/plugins/git-client/WEB-INF/lib/org.eclipse.jgit.http.apache-5.5.1.201910021850-r.jar
lr-x------. 1 jenkins jenkins 64 Mar 24 13:30 337 -> /var/lib/jenkins/plugins/git-client/WEB-INF/lib/org.eclipse.jgit.http.server-5.5.1.201910021850-r.jar
lr-x------. 1 jenkins jenkins 64 Mar 24 13:30 338 -> /var/lib/jenkins/plugins/git-client/WEB-INF/lib/org.eclipse.jgit-5.5.1.201910021850-r.jar
lr-x------. 1 jenkins jenkins 64 Mar 24 13:30 548 -> /var/lib/jenkins/plugins/blueocean-events/WEB-INF/lib/org.eclipse.jgit-4.5.4.201711221230-r.jar
lr-x------. 1 jenkins jenkins 64 Mar 24 13:30 549 -> /var/lib/jenkins/plugins/blueocean-events/WEB-INF/lib/org.eclipse.jgit.http.server-4.5.4.201711221230-r.jar
lr-x------. 1 jenkins jenkins 64 Mar 24 13:30 553 -> /var/lib/jenkins/plugins/blueocean-events/WEB-INF/lib/org.eclipse.jgit.http.apache-4.5.4.201711221230-r.jar
lr-x------. 1 jenkins jenkins 64 Mar 24 13:30 764 -> /var/lib/jenkins/plugins/gitlab-plugin/WEB-INF/lib/org.eclipse.jgit-3.5.2.201411120430-r.jar
{noformat}


However, I was under assumption that Jenkins hierarchical classloading is here to prevent dependencies to leak from plugin to plugin (so in this case, git-plugin would get the version it requires and so will the other plugins). What makes this situation special?

Thanks for any pointers!

steven.dillon@virtualsilicon.co.uk (JIRA)

unread,
Apr 19, 2020, 8:23:03 AM4/19/20
to jenkinsc...@googlegroups.com

Hi Mark Waite

I am having a similar problem in that when i try an SCM build from a git repo i get the error below:

Jenkins v2.204.1

git version 2.23.1

java.lang.NoSuchMethodError: org.eclipse.jgit.lib.Repository.getRef(Ljava/lang/String;)Lorg/eclipse/jgit/lib/Ref; at jenkins.plugins.git.GitSCMFileSystem$1.invoke(GitSCMFileSystem.java:117) at jenkins.plugins.git.GitSCMFileSystem$1.invoke(GitSCMFileSystem.java:114) at jenkins.plugins.git.GitSCMFileSystem$3.invoke(GitSCMFileSystem.java:193) at org.jenkinsci.plugins.gitclient.AbstractGitAPIImpl.withRepository(AbstractGitAPIImpl.java:29) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.withRepository(CliGitAPIImpl.java:80) at jenkins.plugins.git.GitSCMFileSystem.invoke(GitSCMFileSystem.java:189) at jenkins.plugins.git.GitSCMFileSystem.<init>(GitSCMFileSystem.java:114) at jenkins.plugins.git.GitSCMFileSystem$BuilderImpl.build(GitSCMFileSystem.java:353) at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:197) at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:173) at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:115) at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:69) at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:309) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:427) Finished: FAILURE

This doesn't seem to match the other errors submitted exactly but pretty close. Is this again a problem between one plugin or another. Thanks Steve

mark.earl.waite@gmail.com (JIRA)

unread,
Apr 19, 2020, 8:40:03 AM4/19/20
to jenkinsc...@googlegroups.com

Yes steven dillon, that is the message that happens when a plugin (like git plugin 3.x) attempts to access a method getRef that no longer exists in the JGit implementation that is bundled with git client plugin 3.x. Git plugin 4.x must be used with git client plugin 3.x. Git plugin 3.x is not intended to be used with git client plugin 3.x. Upgrading the called plugin (git client) without upgrading the callers (git plugin, git server plugin, GitHub branch source, Gitea, Bitbucket, etc.) can lead to that error.

mark.earl.waite@gmail.com (JIRA)

unread,
Apr 19, 2020, 10:36:02 AM4/19/20
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-53004
Yes [~ciscokid], that is the message that happens when a plugin (like git plugin 3.x) attempts to access a method {{getRef}} that no longer exists in the JGit implementation that is bundled with git client plugin 3.x.  Git plugin * 4.x * must be used with git client plugin * 3.x * .  Git plugin 3.x is * not * intended to be used with git client plugin 3.x. Upgrading the called plugin (git client) from 2 to 3 without upgrading the callers (git plugin from 3 to 4 , git server plugin, GitHub branch source, Gitea, Bitbucket, etc.) can lead to that error.
Reply all
Reply to author
Forward
0 new messages