Difference between revisions of "RedTinderboxStatusInEIS"

From Apache OpenOffice Wiki
Jump to: navigation, search
m
m (added tinderbox category)
Line 1: Line 1:
 
[[Category:Quality Assurance]]
 
[[Category:Quality Assurance]]
 +
[[Category:Tinderbox]]
  
 
Since some time [[EIS]] now has a status overview about [[tinderbox]] builds on [[CWS | ChildWorkspaces]].
 
Since some time [[EIS]] now has a status overview about [[tinderbox]] builds on [[CWS | ChildWorkspaces]].

Revision as of 11:32, 16 May 2007


Since some time EIS now has a status overview about tinderbox builds on ChildWorkspaces. The tinderbox status messages are available on the main CWS overview pages.

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.

Here's a short list what can be done to get more information about such tinderbox build breakers:

  1. 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.
  2. 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.
  3. You are now at the tinderbox overview page for that ChildWorkspace. There is a table with build dates as rows and platform as columns.
  4. 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.
  5. 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 dev@porting.openoffice.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.

Note that there is currently no possiblity to manually trigger a rebuild of tinderbox, but 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.

In the future it is planned that buildbots will send their results also to tinderbox. When this feature will become available you can request a new build on a buildbot to have the tinderbox status being updated.

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 general, these are the circumstances that can cause an invalid result:

  • a new module was added to the cws
    since the new module is not included in the module list, it is not checked out from cvs and the build will most likely fail
  • anoncvs is out of date or not reachable
    obvious failure when anoncvs is not reachable, slightly more difficult to detect when it is out-of date
    The status page will show commits in the column next to the dates. When the build started shortly after the last commit (or when your last changes are not listed at all), anoncvs might not be up-to-date. Carefully check the logs whether ther breaker occurs in an area you touched with that last commit
  • 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.

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.

Common Errors

  • 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)

What to do if you need immediate results

If you can't wait until your cws is rescheduled by the tinderbox, you can use buildbot to start a build. While the buildbot sends results to tinderbox feature is not yet available you can as a developer of course start a buildbot build and just communicate with QA (eg via CWS comments) showing them a successful build on buildbot to prove that there currently is no real problem building on a special platform or no problem anymore after you did a fix.

Personal tools