Critical is when the color in those status messages is red for one of the platforms, because this indicates that the build broke on that platform.
Child workspaces with a red tinderbox status in EIS need a justification when
promoted to "ready for QA" state !
Here's a short list what can be done to get more information about such tinderbox build breakers:
- Go to the CWS Overview page in EIS and look at the tinderbox status
The only thing of interest is when the color is red somewhere, which indicates that the build broke on that platform.
- On that EIS page there is a link below the headline "Tinderbox" with a text like "<cwsname> is open as of <date>". Click on that link.
- You are now at the tinderbox overview page for that ChildWorkspace. There is a table with build dates as rows and platform as columns.
- If there have been build breakers or if the build output contained warnings there will be a colored cell at that build-date/platform combination. Inside that cell there is the letter "L" with a Link. Click on that link.
- If you don't see the cell you're looking for, try to increase the displayed timeframe (links right above the legend) and start over with the above step.
- A popup box is now opening containing the links "View Summary Log" and "View full Log". Usually the Summary log will be enough (and actually the easiest way) to tell where the problem is.
The "Summary Log" (or brief log) is just an excerpt of the buildlog that only includes lines that look like an error to the logparser and some surrounding lines. In case the context of the summary log is not enough, you can choose the full log (the brief log offers a link to the full log and vice versa).
If you are the owner of the CWS and can't fix the problem yourself (eg. because it is system specific and you do not have acesss to that platform) an alternative is to seek help from porters of that platform. You can use either use the firstname.lastname@example.org mailinglist or ask around on IRC ( server: irc.freenode.net channel: #dev.openoffice.org ) - some OpenOffice.org porters are usually around on that IRC channel.
tinderbox will automatically put the CWS back into it's queue of to be build things when it detects that there have been CVS commits on a ChildWorkspace. Thus a CVS commit (which you'd surely would have to do anyway when you fixed something) effectively forces a new build.
Exception: if there is a global outage with anoncvs or similar infrastructure problem announced and you are aware of that tinderbox status can be ignored. Please provide a short comment in the CWS about the outage in this case before nomination or approval.
If you get the CWS back from development with a comment that it´s a false positive go on and approve or nominate the CWS. If you get the CWS back from development with a fix and a comment that that fix did build OK on buildbot go on and approve or nominate the CWS. If you get the CWS back from development without such comment tinderbox status should now no longer be red or else we have a fixed but failed issue.
If the tinderbox status is red and you believe that your CWS should be in a buildable state have a look at the buildlog in tinderbox. Instructions for how to find and analyse the buildlog and handle the red status can be found via the help bubble in EIS beneath the tinderbox headline. Prior to looking at the buildlog you might want to check if there may be a problem inherited from the current milestone your CWS is based on. Use the EIS Menu "Masterworkspace / Tinderbox status" to check tinderbox status of milestones. Note that the treeview shown there only shows the last recent milestones for older milestones you can assume that the milestone build was OK by now.
If it´s a real build breaker try to fix problem or try to find assistance for fixing problem. After you did commit your fix to CVS tinderbox will automatically requeue the CWS for a new test build. You can also start a build on buildbot immediately after fixing for proving that the build is now OK.
If you find out that it´s a false positive (see below) or that the build breaker is already on the MasterWorkspace write a comment into the CWS and send it back to QA.
The policy allows the Developer to just write a comment for the CWS in EIS that tinderbox red status can be ignored because his/her analysis of the tinderbox log file reveled <whatever_problem_there_was_unrelated_to_code_change> if this is the case.
Developer can contact the tinderbox maintainer to requeue a build for that CWS the maintainer can be found on top of the buildlog page or just start a build on buildbot to have an update of the tinderbox status in EIS.
False positives (or when it is OK to ignore a red status)
A red status can sometimes also have other causes than actual bugs it's possible that there is a build breaker because of missing modules, something being tagged wrong on anoncvs etc.
In any case you see a breaker not listed here, and is not caused by your cws, notify the tinderbox admins about it!
In general, these are the circumstances that can cause an invalid result:
- source cannot be checked out/build doesn't start at all.
- obvious failure when sourcecode repository is not reachable. (Just try again later and reenqueue your build).
- slave refuses to build because the cws is not listed in the taglist. Probably the cws is set to private or maybe already integrated. After setting to public, wait approx 10 minutes to allow refreshing of the taglist
- problems with the buildslave itself
- while unfortunate, the buildslaves might experience hardware problems or just run out of diskspace or similar. Please notify the TinderAdmin (listed on top of the buildlog) of the buildslave in that case.
- sometimes building python included in OOo's sources fails with
./libpython2.6.so: undefined reference to `_PyParser_Grammar´
- in that case just reenqueue the build - apparently it is a parallel build issue. (just reenqueue)
All those false errors should be fairly easy to detect by looking at the summary log of a build. If in doubt or when you suspect a parallel build problem or similar, feel free to contact the TinderAdmin of the buildslave.
- There is a compiler specific problem
- A system header file is not found where expected on different platform
- configure.in or setsoenv.in was updated, but configure was not regenerated
- when configure is not updated, the build might fail right at the beginning, or if it introduces new environment variables, might not yield the expected result. Please always regenerate configure in your cws (just run autoconf for this)