Request for stable, automated build process

Joachim Steiger roh at
Fri May 2 16:16:18 CEST 2008

Bobby Martin wrote:
> What I mean by a label (sometimes called a tag) is that your build
> process uses
> your revision control systems' commands to apply a label to all files
> before the
> build process starts.  In svn, you use the svn copy command to tag
> files, like so:
> svn copy file:///tmp/repos/test/trunk file:///tmp/repos/test/tags/building -m "tag tree"
> (see
> Unfortunately, I think OM uses three different repositories (svn, git,
> mtn) so you would
> issue at least three different commands to apply the label.  Then when
> you're done with
> the build, you would relabel it with a build-successful tag, e.g.:
> svn copy file:///tmp/repos/test/tags/building file:///tmp/repos/test/tags/build-success-2008-05-02-13-47 -m "tag tree"
> (If the build happened at 13:47 on 2008/05/02)
> Then you run your tests and relabel with test-success-2008-05-02-13-47
> if those pass.  When
> the build is done, you delete the building tag so you can re-use it for
> the next build.
> You probably also want to tag those same files with build-success-latest
> and test-success-latest.
> That way people can pull that label from the repository and know what to
> expect.  You can also
> look at the labels and see when good builds happened and when things broke.

sounds nice, but i think due to the reasons you named it makes only very
limited sense to tag it in any repo. (besides that buildhost shouldnt
have write access. its executing scripts which 3rd partys released as
software packages so its not on my 'trusted' list)
after all we are building a complete distribution here, not only one
software project which would be clearly contained and propably only in
one repo.
also we use loads of upstream stuff from different svn, cvs, git repos
as well as tarballs via http or ftp.
in addition to that these are cached and again exported by the buildhost.

> A good CI system will also email some set list of people when the build
> is bad with the files that
> changed since the last good build (this set ideally including the list
> of people who checked
> those files in) so the build tends to get fixed quickly.

yeah. thats what i would like to have.

> Being able to retrieve the build products from good builds is obviously
> very important,
> but it's not necessarily very helpful for people doing development
> work.  For them,
> being able to get the very latest code from the project they're working
> on, and the
> latest "good" code from all projects it depends on, is typically what
> they want.

for that we manually cherry pick known to be usable builds after kevin
dean tested these.
they are at

> I have used trac a bit, but probably not enough to be helpful without
> studying up on it.
> I wasn't aware it provided much Continuous Integration support.  I will
> do some research
> on it.

nice. its a plugin into trac, not a base feature, but thats how it
works. very simple skeleton with basic features, the rest is a plugin

> Thanks!
> Bobby

btw: we still want to hire a web_developer_ (needs to know python i say);)


Joachim Steiger
developer relations/support

More information about the community mailing list