Community
Participate
Working Groups
See Bug 412933. At a minimum, we will have to tweak from of our URLs, such as the one used to remotely "start a test". The new "base" URL will be https://hudson.eclipse.org/shared/
(Should do this on Friday, or weekend). The old stuff should "still work" except, I think, for "the Windows box", which can only be connected to "one or the other". And, we will need that, to properly produce our maintenance build for RC1 (not to mention Nightly builds).
Starting Friday night's N-build slightly late, to get in initial fix. Added variable to control whether URI segment is "hudson" or "shared" (That is, to change from the hard-coded "hudson" to the variable that is set to "shared" -- this allows me to not change my test machine's hudson setup). One file, collectTestResults.xml, has to be the same between streams as it is part of a cronjob, the other, invokeTestsJSON.xml, I think exists in both streams, but is typically identical. The "master" version of changes: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=900ab926eaaa9282ea7e462c9786ffe0449af1da cherry-picked to R4_5_maintenance as commit 5249c6943328ac4f46d3191427668054b9b5e163 = = = = = = I suspect there are other things to do, as well. For example, I *think* that the cvstests have, in the past, had to have their test repo directly on Hudson instance and slaves? In this case, as I understand it, the Mac and Windows "slaves" are the same box. Perhaps we'll be lucky and Linux repos were on build machine in /shared/eclipse directory? Also, we do need direct access to /shared/eclipse ... I am assuming that's true here, since is for HIPP instances (but, didn't ask, yet). (We need that for one slave only, technically ... it plays a role in how we "collect results". = = = = = = I have not examined the actual Hudson jobs. There might be some hidden assumptions in there about "where they are running" (I don't think so ... just saying, something about them may need to be tweaked.) = = = = = = = A different bug, but, I will include here, in some of the new "4.6" jobs, I had forgotten to add "releng group" to the security matrix, so just as well fix that, while I'm looking at them. = = = = = = = =
Just to be safe, I saved all "old config" files in /eclipse.platform.releng.aggregator/production/configs/oldShardHudsonConfigs
(In reply to David Williams from comment #2) > Starting Friday night's N-build slightly late, to get in initial fix. > Seemed to run fine. I did have to add "genie.shared" to ACL list of /shared/eclipse/sdk/testjobdata as that is the directory written to, by Hudson, once a test run is complete. (And that file contains 6 or so data points that allow us to "pull" the results from Hudson for further processing and summarizing.) > = = = = = = > I suspect there are other things to do, as well. For example, I *think* that > the cvstests have, in the past, had to have their test repo directly on > Hudson instance and slaves? In this case, as I understand it, the Mac and > Windows "slaves" are the same box. Perhaps we'll be lucky and Linux repos > were on build machine in /shared/eclipse directory? > Turned out to be non-issue, since the "same slaves" are used. > = = = = = = > > I have not examined the actual Hudson jobs. There might be some hidden > assumptions in there about "where they are running" (I don't think so ... > just saying, something about them may need to be tweaked.) Could not find anything that needed to be tweaked, and N-builds seemed to run fine. There were a few errors in Windows tests, but appeared to be the "ransom" errors we see occasionally .... nothing related to Hudson. > = = = = = = = > > A different bug, but, I will include here, in some of the new "4.6" jobs, I > had forgotten to add "releng group" to the security matrix, so just as well > fix that, while I'm looking at them. > I did fix security settings. (Let me know if I missed any). Did find that on new instance, you need to use committer email, instead of committer id, to "sign on".
I am trying to re-run the Windows tests, but, that is primarily to test the "rebuild" plugin. See bug 4129333 ... somehow I was allowed to install it, AND to restart the shared instance. Not sure if that is "just me" .... or, if security on the whole instance has not been tightened down yet? On new instance, I did delete some "old jobs" no longer needed ... such as for "4.4 M-builds" and "4.5 I-builds". I plan to go ahead and delete all ep jobs on "old instance" just for clarity and simplicity. I also added a static link to the shared instance of Hudson, where the tests are done. <p>The unit tests are run on the <a href="https://hudson.eclipse.org/shared/view/Eclipse%20and%20Equinox/">shared Hudson instance</a>.</p> It is not as useful as putting in the specific "job" that produced the results, but is a step in the right direction, that is easy to do, and at least helps committers "get close" to the right place.
(In reply to David Williams from comment #5) > I also added a static link to the shared instance of Hudson, where the tests > are done. > > <p>The unit tests are run on the <a > href="https://hudson.eclipse.org/shared/view/Eclipse%20and%20Equinox/ > ">shared Hudson instance</a>.</p> To be clear, this should show up for the first time on the 8/8/2015 nightly build. I will also announce the new Hudson instance URL on platform-releng-dev.
