Re: RateLimitHandler error

51 views
Skip to first unread message

Ullrich Hafner

unread,
Jul 3, 2017, 5:47:35 AM7/3/17
to Jenkins Developers
Please use the issue tracker to report bugs.

Am 03.07.2017 um 05:48 schrieb Luo <abj...@gmail.com>:

Hi Expert
  I'm running Jenkins with gitlab, when I trigger a build, there are following error in console:

FATAL: org/kohsuke/github/RateLimitHandler
java.lang.NoClassDefFoundError: org/kohsuke/github/RateLimitHandler
	at org.jenkinsci.plugins.github_branch_source.GitHubBuildStatusNotification.createBuildCommitStatus(GitHubBuildStatusNotification.java:139)
	at org.jenkinsci.plugins.github_branch_source.GitHubBuildStatusNotification.access$500(GitHubBuildStatusNotification.java:69)
	at org.jenkinsci.plugins.github_branch_source.GitHubBuildStatusNotification$JobCheckOutListener.onCheckout(GitHubBuildStatusNotification.java:285)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
	at hudson.model.Run.execute(Run.java:1741)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:410)
Caused by: java.lang.ClassNotFoundException: org.kohsuke.github.RateLimitHandler
	at jenkins.util.AntClassLoader.findClassInComponents(AntClassLoader.java:1376)
	at jenkins.util.AntClassLoader.findClass(AntClassLoader.java:1326)
	at jenkins.util.AntClassLoader.loadClass(AntClassLoader.java:1079)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
	... 10 more


How can I fix it?

thanks!

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/12fa1b3a-5150-4750-93f0-3ae791306e4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

signature.asc

Oleg Nenashev

unread,
Jul 3, 2017, 12:49:18 PM7/3/17
to Jenkins Developers, James Dumay
Likely it is a binary conflict with GitHub API version older than 1.64 (commit: https://github.com/kohsuke/github-api/commit/4093e53b5b7eb16e0b4de184a93262285ee6164b).

The first step is to ensure that all plugins depend on GitHub API Plugin instead of the direct library dependency. Added James Dumay to cc, because here is something strange in BlueOcean: https://github.com/jenkinsci/blueocean-plugin/blob/404ac7275b4bac85b8ebaea3e7245abc94cb4769/blueocean-github-pipeline/pom.xml#L32-L35 . I do not see other direct GitHub API usages within jenkinsci org plugins from what I see

понедельник, 3 июля 2017 г., 11:47:35 UTC+2 пользователь Ullrich Hafner написал:

James Dumay

unread,
Jul 3, 2017, 9:19:40 PM7/3/17
to Jenkins Developers, Oleg Nenashev
We depend on it directly because we use it directly to make the Pipeline Editor work. 

https://github.com/jenkinsci/blueocean-plugin/blob/404ac7275b4bac85b8ebaea3e7245abc94cb4769/pom.xml#L471 

We just started to use that new API for handling rate limits and abuse limits so the UI doesn't freeze up.


The other plugin that does not depend on the Github plugin but probably shouldn't (isn't SCM related) is the Github Oauth plugin. It also uses the limit handlers to prevent web threads from being eaten and locking up the UI.


A few things here:
* perhaps we need to shade in the Github library into each plugin that requires it. Avoid version hell altogether
* start versioning the Github library so it's clear when there are major breaking changes between versions. Stephen C does an excellent job at this for all the branch and scm API changes.
--
James Dumay,
Director of Product Management.
CloudBees, Inc.

Meet with me: https://calendly.com/jdumay
Skype: jdumaycb Twitter: i386

Oleg Nenashev

unread,
Jul 4, 2017, 3:08:14 AM7/4/17
to Jenkins Developers, o.v.ne...@gmail.com, Sam Gleske
Thanks James for catching another dependency! Added Sam To Cc.

Anyway, both plugins use new versions of GitHub API, hence the should not cause the reported issue with the missing class. So it comes from something else, maybe from a transient library dependency. We definitely need a bug in JIRA with a list of plugin and a support core bundle to diagnose it more.

Regarding the reflection proposal, it looks a good approach though I do not know why BlueOcean can't just depend on the GitHub API plugin. In Github API lib there is direct class name references, so reflection should work. Proper reflection with OkHttp & Co will require more efforts though.

BR, Oleg


вторник, 4 июля 2017 г., 3:19:40 UTC+2 пользователь James Dumay написал:

James Dumay

unread,
Jul 5, 2017, 2:19:38 AM7/5/17
to Jenkins Developers, o.v.ne...@gmail.com, sam.m...@gmail.com
Reflection is also going to break when someone inevitably changes the library. As a rule we do not use such hacks in Blue Ocean.

Kanstantsin Shautsou

unread,
Jul 5, 2017, 7:10:22 PM7/5/17
to Jenkins Developers, o.v.ne...@gmail.com

A few things here:
* perhaps we need to shade in the Github library into each plugin that requires it. Avoid version hell altogether
* start versioning the Github library so it's clear when there are major breaking changes between versions. Stephen C does an excellent job at this for all the branch and scm API changes.

This library is claimed as backward compatible by KK (okhttp isn't updated and User/Org difference isn't implement also because of this) , that's why it wrapped into jenkins plugin and used by all other plugins.  While i were maintaining gh-api-plugin and gh-plugin i were checking them before releases (until few devs started doing changes without approval violating project rules, but it other story) and found broken binary compatibility few times. It was caused by Kohsuke's "maintaining style", or simply saying merge everything, make changes in one evening and release few minutes later. So some projects using direct library dep may hit incompatibilities between available gh-api-plugin versions. 
In theory breakage shouldn't happen, but if somebody depend directly on library, then it should shade it or play by jenkins classloaders rules and use plugin wrapper. Even today there are issues with this library, so probably it even makes sense to starting thinking on using some other library or fork it.

For those who requested support and eclude abstract discussions, please provide  https://wiki.jenkins.io/display/JENKINS/How+to+report+an+issue#Howtoreportanissue-WhatinformationtoprovideforEnvironmentandDescription 
Reply all
Reply to author
Forward
0 new messages