Bugzilla – Full Text Bug Listing
| Summary: | Install gerrit-trigger plugin on main hudson and migrate egit/jgit verifier jobs from sandbox hudson | ||
|---|---|---|---|
| Product: | Community | Reporter: | Matthias Sohn <matthias.sohn> |
| Component: | CI-Jenkins | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel_megert, denis.roy, gregory.amerson, gunnar, jan.sievers, jesse.mcconnell, remy.suen, steffen.pingel, tomasz.zarna |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 375350 | ||
| Bug Blocks: | 393422 | ||
|
Description
Matthias Sohn
+1 I don't think we've seen any issues with the gerrit-trigger pluggin on the sandbox. Down the road, we may need to create gerrit-specific slaves and tie gerrit builds to them exclusively if we see gerrit is swamping Hudson with builds. But we'll cross that bridge when we get there. Yes, I think it will make sense to have dedicated slaves for the gerrit verification jobs. Usually they are faster since they typically compile everything and run the tests but don't package and sign. But there are many of them as every new change pushed for code review will trigger another build. But projects will definitively want these jobs as they are a great way to catch bugs before the changes are accepted into the master branch. In order to wire the gerrit-trigger plugin to Gerrit create a Gerrit ssh batch account [1] install that on Hudson and configure the gerrit-trigger plugin according to [2] (have a look at the sandbox hudson there it is already configured). [1] https://git.eclipse.org/r/Documentation/cmd-create-account.html [2] https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger OK I've added the Gerrit trigger, moved the jobs over from the sandbox and restarted things. Denis setup the user, and the test connection widget returns 'success'. Can we get verification that it's working as expected? -M. I've just pushed a new Patch Set to https://git.eclipse.org/r/#/c/5045/ but nothing happens. I even tried adding "Hudson CI" as a reviewer manually, still no luck. It seems it kicked of the egit.gerrit job on a new change [1], the build failed as the job looked at the old git URL, I fixed the job configuration and retriggered the build, it's currently waiting for an executor thread. I updated account 442 to display "Hudson CI" as full name for the batch account which triggered this build. It displayed as "Anonymous Coward" since its "Full name" was null. I'll close this bug when this works ok. [1] https://git.eclipse.org/r/#/c/5048/ The batch user used by Hudson currently does not have the required privileges, it should have the "Label Verified -1..+1" privilege on "refs/heads/*" otherwise it's not able to vote on changes it built. We should have a group "Hudson" and the batch user should be a member of this group and we need to grant this privilege to that group. Do you want me to define such a group or do you want to do that in LDAP ? We should grant this privilege on the "All-Projects" Ueber-project to enable Hudson to run verifications and vote accordingly for all projects using Gerrit. Go ahead and create a group in Gerrit and assign the privs to the All-Projects. I can't foresee needing such a group in LDAP. Thanks I can't save the job configuration when setting the choosing strategy for the git plugin to "Gerrit" since the git plugin version is much too old. This causes the exception [1]. Could you update the git plugin to at least the one used on sandbox hudson ? [1] Status Code: 500 Exception: Stacktrace: java.lang.NoClassDefFoundError: org/spearce/jgit/lib/ObjectId at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.getDeclaredMethods(Class.java:1791) at com.google.inject.spi.InjectionPoint.getInjectionPoints(InjectionPoint.java:662) at com.google.inject.spi.InjectionPoint.forInstanceMethodsAndFields(InjectionPoint.java:356) at com.google.inject.spi.InjectionPoint.forInstanceMethodsAndFields(InjectionPoint.java:375) at org.hudsonci.inject.injecto.internal.InjectomaticImpl.isInjectable(InjectomaticImpl.java:94) at org.hudsonci.inject.injecto.internal.InjectomaticImpl.inject(InjectomaticImpl.java:114) at org.hudsonci.inject.injecto.internal.InjectomaticAspectHelper.inject(InjectomaticAspectHelper.java:76) at org.hudsonci.inject.injecto.internal.InjectableAspect.ajc$afterReturning$org_hudsonci_inject_injecto_internal_InjectableAspect$1$cc99ea6d(InjectableAspect.aj:43) at com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.GerritTriggerBuildChooser.(GerritTriggerBuildChooser.java:39) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.kohsuke.stapler.RequestImpl.invokeConstructor(RequestImpl.java:419) at org.kohsuke.stapler.RequestImpl.access$300(RequestImpl.java:75) at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:626) at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:372) at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:368) at hudson.plugins.git.GitSCM$DescriptorImpl.newInstance(GitSCM.java:1104) at hudson.plugins.git.GitSCM$DescriptorImpl.newInstance(GitSCM.java:980) at hudson.scm.SCMS.parseSCM(SCMS.java:66) at hudson.model.AbstractProject.submit(AbstractProject.java:1709) at hudson.model.Project.submit(Project.java:191) at hudson.model.FreeStyleProject.submit(FreeStyleProject.java:99) at hudson.model.Job.doConfigSubmit(Job.java:1009) at hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:668) I've updated the Git plugin to 2.2.0... Just waiting for jobs to complete to restart. (In reply to comment #8) > Go ahead and create a group in Gerrit and assign the privs to the All-Projects. > I can't foresee needing such a group in LDAP. > > Thanks Added a group "Hudson" and made "Hudson CI" the only member. Granted the Verified Label -1..+1 to this group so that Hudson can vote on changes it ran a verification build for. (In reply to comment #10) > I've updated the Git plugin to 2.2.0... Just waiting for jobs to complete to > restart. I still get the same exception. I guess you installed the gerrit-trigger plugin from [1]. As this plugin is no longer maintained for Hudson this is outdated, this probably causes the error I reported, see [2]. Try to install the gerrit-trigger plugin from the Jenkins site (also explained in [2]) where it is maintained [3]. [4] specifies the plugin versions we used on sandbox hudson earlier. The Hudson / Jenkins split is really a mess :-( [1] http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Trigger [2] http://issues.hudson-ci.org/browse/HUDSON-9008 [3] https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger [4] http://dev.eclipse.org/mhonarc/lists/egit-dev/msg02431.html ping - any update here ? We really would like to re-enable our verification builds. > ping - any update here ?
Please be patient... Since disabling the 'old' Gerrit plugin Hudson has been quite stable. We are investigating, but we must avoid jeopardizing our Hudson's stability.
The plugin is still installed on the sandbox(and I updated it to point at our Gerrit intance), so I'm willing to copy your jobs to the sandbox and you can run them there until we get this resolved. If that sounds like a plan just let me know which jobs need to move. -M. Why is it so important that the trigger jobs run on the main server? Considering security wouldn't it be much better to run the trigger jobs on separate infrastructure with separate privileges? AFAIK, trigger jobs need to be specifically configured for Gerrit so most projects will end up with a separate snapshot/release job anyways. > Considering security wouldn't it be much better to run the trigger jobs on
> separate infrastructure
As more and more jobs become trigger jobs, it's definitely in our plans to force them onto separate hardware.
*** Bug 373429 has been marked as a duplicate of this bug. *** We won't install it on the main Hudson, but we do support it on individual HIPP instances. |