Difference between revisions of "RedTinderboxStatusInEIS"

From Apache OpenOffice Wiki
Jump to: navigation, search
(What to do if you need immediate results: the buildbot does send the build information to the tinderbox)
Line 86: Line 86:
 
=== What to do if you need immediate results ===
 
=== 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.
 
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.
+
The [[buildbot]] will send the results to [[tinderbox]] when the build is complete.

Revision as of 15:02, 8 September 2007


Policy

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.

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:

  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.

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.

buildbots now also send their results to tinderbox. With this feature becoming available you can now request a new build on a buildbot to have the tinderbox status being updated.


QA Guidelines

If the tinderbox status is red first check if there is a comment from Development why it might be ignored, eg. the problem was already on the Masterworkspace

If there is no DEV comment write a comment to development to please have a look at tinderbox into the CWS and set state back to new.

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.


Development Guidelines

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 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 with:
    Fetching dependencies for module <new module> from solver... failed...
  • 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.
  • failed to create localedata
    If you see the following error (not necessarily with the same file, but while creating localedata), and you didn't touch anything in that area, then it is not your fault. This error is rarely seen, and is not reproducible at all. Blame it to the solar wind.
    dmake:  Error code 132, while making ´../../../unxmacxp.pro/misc/localedata_en_NA.cxx´

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. The buildbot will send the results to tinderbox when the build is complete.

Personal tools