Overview#

The purpose of tinderbox is to proactively catch checkins that break the build or cause regression failures. This is accomplished by setting up a tinderbox machine that performs automated nightly builds and regression runs.

This is considered to be a critical success factor for the Trinity project.

Objective#

• Run daily builds (as defined below) and kernel regressions of binaries. Regression runs are estimated to take 8 hours to run to completion.
• Daily regressions will be turned off on Friday, Saturday, and Sunday to allow the regular weekend regressions to run.
• PRs will be raised for any build failures (Stephane).
• PRs will be raised for any regression failures (Kirk)
• PR owners will be hounded until they are resolved. (Steve)
• Past sandboxes will be kept if it can be done in a low maintenance way (automation). These will be used for debugging. Keep one or two. If keeping two, automate in a way that one good one is kept and not two broken ones. Save in a useful format such as a file or ISO. Source will be kept but if RCS Ids are implemented then it is not necessary to keep the source.
• Builds will be promoted to the dog food directories with access to developers via qnet.
• Successful builds will be pushed to developers to use as dog food. (Sebastien)
• A Trinity cvs checkout and build algorithm needs to be defined (Sebastien)
• Provide instructions for non-qnx6 hosted developers can use nfs,etc to use the trinity dog food area (Sebastien)

There will be three seperate tinder box projects:

1. Trinity compile with x86 kernel regression run
2. Full Head branch compile only
3. Full release branch compile using the Trinity libs/headers

The following dog food directories will be setup for tester/developer use:

1. Trinity files only, not a full release
2. Trinity on top of SP2
3. Trinity on top of SP1 (lower priority and may decide to drop if not achievable)