Comment 1 Matthias Sohn 2015-12-26 18:19:29 EST

the version of the installed Gerrit trigger plugin is 2.5.3-h-2 which worked with the Hudson version we used before the upgrade (3.0.1-b2)

Comment 2 Mikaël Barbero 2016-01-07 09:40:07 EST

*** Bug 485355 has been marked as a duplicate of this bug. ***

Comment 3 Andrey Loskutov 2016-01-08 03:25:04 EST

Just wondering what is the root cause? Is there still any development community behind hudson, or everyone is on jenkins now?

https://projects.eclipse.org/projects/technology.hudson/who
https://github.com/jenkinsci/jenkins/graphs/commit-activity

Comment 4 Matthias Sohn 2016-01-08 04:58:39 EST

compare these numbers available on OpenHub:

Jenkins [1]
- last 12 months: 4701 commits from 292 contributors
- last  1 month:   159 commits from  35 contributors

Hudson [2]
- last 12 months: 110 commits from 7 contributors
- last  1 month:    5 commits from 2 contributors

[1] https://www.openhub.net/p/jenkins/commits/summary
[2] https://www.openhub.net/p/hudson/commits/summary

Looking at these numbers it seems to be time to fix bug 336262

Comment 5 Winston Prakash 2016-01-08 13:00:50 EST

