Community
Participate
Working Groups
This is purely my work item. But recently I made a job on Hudson to "promote" a Sim. Rel repo from "staging" to "releases". And something went wrong since it did not include the mirror.url nor "stats" line. (Thanks to Ed Merks for pointing this out BEFORE it was released!) So, the "Hudson promote" script needs work. Bot to "work correctly" and to "fail" if something goes wrong.
This is the log from the "promote" run: https://hudson.eclipse.org/simrel/view/Releng%20jobs/job/simrel.releng.promoteToReleases/22/console And it does say, in there, Starting application: 3240 INFO: artifact repository directory set from 'artifactRepoDirectory': null The artifact repository directory needs to be specified for this task. Try setting system property 'artifactRepoDirectory'? WARNING: repository was not rewritten But, at the same time the artifact repository IS part of the variables that are to become "VM arguments" devArgs: -Djava.io.tmpdir=/home/hudson/genie.simrel/.hudson/jobs/simrel.releng.promoteToReleases/workspace/tmp -Dp2MirrorsURL=http://www.eclipse.org/downloads/download.php?format=xml&file=/releases/neon/201605271000 -DartifactRepoDirectory=/home/data/httpd/download.eclipse.org/releases/neon/201605271000 -Dp2StatsURI=http://download.eclipse.org/stats/releases/neon -Dp2ArtifactRepositoryName=neon/201605271000 So, I suspect I am not "passing in" devArgs correctly to Eclipse.
I think I have fixed the script that does the promotion. The main problem, I think, was that I added quotes around $vmargs so the end of the command was -vmargs "$vmargs". I think that means that Eclipse got one big "vm arg" (that made no sense) instead of the 5 or 6 arguments it is supposed to get. I won't mention by name the "bash style checker" that recommended that, but will take it as a personal lesson not to believe "style checkers" blindly. :) Also, there were also several places I had "echoes" for "Fatal error" but they were not followed by an "exit". While not related to the current problem I fixed those too. I should be able to do a "sanity check" before the next "real run" and just delete the test data quickly so it doesn't bother the mirrors too much.
