Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #364151 +++ <quote> B. This would be a good place to improve scripts so if it fails to fetch the pre-req, the build fails immediately with a clear message it failed to fetch the pre-req. As it is, the fetch fails, but the script plods along, and fails later with some unhelpful messages. </quote> Technically a feature request, maybe, but practically, since the build doesn't fail when a required pre-req is not found, it is hard to see why the build failed, so also sort of a bug. In the dependency scripts should add a property that says "required" (true|false) and if true, and if the "fetch" fails, then set a "fail flag" and explicitly fail at the next good opportunity. I say "next opportunity" since its often best to return to main script, let it do some cleanup and save log and then <fail>.
I've improved the main scripts so that a) it will detect common reasons to declare the build "failed early", b) capture it, and c) make the the log gets pushed to "download page" so it will be easy for all committers to see. Some cases that'd be most helpful, are that it will detect things like cvs aborting a checkout "because tag abc was not found", which might mean the map file has the wrong tag .... or, that where was a temporary network problem. In these cases the full log is still "captured" and put on download page, so it'll be easier for everyone to read, without waiting for build master to snag a copy. I've tested locally, but now I can't wait for the next person to break a build, to see if it works as expected on build.eclipse.org. I may break a few myself, just to see :)
I'm going to try some explicit "fail" cases, to make sure this works on build.eclipse.org (that is, that I correctly "merged" the fixes from test branch back into main stream, and deployed them, etc.). I'll do mostly on I-build, but probably do one on M builds too). The test cases I'll try are to 1. put a typo in "prereq" eclipse version so it can not be fetched. 2. put a typo in map file so some bundle version can not be found. 3. revert some changes in map file, so the "com.thoughtworks.xstream" will have "unresolved required prereqs".
Testing is finished. Discovered a one problem I forgot (forgot to update releng control directory so "artifacts directory" completely defined) also noticed and "enhancement" could be made in summary page ... by default got a question mark if build failed, but easy to fix that so it gets a red X. I've restarted build in both I and M branches to make sure I've restore all to be error free.
Quirk 1: In normal logs (when no reason is found to fail the build early) there will be some messages that might appear to indicate something is wrong ... messages something like Result: 1Result: 1 Result: 1 Result: 1 Result: 1 The reason for this is because we use <exec grep in order to search for the strings in the log file that indicate some failure, and grep returns '1' if nothing is found (instead of '0'). So, ant exec logs it as "not returning normally". I've not found a way around this. The reason we use "<exec grep" instead of the ant task "<resourcecontains" is that the latter has been found to read in entire file at once, before searching for the string to match. With our sometimes huge log files, this can cause an "out of memory" error in our java process. Granted, we _might_ be able to increase our heap memory enough to accommodate it, it just doesn't seem like a good idea as there would always be some risk the log would get larger, and eventually cause "out of memory" again. Ideally, someone someday could write our own version of "resourcecontains" that used a buffer and just searched the buffer for matches (but, that is not trivial so I can see why Ant took the easy way out :) ]. So, for now, we'll need to get used to the "Result: 1" messages and know that's a good thing in this case, not an indication of an error.
Quirk 2: if required bundle prereqs can not be found, all of the prereqs not found are listed, even if many of them are optional. This is confusing, but easy enough to fix by looking at the bundle (and error messages) in eclipse IDE. As far as I know this is a PDE Build quirk and out of our control. If anyone knows otherwise, let me know. As a recent example, the failed log might say [orbit-set1] Unsatisfied import package net.sf.cglib.proxy_[2.2.0,3.0.0). [orbit-set1] Unsatisfied import package nu.xom_[1.1.0,2.0.0). [orbit-set1] Unsatisfied import package org.codehaus.jettison_[1.0.1,2.0.0). [orbit-set1] Unsatisfied import package org.codehaus.jettison.mapped_[1.0.1,2.0.0). [orbit-set1] Unsatisfied import package org.dom4j_[1.6.1,2.0.0). [orbit-set1] Unsatisfied import package org.dom4j.io_[1.6.1,2.0.0). [orbit-set1] Unsatisfied import package org.dom4j.tree_[1.6.1,2.0.0). [orbit-set1] Unsatisfied import package org.joda.time_[1.6.0,2.0.0). [orbit-set1] Unsatisfied import package org.joda.time.format_[1.6.0,2.0.0). [orbit-set1] Unsatisfied import package org.xmlpull.mxp1_[1.1.4,2.0.0). [orbit-set1] Unsatisfied import package org.xmlpull.v1_[1.1.4,2.0.0). even though only xmlpull (at 1.1.3 version level) is the only _required_ packages. The others do not exist either, but are tagged as optional. So, I'm assuming just a limitation of PDE Build that its not more exact about what exactly is unsatisfied and required. Just wanted to document what I've noticed while working on these build improvements.
