[cross-project-issues-dev] IOExceptions on hudson-slave1 -4 but not on -2
About half of the Virgo Hudson jobs started failing in the same way apparently since the server move at the weekend. The symptom is an IOException on some (undetermined) file. For example, Hudson » Virgo » virgo.apps.snapshot » #1264 failed with: /opt/users/hudsonbuild/workspace/virgo.apps.snapshot/virgo-build/common/common.xml:198: Execute failed: java.io.IOException: Cannot run program ant (in directory /opt/users/hudsonbuild/workspace/virgo.apps.snapshot/org.eclipse.virgo.apps.splash): java.io.IOException: error=2, No such file or directory I cleaned the workspace, but the problem persisted. The git revision checked out is correct. When I download a zip of the workspace, it builds locally. Building with the -v (verbose) and -d (debug) Ant switches produces additional diagnostics, but no hint of which file is causing the IOException. However the failures seem to correlate to Hudson slaves. hudson-slave2 doesn't hit the problem whereas hudson-slave1 and hudson-slave4 do hit the problem predictably. Since the Virgo jobs were configured against the build2 group consisting of slaves 1, 2, and 4 they were prone to running on the problem slaves. I' guessing this is associated with the configuration of those slaves and the fact that the Virgo jobs locate their shared Ivy cache in the home directory of the slave. I have reconfigured most of the jobs to run on hudson-slave2 and they are now passing. The virgo.medic.snapshot job is tied to hudson-slave4 and may be used to reproduce and hopefully diagnose the problem. I wonder if slaves 1 and 4 were somehow reconfigured during the server move? Regards, Glyn ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] cross-project-issues-dev Digest, Vol 84, Issue 5
Hi Denis You wrote: On 01/04/2013 04:35 AM, Glyn Normington wrote: Scott Lewis sle...@composent.com mailto:sle...@composent.com wrote: Hi Folks, Until recently, (ECF) has been signing our plugins by 'pushing' our plugins toeclipse.org http://eclipse.org/(built on our own builder machine...which is *not* running ateclipse.org http://eclipse.org/). Apparently this is not the appropriate way now...rather what Denis indicated was appropriate was to have an eclipse.org http://eclipse.org/machine 'pull' our unsigned plugins, sign them, and then put the signed versions somewhere. I assume that other projects do some/all of their build on non-eclipse systems...and need to do this as well. Are there ant scripts and/or documentation on this 'pull' approach for signing? I'm puzzled by the idea of a machine at eclipse.org http://eclipse.org pulling from a build machine running, for example, behind a corporate firewall. Maybe someone could clarify what Denis might have been meaning. If the remote build machine is behind a corporate firewall, it is not accessible anonymously by everyone on the planet and is being actively maintained by IT staff, then that gets my two thumbs up. By all means, put your committer ID's private key there and push all you want. Thanks for the clarification. (In the case of Virgo, we use our own machines for building, so security of committer private keys is already a given.) On the other hand, if your remote build machine is running a publicly web-accessible CI system with an open-to-the-world SSH port, I don't feel that the private key to your shell-enabled eclipse.org account is in a safe location. This is consistent with my position regarding committer private keys on our own publicly web-accessible Hudson instance. If committers really feel that the our CI system should have the ability to push commits to Git and push builds to the downloads area via a committer's account (and I agree, this would be immensely convenient), then we could perhaps consider closing hudson.eclipse.org to the anonymous users, thus requiring a committer account and authentication to access Hudson? Although I can see that some projects might want to use Hudson in this way, I wonder if any non-committers look at Hudson job status to get a feel for the stability of a project and would really miss being able to access that? In that case, if the risk of exposing the ssh port to the world is that someone will run a password cracking tool against it, would it be possible to allow HTTP traffic to Hudson but restrict the SSH access to requiring a committer's private key to authenticate? Regards, Glyn ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] signing question
Scott Lewis sle...@composent.com wrote: Hi Folks, Until recently, (ECF) has been signing our plugins by 'pushing' our plugins to eclipse.org (built on our own builder machine...which is *not* running at eclipse.org). Apparently this is not the appropriate way now...rather what Denis indicated was appropriate was to have an eclipse.org machine 'pull' our unsigned plugins, sign them, and then put the signed versions somewhere. I assume that other projects do some/all of their build on non-eclipse systems...and need to do this as well. Are there ant scripts and/or documentation on this 'pull' approach for signing? I'm puzzled by the idea of a machine at eclipse.org pulling from a build machine running, for example, behind a corporate firewall. Maybe someone could clarify what Denis might have been meaning. Thanksinadvance, Scott fyi Virgo milestones and releases are built on non-eclipse systems. Virgo's signing scripts, which are using the push model, were added recently in this commit: http://git.eclipse.org/c/virgo/org.eclipse.virgo.packaging.git/commit/?id=7f149be0b1c6ac54122c5f197876d711e42933d8 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Hudson job stuck
We've got more jobs in the zombie state. For instance, in some views virgo.kernel.snapshot #1252 is still running and can't be killed and in other views it seems to have finished. Similarly for virgo.util.snapshot #865 and virgo.medic.snapshot #820. Regards, Glyn On 25 Sep 2012, at 14:25, Glyn Normington wrote: Thanks for trying Matt, but https://hudson.eclipse.org/hudson/view/Virgo/job/virgo.artifact-repository.snapshot/752/ still shows a flashing blue ball and some small amount of progress on the progress bar, so I don't think it's quite dead yet. I tried a force refresh of the browser *and* another browser to guard against browser caching. Please could you be more brutal? Regards, Glyn On 25 Sep 2012, Webmaster(Matt Ward) webmas...@eclipse.org wrote: I've killed the job and it seems to be dead. -Matt. Dear Web Master I would be grateful if you could kill the following job, or recycle enough of Hudson to kill it: https://hudson.eclipse.org/hudson/view/Virgo/job/virgo.artifact-repository.snapshot/752/ We've tried multiple times and it won't die. Thanks. Regards, Glyn ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Hudson job stuck
Dear Web Master I would be grateful if you could kill the following job, or recycle enough of Hudson to kill it: https://hudson.eclipse.org/hudson/view/Virgo/job/virgo.artifact-repository.snapshot/752/ We've tried multiple times and it won't die. Thanks. Regards, Glyn ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Hudson job stuck
Thanks for trying Matt, but https://hudson.eclipse.org/hudson/view/Virgo/job/virgo.artifact-repository.snapshot/752/ still shows a flashing blue ball and some small amount of progress on the progress bar, so I don't think it's quite dead yet. I tried a force refresh of the browser *and* another browser to guard against browser caching. Please could you be more brutal? Regards, Glyn On 25 Sep 2012, Webmaster(Matt Ward) webmas...@eclipse.org wrote: I've killed the job and it seems to be dead. -Matt. Dear Web Master I would be grateful if you could kill the following job, or recycle enough of Hudson to kill it: https://hudson.eclipse.org/hudson/view/Virgo/job/virgo.artifact-repository.snapshot/752/ We've tried multiple times and it won't die. Thanks. Regards, Glyn ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Checksums on downloads
A user has pointed out that checksums downloaded over HTTP do not really add any security since a man-in-the-middle could substitute a checksum to match a substituted download. So why do we bother having these checksums? Would it be better to enable the checksums to be downloaded over https or does that put too much load on the mirrors? (Of course, the user prefers downloads to be signed, but that's another matter.) Regards, Glyn ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Hudson failures
Something drastic seems to have happened which is making a number of Virgo Hudson jobs fail. For instance: https://hudson.eclipse.org/hudson/view/Virgo/job/virgo.web-server.snapshot/909/console failed with the console output below, although I can successfully clone the repository locally. Regards, Glyn Started by user gnormington Building remotely on hudson-slave2 Checkout:virgo.web-server.snapshot / /opt/buildhomes/hudsonBuild/workspace/virgo.web-server.snapshot - hudson.remoting.Channel@393d701a:hudson-slave2 Using strategy: Default Last Built Revision: Revision 2ca8d842ef1ad5bc70059428ad45c32c27aff425 (origin/master) Checkout:virgo.web-server.snapshot / /opt/buildhomes/hudsonBuild/workspace/virgo.web-server.snapshot - hudson.remoting.LocalChannel@4f46c96c Fetching changes from the remote Git repository Fetching upstream changes from git://git.eclipse.org/gitroot/virgo/org.eclipse.virgo.web-server.git ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway ERROR: (Underlying report) : Error performing command: git fetch -t git://git.eclipse.org/gitroot/virgo/org.eclipse.virgo.web-server.git +refs/heads/*:refs/remotes/origin/* Command git fetch -t git://git.eclipse.org/gitroot/virgo/org.eclipse.virgo.web-server.git +refs/heads/*:refs/remotes/origin/* returned status code 128: fatal: The remote end hung up unexpectedly ERROR: Could not fetch from any repository FATAL: Could not fetch from any repository hudson.plugins.git.GitException: Could not fetch from any repository at hudson.plugins.git.GitSCM$3.invoke(GitSCM.java:887) at hudson.plugins.git.GitSCM$3.invoke(GitSCM.java:845) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1960) at hudson.remoting.UserRequest.perform(UserRequest.java:114) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:283) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Hudson failures
Glyn, Apologies for that -- we've done a bit of network maintenance, and there was a bad DNS entry. I've run your job again, and it works now. Denis Thanks Denis! ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Bugzilla down
Eclipse bugzilla appears to be down. Regards, Glyn ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Problem logging in to Hudson
Hi Markus Markus Knauer mkna...@eclipsesource.com wrote: It's working with my account. Did you try logging into other Eclipse services apart from the Portal, i.e. the Eclipse Wiki? Yes. I could log in to the wiki, the forums, bugzilla, the portal, but not Hudson. An hour or two later, I was also able to log in to Hudson once more. I guess we'll have to wait for this problem to last longer before it can be diagnosed... Regards, Glyn___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Hudson web page problems
Please ignore my post - this is the same a bug 373636 logged a little while ago by Thomas. (Shame I subscribe in digest mode in this particular instance.) Regards, Glyn ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
