Community
Participate
Working Groups
While working on bug 395777, some notable improvements are needed on "basebuilder" handling. (And these are true if literally using basebuilder, or our eventual sdk based builder). Wanted to note them before I forgot. 1) during the final "generate test indexes" phase, we use the same one that we used during the "build phase". This is correct 99% of the time, but is bound to fail eventually, such if we rapidly started a new build with potentially a different tagged version of base builder, they would "step on" on other ... (and this could happen even if using same version, since one could be removing it, right after the other checked it out) ... so, the "generate test indexes" phase should use its own copy, based on its own tag. 2) We currently use a shell script to get basebuilder during a build, and ant task during tests -- essentially duplicating code/function. The ant task is simple enough it should be executable anywhere, so just as well use that everywhere, so we have just one way to do it. 3) We do not "fail" if we can not chmod (not even sure you can with ant?) but then also do not explicitly return fail code later if found that we can not execute eclipse. Just as well, to make it obvious where things are not working as expected.
I noticed in our masterBuild.sh script, we first get the basebuilder, then get eclipseBuilder. For us to use an XML file (any script) from eclipsebuilder to get the basebuilder, then eclispebuilder will have to come first. From inspection, I'm relatively sure the order can be reversed without impact, but will try simply reversing that order first, and confirm that works ok (using existing scripts otherwise).
*** Bug 399274 has been marked as a duplicate of this bug. ***
I'm going to count this as fixed for M6. (It was fixed in pieces, all along). The fix is accomplished by two things. First, we keep track of the "ebuilder" used and the "base builder" used during the build in buildproperties.* file, so we can always retrieve the exact version if/when needed, if not already present. The second part is that when we use it for things like "processing test results", we put a copy directly in the build's "drop directory" on the build server and use that. (So, for one example, then the next test finishes, maybe hours later, we already have a "safe" version there, specific to that build, we can re-use and don't have to re-fetch. The one caveat, that should not be required often, there are "tricks" that can be done so a fix made "after the fact", in master, but then it must be remembered to remove any existing copies and replace the specific version SHA hash with 'master' to fetch a new copy with the fix.
Oh, another other caveat, we must remember when actually promoting the "drop" to exclude those directories, in order not to make DL site larger then it has to be with "build only" items. Easy to do with rsync such as the following: rsync -r --exclude="*org.eclipse.releng.basebuilder*" --exclude="*eclipse.platform.releng.aggregator*" ${DL_DROP_ID} /home/data/httpd/download.eclipse.org/eclipse/downloads/drops4/
While working on some other bugs, I've seen places where we still use scripts from "tychobuilder" project during publish, that is "tychobuilder" directly under the aggregator version under gitCache ... to be safe, we should make our copy top "pulishing directory" and use the scripts from there, instead.
We now use common scripts, and one copy, all resulting in "safe copies", directly in the build machine's drop location ... the one specific for that build ... so is working well ... and very comforting to know I can start a test build or something while an N build is taking place. Or ... go back hours later to "rerun" part of the publish process, and worry about other changes made.
fixed as described.
mass change to 'verified', as these bugs are either routine or obviously fixed build breaks.