(In reply to Matthias Sohn from comment #1)

Basically, Hudson core change did not cause this issue.

When we upgraded Spring security in Hudson 3.2.2, gerrit plugin was broken because Spring guys changed a  package name.

Looks like same thing happening in Hudson 3.3.2, when we moved to another version of Spring, the package name has changed again.

We have two options

- Keep all the plugins compatible to core but don't bother about outdated libraries in the core (like the Jenkins guys do, they still use Spring Security 1.x called acegi)

- Take a trade off (plugins may break) and upgrade libraries in the core for a secure and more stable core

Moving to Spring 3.1.2 in Hudson 3.3.2 is one such trade off because of major security issue in older version of Spring.

We tried our best to modify plugins that uses Spring API after releasing 3.3.2. Some how we missed Gerrit plugin.

I will compile the Gerrit plugin again with the changed package name and release a new version.

Comment 6 Winston Prakash 2016-01-08 13:17:58 EST

(In reply to Matthias Sohn from comment #4)

Also according to this statistics, 

http://stats.jenkins-ci.org/jenkins-stats/svg/svgs.html

Jenkins has more than 126,000 installations. While, Hudson has less than 15,000 installations.

Main reason any one (especially Enterprises) still wants to use Hudson is because of its stability and security, which we tried to maintain with slow, steady and thoroughly QA-ed core development, released every 3-6 months (where as Jenkins is released every week). We have no plans to change that mode of development  in the future also.

So, if Eclipse wants to use fast paced Jenkins as its build tool, we at Hudson project won't feel offended :)

Comment 7 Winston Prakash 2016-01-08 17:38:18 EST

(In reply to Winston Prakash from comment #5)

Sorry, I take that back. We did not upgrade Spring after Hudson 3.2.0. So Gerrit trigger plugin is 2.5.3-h-2 (released on Mar 26, 2015) is the correct version for  Hudson 3.3.2 also.

BTW, Gerrit Trigger 2.5.3-h-2 would not have worked with 3.0.1. That should be Gerrit Trigger 2.5.3-h-1.

Just make sure you have  Gerrit Trigger 2.5.3-h-2 installed for Hudson 3.2.0 and above

Comment 8 Matthias Sohn 2016-01-10 17:35:33 EST

(In reply to Winston Prakash from comment #7)
> (In reply to Winston Prakash from comment #5)
> 
> Sorry, I take that back. We did not upgrade Spring after Hudson 3.2.0. So
> Gerrit trigger plugin is 2.5.3-h-2 (released on Mar 26, 2015) is the correct
> version for  Hudson 3.3.2 also.
> 
> BTW, Gerrit Trigger 2.5.3-h-2 would not have worked with 3.0.1. That should
> be Gerrit Trigger 2.5.3-h-1.

after Mikaël downgraded we have gerrit-trigger plugin 2.5.3-h-1.

> Just make sure you have  Gerrit Trigger 2.5.3-h-2 installed for Hudson 3.2.0
> and above

AFAIR after the upgrade we had gerrit-trigger plugin 2.5.3-h2. Though it's possible I did a mistake during the upgrade. I will try it again.

Where do I find the gerrit-trigger plugin 2.5.3-h2 ?
Hudson 3.0.1-b2 which we now again use after the downgrade doesn't show it in Plugin Manager in tab "Updates" or "Available" and http://wiki.hudson-ci.org/display/HUDSON/Plugins currently shows an error message that Confluence isn't available due to some cluster failure

Comment 9 Winston Prakash 2016-01-11 11:49:03 EST

(In reply to Matthias Sohn from comment #8)

Hudson 3.0.1 core has older version of Spring, so gerrit-trigger plugin 2.5.3-h-2 will not work. When you upgrade to Hudson 3.3.2, the initial setup page will automatically pickup gerrit-trigger plugin 2.5.3-h-2 and advise you to upgrade to that version.

Hudson 3.0.1 uses http://hudson-ci.org/PluginCentral/site/3.0/ as Plugin Central, so its update center shows only version  gerrit-trigger plugin 2.5.3-h-1. Where as Hudson 3.3.2 uses http://hudson-ci.org/PluginCentral/site/3.3.2/, so you will see gerrit-trigger plugin 2.5.3-h-2 in its update center. 

If you missed to upgrade the plugins during initial setup, you can upgrade from update center later. We recommend to upgrade plugins at initial setup page, in order to avoid Hudson breaking at startup.


Using multiple Plugin Central helps us to upgrade core libraries, with out affecting older Hudson releases and its plugins.

Comment 10 Pierre-Charles David 2016-01-25 10:15:11 EST

FWIW, we recently upgraded the Sirius HIPP (https://hudson.eclipse.org/sirius) from Hudson 3.0.1-b2 to 3.3.2, and the version of the gerrit-trigger plug-in that we got after the upgrade (2.5.3-h-2) seems to work fine for us, including manual re-triggering of builds.

Comment 11 Matthias Sohn 2016-01-26 06:37:43 EST

thanks for this hint, I will retry the upgrade of our HIPPs

Comment 12 Matthias Sohn 2016-01-26 08:11:15 EST

I upgraded the EGit HIPP again and updated all plugins to the version recommended by the update center. The gerrit-trigger plugin is now version 2.5.3-h-2.
I am unable to update the Dashboard from 2.5-h-1 (Installed) to 2.9.2-h-1.
When trying to update that I get a green checkbox looking like this update succeeded. But after restarting Hudson it's back to the old version.

And manual Gerrit trigger again hits the problem described above. No clue why this seems to work for other HIPPs but not for this one.

Comment 13 Thomas Wolf 2016-01-30 12:41:35 EST

> And manual Gerrit trigger again hits the problem described above. No clue
> why this seems to work for other HIPPs but not for this one.

Indeed it does, also when retriggering a failed build:

Caused by: java.lang.NoSuchMethodError: hudson.model.Hudson.getAuthentication()Lorg/springframework/security/Authentication;
	at com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.GerritUserCause.<init>(GerritUserCause.java:93)
	at com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.GerritTrigger.retriggerThisBuild(GerritTrigger.java:551)
	at com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.actions.RetriggerAction.doIndex(RetriggerAction.java:144)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:274)
	at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:141)
	at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:80)
	at org.kohsuke.stapler.MetaClass$2.dispatch(MetaClass.java:140)
	at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:566)
	... 62 more

Unfortunately, we have a few unstable test cases in our test suite (yes, tracking those down and fixing them is on my to-do list), so not being able to retrigger is a nuisance and forces me to upload new patch sets to retrigger.

Comment 14 Matthias Sohn 2016-02-01 05:31:51 EST

(In reply to Thomas Wolf from comment #13)
> > And manual Gerrit trigger again hits the problem described above. No clue
> > why this seems to work for other HIPPs but not for this one.
> 
> Indeed it does, also when retriggering a failed build:
> 
> Caused by: java.lang.NoSuchMethodError:
> hudson.model.Hudson.getAuthentication()Lorg/springframework/security/
> Authentication;
> 	at
> com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.GerritUserCause.
> <init>(GerritUserCause.java:93)
> 	at
...
> Unfortunately, we have a few unstable test cases in our test suite (yes,
> tracking those down and fixing them is on my to-do list), so not being able
> to retrigger is a nuisance and forces me to upload new patch sets to
> retrigger.

I requested rollback of the upgrade in https://bugs.eclipse.org/bugs/show_bug.cgi?id=484915#c6