Request for stable, automated build process

[Bobby Martin]

On Fri, May 2, 2008 at 12:02 AM, Joachim Steiger <roh at openmoko.org> wrote:

> Bobby Martin wrote:
> >
> >
> > On Thu, May 1, 2008 at 11:50 AM, Thomas Wood <thomas at openedhand.com
> > <mailto:thomas at openedhand.com>> wrote:
> >
> >     Well, there is buildhost.openmoko.org
> >     <http://buildhost.openmoko.org> which builds images nightly. I've
> >     been asking for the toolchain to be fixed and updated and I believe
> >     Julian has this on his TODO list.
> >
> >     Regards,
> >
> >     Thomas
> >
> >
> > Thanks for pointing that out.
> >
> > Does it apply a label to builds that succeed?  Is there documentation of
> > what this hypothetical label might be, and also documentation of the
> > build process that buildhost.openmoko.org
> > <http://buildhost.openmoko.org> uses?
> >
> > (Hrm, reading over that, it looks like I'm trying to be sarcastic with
> > the thanks.  I'm definitely not!  The thanks, and the questions, are
> > real, not rhetorical.)
>
> i do not really get what you mean by labels.
> when buildhost successfully finished a build there is a new image.
> else, there is not.
> if it cannot compile all dependencies then it logically cannot package it.
>
> i think i know what you really want in the end.
> a full CI representation of what buildhost does build and what not.
>
> i have found http://bitten.edgewall.org/ recently and since we are
> currently in the process of moving to trac it is very interesting for me.
>
> whats missing is the glue between that and the openembedded build system.
> and to make it really usefull at all we would need unit tests for all
> 'packages', not only a 'built something' 'did report exit=!0'
>
> yes i want that. but let us finish work on getting trac first please ;)
>
> if you know your way around trac, python and OE i am happy about
> everyone who can help me there.


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 http://svnbook.red-bean.com/en/1.1/re07.html)

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.

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.

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.

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.

Thanks!
Bobby

-- 
If it doesn't make you smile, you're doing something wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/openmoko-devel/attachments/20080502/6db849bf/attachment.htm