On Fri, May 2, 2008 at 12:02 AM, Joachim Steiger <[EMAIL PROTECTED]> wrote:
> Bobby Martin wrote: > > > > > > On Thu, May 1, 2008 at 11:50 AM, Thomas Wood <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> 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.