Opened 9 years ago

Last modified 9 years ago

#5279 new defect

Build process

Reported by: cscott Owned by: cscott
Priority: high Milestone: 8.2.0 (was Update.2)
Component: distro Version: Development build as of this date
Keywords: test-suite Cc: mstone, dgilmore, kimquirk, jg, marco
Blocked By: Blocking:
Deployments affected: Action Needed:
Verified: no


OLPC builds should have the following stages:

1) Repository collection.
Both koji and joyride-related repositories should be collected into a git archive. By building from git instead of directly from koji, we both speed up our builds (by hosting the files locally) and insulate ourselves from koji/connectivity failures which would otherwise interrupt our builds. We also ensure that the full set of bits (source and binary) which make up our builds are archived locally and permanently accessible. The separate collection step also allows us to side-step koji in the rare cases where it is necessary, and to provide better repository commit messages in the run-up to a stable release.

1b) Joyride collection should include rebuilding SRPMs in an appropriate mock chroot, to ensure that our binaries match our sources and that binary incompatibilies don't sneak in.

2) Package composition (aka "the build", aka "pilgrim").
Composition takes place with yum targetted at the collected repositories.

3) Automated build testing. (aka, "tinderbox")
After each build, an automated test suite is run which (a) protects against regressions, (b) ensures that the build was "correct" (ie, pilgrim didn't fail), and (c) to the greatest extent possible, ensures that all released builds, even development builds, are at least dogfood quality.

3b) Reversion/promotion.
At some future point, automated reverts of the package collection might occur if new builds fail the automated test suite. Alternatively, we can automatically graduate packages from 'development' to 'testing' if a certain period has passed without a blocking bug filed against the package. (This latter plan requires greater integration of our build system and bug database.)

4) Installation.
Builds which pass the automated tests are installed to the appropriate directory on (see trac #5038 and #1813). Builds which don't pass automated tests might be made available in some appropriate "unofficial" spot to aid correction of the failures, but this spot should not be visible to the general public. Installation may also involve updating the database so that (for example) the 'joyride' stream always points to the latest joyride build.

This trac item will be a meta bug for:

a) discussion of this process,
b) creating appropriate wiki pages documenting the process in detail,
c) referencing specific trac items for the various work required to fully implement this system, and reporting on progress.

Change History (3)

comment:1 Changed 9 years ago by marco

  • Cc marco added

comment:2 Changed 9 years ago by skierpage

Dear cscott, I also noticed that

a) says "check the _Tinderbox_", but is months out-of-date.

b) has more recent tinderbox info but still says

Latest build 443
Latest stable build 406

c) has a [automated test results] link that's a broken link.

You undoubtedly know about these, I wasn't sure whether to open a new bug for "Tinderbox paperwork".

comment:3 Changed 9 years ago by cscott

I've asked sugarlabs for help with this.

Note: See TracTickets for help on using tickets.