On Fri, May 2, 2008 at 12:02 AM, Joachim Steiger <<a href="mailto:roh@openmoko.org">roh@openmoko.org</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Bobby Martin wrote:<br>
><br>
><br>
> On Thu, May 1, 2008 at 11:50 AM, Thomas Wood <<a href="mailto:thomas@openedhand.com">thomas@openedhand.com</a><br>
</div><div class="Ih2E3d">> <mailto:<a href="mailto:thomas@openedhand.com">thomas@openedhand.com</a>>> wrote:<br>
><br>
> Well, there is <a href="http://buildhost.openmoko.org" target="_blank">buildhost.openmoko.org</a><br>
</div>> <<a href="http://buildhost.openmoko.org" target="_blank">http://buildhost.openmoko.org</a>> which builds images nightly. I've<br>
<div class="Ih2E3d">> been asking for the toolchain to be fixed and updated and I believe<br>
> Julian has this on his TODO list.<br>
><br>
> Regards,<br>
><br>
> Thomas<br>
><br>
><br>
> Thanks for pointing that out.<br>
><br>
> Does it apply a label to builds that succeed? Is there documentation of<br>
> what this hypothetical label might be, and also documentation of the<br>
> build process that <a href="http://buildhost.openmoko.org" target="_blank">buildhost.openmoko.org</a><br>
</div>> <<a href="http://buildhost.openmoko.org" target="_blank">http://buildhost.openmoko.org</a>> uses?<br>
<div class="Ih2E3d">><br>
> (Hrm, reading over that, it looks like I'm trying to be sarcastic with<br>
> the thanks. I'm definitely not! The thanks, and the questions, are<br>
> real, not rhetorical.)<br><br>
</div>i do not really get what you mean by labels.<br>
when buildhost successfully finished a build there is a new image.<br>
else, there is not.<br>
if it cannot compile all dependencies then it logically cannot package it.<br>
<br>
i think i know what you really want in the end.<br>
a full CI representation of what buildhost does build and what not.<br>
<br>
i have found <a href="http://bitten.edgewall.org/" target="_blank">http://bitten.edgewall.org/</a> recently and since we are<br>
currently in the process of moving to trac it is very interesting for me.<br>
<br>
whats missing is the glue between that and the openembedded build system.<br>
and to make it really usefull at all we would need unit tests for all<br>
'packages', not only a 'built something' 'did report exit=!0'<br>
<br>
yes i want that. but let us finish work on getting trac first please ;)<br>
<br>
if you know your way around trac, python and OE i am happy about<br>
everyone who can help me there.</blockquote><div><br>What I mean by a label (sometimes called a tag) is that your build process uses<br>your revision control systems' commands to apply a label to all files before the<br>
build process starts. In svn, you use the svn copy command to tag files, like so:<br><pre class="screen">svn copy file:///tmp/repos/test/trunk file:///tmp/repos/test/tags/building -m "tag tree"</pre> </div></div>
(see <a href="http://svnbook.red-bean.com/en/1.1/re07.html">http://svnbook.red-bean.com/en/1.1/re07.html</a>)<br clear="all"><br>Unfortunately, I think OM uses three different repositories (svn, git, mtn) so you would<br>
issue at least three different commands to apply the label. Then when you're done with<br>the build, you would relabel it with a build-successful tag, e.g.:<br><pre class="screen">svn copy file:///tmp/repos/test/tags/building file:///tmp/repos/test/tags/build-success-2008-05-02-13-47 -m "tag tree"</pre>
(If the build happened at 13:47 on 2008/05/02)<br><br>Then you run your tests and relabel with test-success-2008-05-02-13-47 if those pass. When<br>the build is done, you delete the building tag so you can re-use it for the next build.<br>
<br>You probably also want to tag those same files with build-success-latest and test-success-latest.<br>That way people can pull that label from the repository and know what to expect. You can also<br>look at the labels and see when good builds happened and when things broke.<br>
<br>A good CI system will also email some set list of people when the build is bad with the files that<br>changed since the last good build (this set ideally including the list of people who checked<br>those files in) so the build tends to get fixed quickly.<br>
<br>Being able to retrieve the build products from good builds is obviously very important,<br>but it's not necessarily very helpful for people doing development work. For them,<br>being able to get the very latest code from the project they're working on, and the<br>
latest "good" code from all projects it depends on, is typically what they want.<br><br>I have used trac a bit, but probably not enough to be helpful without studying up on it.<br>I wasn't aware it provided much Continuous Integration support. I will do some research<br>
on it.<br><br>Thanks!<br>Bobby<br><br>-- <br>If it doesn't make you smile, you're doing something wrong.