Jump to: navigation, search

Difference between revisions of "Platform-releng/How to do miscellaneous releng tasks"

(misc documentation)
(No difference)

Revision as of 14:14, 11 September 2012

There are times when some quirky thing out of the ordinary has to be done. This page captures some of them. They are likely easily to get out of date or details change from case to case, but ... thought they'd serve as "hints" in case others have to ever do these things (and serve as reminders to me :). They are likely too quirky to be part of a FAQ, but can be evolved to that and/or a more formal "procedures document". Thought I'd try to capture them every time I do one, so it is not near exhaustive. (Note, these pretty much all require shell access ... so ... not of use to most committers).

How to restart Hudson tests

Technically, could restart Hudson tests directly from Hudson web interface, but, the result would stay there, and not be automatically integrated with our build pages. Here's the procedure to start them in the same manner we do after a build, so the results "come back" to us and integrated with the build's download page.

This example is specific for a Kepler I-build, but idea would be same for others. It assumes the build is complete, and on "downloads" and this is just to run the tests on Hudson, and "wait" until tests are done, and once done, run some summary programs and re-generate DL pages with the new data.

The key is files in

/shared/eclipse/eclipse4I/build/supportDir/org.eclipse.releng.eclipsebuilder/testScripts

To do the retest a file named startTests.sh is executed from command line.

But, this file needs two parameters, the buildId to test, and the eclipseStream that the build is from. You could edit the sh file directly, but best is to edit a file named buildParams.shsource. The contents of that file, for a Kepler re-test, would be something like

buildId=I20120911-1000
eclipseStream=4.3.0

Then, then startTests.sh is executed, it will read the values from that file.

(I think startTests.sh should be ran from screen shell, or otherwise allowed to continue running even if you logoff or lose connection.)