Community
Participate
Working Groups
The Scout project would like to request a dedicated Hudson instance.
+1
I've created a HIPP instance for Scout which can now be reached at https://hudson.eclipse.org/scout/ Scout committers should now be able to login and create jobs. Let me know if you need any additional Hudson plugins installed. Also we can optionally add the Scout HIPP user to the Scout project group which would allow Hudson to access any directories the scout project has access to including the downloads area and git repos. Is handy if you want to use Hudson for automatic build promotion. If this is something you'd like to have than reopen this bug and let us know.
Hi Thanh, Thank you for setting up an Hudson instance for the Eclipse Scout project. Could you please * install the Gerrit Trigger plugin and * grant write access to the Scout Hudson user for the download repo. However, we do NOT need write access to the Scout Git code repo for the Hudson user. Cheers, Ken
(In reply to Ken Lee from comment #3) > Hi Thanh, > > Thank you for setting up an Hudson instance for the Eclipse Scout project. > Could you please > * install the Gerrit Trigger plugin and > * grant write access to the Scout Hudson user for the download repo. > However, we do NOT need write access to the Scout Git code repo for the > Hudson user. I added the Hudson user to the scout group and installed the Gerrit Trigger. For these changes to take effect though I need to restart the Scout HIPP instance. I will do this when the current job finishes. Regarding write access to the code repo I just double checked and since your repos are Gerrit enabled the Hudson user won't have access to them anyway because the group ownership changes when we enable Gerrit.
I've restarted the instance. The changes should be in effect now but let me know if it isn't.
(In reply to Thanh Ha from comment #4) > I added the Hudson user to the scout group and installed the Gerrit Trigger. > For these changes to take effect though I need to restart the Scout HIPP > instance. I will do this when the current job finishes. Thank you very much for, Thanh. I'm currently experiencing problems with the HIPP for Scout but I'm not sure if this is really related to Hudson. Our last jobs [1] and [2] got stuck yesterday when downloading hamcrest.core from Orbit Stable: [INFO] Fetching org.hamcrest.core.source_1.3.0.v201303031735.jar.pack.gz from http://download.eclipse.org/tools/orbit/downloads/drops/S20130914154012/repository/plugins/ (3.96kB of 25.74kB at 0B/s) However, this does not happen on the shared Hudson instance. Do you have any further log files on the HIPP? I started a new job to see if this happens again after your restart. [1] https://hudson.eclipse.org/scout/job/scout-release/8/console [2] https://hudson.eclipse.org/scout/job/scout-release/9/console
In addition, could you also install the Coverity Scan plugin [1] for us? Thanks in advance. [1] https://scan.coverity.com/faq#eclipse
We also need the SVN plugin installed to build our Scout legacy branch [1]. [1] https://hudson.eclipse.org/hudson/job/scout-release-legacy/
I've installed the coverity and SVN plugins. (In reply to Ken Lee from comment #6) > However, this does not happen on the shared Hudson instance. Do you have any > further log files on the HIPP? > > I started a new job to see if this happens again after your restart. > > [1] https://hudson.eclipse.org/scout/job/scout-release/8/console > [2] https://hudson.eclipse.org/scout/job/scout-release/9/console I see this job is passing now. Is this still an issue or did you do something to allow it to pass?
(In reply to Thanh Ha from comment #9) > I've installed the coverity and SVN plugins. Thank you. Could it be that the optional function has to be installed separately? According to [1] it says: "The Coverity plugin for Hudson performs 3 functions: * it can transparently invoke the Coverity Static Analysis tools during your build (optionally)" This is exactly what I'm looking for. At the moment I'm only able to configure the post-build steps. > I see this job is passing now. Is this still an issue or did you do > something to allow it to pass? To be honest, I didn't change any configuration settings. Your first restart might be the reason that the job runs successfully now. [1] http://wiki.hudson-ci.org/display/HUDSON/Coverity+Plugin
(In reply to Ken Lee from comment #10) > (In reply to Thanh Ha from comment #9) > > I've installed the coverity and SVN plugins. > > Thank you. Could it be that the optional function has to be installed > separately? According to [1] it says: > hmm... looks like I think I installed the wrong coverity plugin. On the sandbox there is the "Coverity Scan Plugin" while on the HIPP instance which I installed from the plugin manager is the "Coverity Plugin". I don't know much about either plugins but I will see if I can get the "Coverity Scan Plugin" installed so that it's the same as the sandbox.
(In reply to Thanh Ha from comment #11) > On the sandbox there is the "Coverity Scan Plugin" while on the HIPP > instance which I installed from the plugin manager is the "Coverity Plugin". > I don't know much about either plugins but I will see if I can get the > "Coverity Scan Plugin" installed so that it's the same as the sandbox. Yes, the name of the plugin we use at the sandbox Hudson is called "Coverity Scan" plugin. Would be great if this plugin could be installed.
(In reply to Ken Lee from comment #12) > (In reply to Thanh Ha from comment #11) > > On the sandbox there is the "Coverity Scan Plugin" while on the HIPP > > instance which I installed from the plugin manager is the "Coverity Plugin". > > I don't know much about either plugins but I will see if I can get the > > "Coverity Scan Plugin" installed so that it's the same as the sandbox. > > Yes, the name of the plugin we use at the sandbox Hudson is called "Coverity > Scan" plugin. Would be great if this plugin could be installed. I think I got the right plugin this time. Need to restart the instance so I will do it once the current build is done.
(In reply to Thanh Ha from comment #13) > I think I got the right plugin this time. Need to restart the instance so I > will do it once the current build is done. The plugin is now installed bug I am getting NullPointerException when it tries to initialize. I'm not entirely sure why. I copied this same plugin from the Hudson sandbox instance. At the moment one difference I think is that the sandbox Hudson version 3.0.0 while the HIPP instance is hudson version 3.0.1 SEVERE: Failed Initializing plugin scan-plugin java.lang.NullPointerException at hudson.PluginManager$2$1$2.run(PluginManager.java:315) at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259) at hudson.model.Hudson$4.runTask(Hudson.java:667) at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187) at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724)
(In reply to Thanh Ha from comment #14) > (In reply to Thanh Ha from comment #13) > > I think I got the right plugin this time. Need to restart the instance so I > > will do it once the current build is done. > > The plugin is now installed bug I am getting NullPointerException when it > tries to initialize. I'm not entirely sure why. I copied this same plugin > from the Hudson sandbox instance. > > At the moment one difference I think is that the sandbox Hudson version > 3.0.0 while the HIPP instance is hudson version 3.0.1 > I opened a bug with the scan-plugin project [1] [1] https://github.com/kaizer113/scan-plugin/issues/1
(In reply to Thanh Ha from comment #15) > I opened a bug with the scan-plugin project [1] > > [1] https://github.com/kaizer113/scan-plugin/issues/1 Thank you Thanh for opening a bug report for the Coverity scan plugin. In the meantime another problem has arisen: Our Scout legacy nightly build fails when running on the Scout HIPP [1]. It seems that Scout Hudson user does not have the permission to write into the directory '/home/data/httpd/download-staging.priv/technology/scout/nightly/out/sign.zip' What is the username of the Scout Hudson user and to which group does it belong? Is it genie.technology.scout? This user belongs to the group 'technology.scout' where all members should have read-write-executable rights in that directory. [1] https://hudson.eclipse.org/scout/job/scout-legacy-nightly/1/console
(In reply to Ken Lee from comment #16) > (In reply to Thanh Ha from comment #15) > > I opened a bug with the scan-plugin project [1] > > > > [1] https://github.com/kaizer113/scan-plugin/issues/1 > > Thank you Thanh for opening a bug report for the Coverity scan plugin. > In the meantime another problem has arisen: Our Scout legacy nightly build > fails when running on the Scout HIPP [1]. It seems that Scout Hudson user > does not have the permission to write into the directory > '/home/data/httpd/download-staging.priv/technology/scout/nightly/out/sign. > zip' > Odd for some reason the sign tool was missing on the server. I copied it back over and tested that the genie.technology.scout user can run it. Can you try again and see if it's any better? (the permission denied error you got referred to the missing 'sign' tool, not an issue with directory permissions) > What is the username of the Scout Hudson user and to which group does it > belong? > Is it genie.technology.scout? This user belongs to the group > 'technology.scout' where all members should have read-write-executable > rights in that directory. > Yes genie.technology.scout is the user for your instance.
(In reply to Thanh Ha from comment #17) > Odd for some reason the sign tool was missing on the server. I copied it > back over and tested that the genie.technology.scout user can run it. Can > you try again and see if it's any better? > > (the permission denied error you got referred to the missing 'sign' tool, > not an issue with directory permissions) > It seems that the same error still occurs [1]. Is the sign tool missing again? [1] https://hudson.eclipse.org/scout/job/scout-legacy-nightly/2/console
(In reply to Ken Lee from comment #18) > It seems that the same error still occurs [1]. Is the sign tool missing > again? > sign tool is there and I can run it as the genie.technology.scout user from the commandline. Not sure why from inside a Hudson job it gets permission denied (I even restarted the instance just in case). I'll keep investigating, I created a test-sign-tool job to investigate.
(In reply to Thanh Ha from comment #19) > (In reply to Ken Lee from comment #18) > > It seems that the same error still occurs [1]. Is the sign tool missing > > again? > > > > sign tool is there and I can run it as the genie.technology.scout user from > the commandline. Not sure why from inside a Hudson job it gets permission > denied (I even restarted the instance just in case). I'll keep > investigating, I created a test-sign-tool job to investigate. Very strange... I managed to get Hudson to be able to run it in my test job so I think it's fixed now. Can you try again? What I did was removed the Hudson user from the signers group, then re-added the user back to the signers group and restarted Hudson. I guess something was messed up with the unix account.
(In reply to Thanh Ha from comment #20) > Very strange... I managed to get Hudson to be able to run it in my test job > so I think it's fixed now. Can you try again? > > > What I did was removed the Hudson user from the signers group, then re-added > the user back to the signers group and restarted Hudson. I guess something > was messed up with the unix account. The problem does still occur but now the error message is a bit different [1]. What confuses me is that the user who wants to write into the directory is called genie instead of genie.technology.scout. [mkdir] Created dir: /home/data/httpd/download-staging.priv/technology/scout/nightly/in [mkdir] Created dir: /home/data/httpd/download-staging.priv/technology/scout/nightly/out [zip] Building zip: /home/data/httpd/download-staging.priv/technology/scout/nightly/in/sign.zip [exec] WARNING: outputDir /home/data/httpd/download-staging.priv/technology/scout/nightly/out not writable by user genie. Changing permissions to make file group-writable. [exec] [exec] WARNING: File /home/data/httpd/download-staging.priv/technology/scout/nightly/in/sign.zip not writable by user genie. Changing permissions to make file group-writable. [exec] [exec] File /home/data/httpd/download-staging.priv/technology/scout/nightly/in/sign.zip added to queue. [exec] You will receive notification when the file is signed, if you used the mail parameter. [exec] [exec] You can check signing status by tailing /home/data/httpd/download-staging.priv/arch/signer.log [exec] [waitForFile] wait for '/home/data/httpd/download-staging.priv/technology/scout/nightly/out/sign.zip'. [1] https://hudson.eclipse.org/scout/job/scout-legacy-nightly/3/console
see comment 21
The build is successful finally. The console log is similar to our shared Hudson build [1]. Will mark this bug as resolved. Thanks for your assistance! [1] https://hudson.eclipse.org/hudson/job/scout-release-legacy/1145/console
It seems that there are still some issues with the signing process on the HIPP. However, this time the Maven build is affected if you have a look at [1] and [2]. Those two builds were triggered as a nightly build. The build [3] was triggered manually and was running successfully. Not sure if this is somehow related. Could you have a look at this problem? [1] https://hudson.eclipse.org/scout/job/scout-head-nightly/4/console [2] https://hudson.eclipse.org/scout/job/scout-head-nightly/6/console [3] https://hudson.eclipse.org/scout/job/scout-head-nightly/5/console
(In reply to Ken Lee from comment #24) > It seems that there are still some issues with the signing process on the > HIPP. However, this time the Maven build is affected if you have a look at > [1] and [2]. > Those two builds were triggered as a nightly build. The build [3] was > triggered manually and was running successfully. Not sure if this is somehow > related. Could you have a look at this problem? > > [1] https://hudson.eclipse.org/scout/job/scout-head-nightly/4/console > [2] https://hudson.eclipse.org/scout/job/scout-head-nightly/6/console > [3] https://hudson.eclipse.org/scout/job/scout-head-nightly/5/console Are you using the CBI Maven plugins for signing? I think this may be a fluke that just happened to happen twice for you. The platform has seen this happen twice (half a year apart) in the past as well. Which I've raised a bug 417940 after some discussion with David Williams in regards to the CBI signing plugins. What happens is if the signing server doesn't respond due to some unexpected issues such as being too busy for a short time or just a hiccup on the server. The CBI plugin doesn't retry so instead it fails the entire build instead. We should certainly monitor this if this occurs frequently but from what I've seen with the platform builds this situation happens very rarely.
(In reply to Thanh Ha from comment #25) > I think this may be a fluke that just happened to happen twice for you. The > platform has seen this happen twice (half a year apart) in the past as well. > Which I've raised a bug 417940 after some discussion with David Williams in > regards to the CBI signing plugins. Sorry this should have been bug 419064.
(In reply to Thanh Ha from comment #25) > > Are you using the CBI Maven plugins for signing? Yes, we are using the CBI Maven plugin jar-signer. > What happens is if the signing server doesn't respond due to some unexpected > issues such as being too busy for a short time or just a hiccup on the > server. The CBI plugin doesn't retry so instead it fails the entire build > instead. > > We should certainly monitor this if this occurs frequently but from what > I've seen with the platform builds this situation happens very rarely. Ok, we will observe in the next weeks if this issue will come up again. In the meantime, I discovered that the Hudson job [1] gets stuck again when downloading org.hamcrest.core.source_1.3.0.v201303031735.jar.pack.gz from http://download.eclipse.org/tools/orbit/downloads/drops/S20130914154012/repository/plugins/ as I reported in comment 6. Is this related to the Orbit update site or to the Scout HIPP? [1] https://hudson.eclipse.org/scout/job/scout-head-nightly/7/console
(In reply to Ken Lee from comment #27) > In the meantime, I discovered that the Hudson job [1] gets stuck again when > downloading org.hamcrest.core.source_1.3.0.v201303031735.jar.pack.gz from > http://download.eclipse.org/tools/orbit/downloads/drops/S20130914154012/ > repository/plugins/ as I reported in comment 6. > > Is this related to the Orbit update site or to the Scout HIPP? > > [1] https://hudson.eclipse.org/scout/job/scout-head-nightly/7/console Hmm this is very odd. We checked our server logs and it looks like it's successful from a server-side perspective. I'm not sure why Maven is getting stuck on this file. Looks like this time it's happening on a different job this time though. I wonder how reproducible it is. Can we rerun this job again and see if it continues to happen? Proxy Logs: proxy - - [11/Oct/2013:08:27:22 -0400] "GET http://download.eclipse.org/tools/orbit/downloads/drops/S20130914154012/repository/plugins/org.hamcrest.core.source_1.3.0.v201303031735.jar.pack.gz HTTP/1.1" 200 26361 "-" "Apache-HttpClient/4.1.3 (java 1.5)" proxy - - [11/Oct/2013:09:33:18 -0400] "GET http://download.eclipse.org/tools/orbit/downloads/drops/S20130914154012/repository/plugins/org.hamcrest.core.source_1.3.0.v201303031735.jar.pack.gz HTTP/1.1" 200 26361 "-" "Apache-HttpClient/4.1.3 (java 1.5)" proxy - - [11/Oct/2013:09:33:19 -0400] "GET http://download.eclipse.org/tools/orbit/downloads/drops/S20130914154012/repository/plugins/org.hamcrest.core.source_1.3.0.v201303031735.jar.pack.gz HTTP/1.1" 200 26361 "-" "Apache-HttpClient/4.1.3 (java 1.5)" download.eclipse.org logs: download - - [11/Oct/2013:08:27:22 -0400] "GET /tools/orbit/downloads/drops/S20130914154012/repository/plugins/org.hamcrest.core.source_1.3.0.v201303031735.jar.pack.gz HTTP/1.1" 200 26361 "-" "Apache-HttpClient/4.1.3 (java 1.5)" download - - [11/Oct/2013:09:33:18 -0400] "GET /tools/orbit/downloads/drops/S20130914154012/repository/plugins/org.hamcrest.core.source_1.3.0.v201303031735.jar.pack.gz HTTP/1.1" 200 26361 "-" "Apache-HttpClient/4.1.3 (java 1.5)" download - - [11/Oct/2013:09:33:19 -0400] "GET /tools/orbit/downloads/drops/S20130914154012/repository/plugins/org.hamcrest.core.source_1.3.0.v201303031735.jar.pack.gz HTTP/1.1" 200 26361 "-" "Apache-HttpClient/4.1.3 (java 1.5)"
Could the version of Java used (java 1.5?) have any impact here?
(In reply to Thanh Ha from comment #28) > Looks like this time it's happening on a different job this time though. I > wonder how reproducible it is. Can we rerun this job again and see if it > continues to happen? I aborted the job and restarted it [1]. Some details about the build job: The build job verifies (mvn clean verify) that Scout can be build against the platforms Indigo, Juno, Kepler and Luna and finally builds (mvn clean install) and deploys against Helios. If you search for the line in the full log [2] "Fetching org.hamcrest.core.source_1.3.0.v201303031735.jar.pack.gz from" you can see that the same file was fetched when verifying against Indigo platform. However, it gets stuck when the build runs against Helios. [1] https://hudson.eclipse.org/scout/job/scout-head-nightly/8/ [2] https://hudson.eclipse.org/scout/job/scout-head-nightly/7/consoleFull
Since this morning, we've been experiencing problems with our Scout Hudson (see [1] and [2] for example). Maven gets stucked and waits for a connection on a specific port. Example: [DEBUG] Waiting for connection on port: 40472 Could anyone have a look at this? Thanks in advance. [1] https://hudson.eclipse.org/scout/view/Scout%20Gerrit%20Jobs/job/org.eclipse.scout.rt_gerrit/148/console [2] https://hudson.eclipse.org/scout/view/Scout%20Gerrit%20Jobs/job/org.eclipse.scout.rt_gerrit/149/console
(In reply to Ken Lee from comment #31) > Since this morning, we've been experiencing problems with our Scout Hudson > (see [1] and [2] for example). > Maven gets stucked and waits for a connection on a specific port. > > Example: [DEBUG] Waiting for connection on port: 40472 > > Could anyone have a look at this? > That port seems to change each time, a few lines up I can see Maven adds that command as an eventspy port "-Dhudson.eventspy.port=40472" although I'm not entirely sure what that is. I can see you have successful builds after those failed ones though. Is this problem intermittent?
(In reply to Thanh Ha from comment #32) > (In reply to Ken Lee from comment #31) > > Since this morning, we've been experiencing problems with our Scout Hudson > > (see [1] and [2] for example). > > Maven gets stucked and waits for a connection on a specific port. > > > > Example: [DEBUG] Waiting for connection on port: 40472 > > > > Could anyone have a look at this? > > > > That port seems to change each time, a few lines up I can see Maven adds > that command as an eventspy port "-Dhudson.eventspy.port=40472" although I'm > not entirely sure what that is. > > I can see you have successful builds after those failed ones though. Is this > problem intermittent? I'm seeing this issue on Platform HIPP as well, see builds 95 and 96: https://hudson.eclipse.org/platform/job/eclipse-aggregator-master
I'm closing this one since this new issue needs it's own bug. I opened up bug 422852 for tracking the newer issue.
