[Buildbot-devel] Serial numbering of builds

A.T.Hofkamp a.t.hofkamp at tue.nl
Thu May 18 09:43:35 UTC 2006


John Pye wrote:
> Strikes me as a waste of effort. After all, Buildbot clearly does know
> the revision number: it shows it in its log pages. So it should be
> possible to incorporate it into the build somehow, right, without
> messing around with temporary files etc?

To some extent, yes.

The question you may want to ask yourself is 'do I want to move knowledge of 
how to build my software into buildbot?'. This becomes quite important if your 
way of building software changes, since the only person that can fix it then 
is the buildmaster.

The buildbot developers (and I tend to agree with them) are quite nervous 
about this potential problem.

So it may look like that it is much easier to have buildbot fill in a magic 
number, in the long run it may be better to make such magic part of the 
software project, so you can put it in the repository, and maintain it as part 
of the project rather than as part of buildbot maintenance.



On the other hand, maybe I am too strict here, and it is feasible to have a 
developer fill in a magic number by hand if buildbot is not around for some 
reason.

One of the reasons why I chose to create a file is that I run a seperate 
program before the actual build that decides what needs to be rebuild. Also, 
the install+test gets done somewhere else and for that I need similar 
information. I write all that information into the file as well, so
1) I can do incremental builds at another machine
2) I have a file for each revision that states what tools exist (with what 
revision).

An example file:
<?xml version='1.0'?>

<revision id='796'>
   <creation-date>2006-04-26T09:33:52Z</creation-date>
   <package name='chi-chi2dast'>
     <last-modify id='795'/><selected id='796'/></package>
   <package name='chi-dast2dast'>
     <last-modify id='786'/><selected id='787'/></package>
   <package name='chi-dast2pml'>
     <last-modify id='786'/><selected id='787'/></package>
   <package name='chi-dastchecker'>
     <last-modify id='786'/><selected id='787'/></package>
   <package name='chi-dast2c'>
     <last-modify id='786'/><selected id='787'/></package>
   <package name='chi-dast2mcrl'>
     <last-modify id='786'/><selected id='787'/></package>
   <package name='chi-dast2py'>
     <last-modify id='786'/><selected id='787'/></package>
   <precious/>
</revision>

This is the file for revision 796; it has a creation date, and for each chi-* 
tool, it knows when the last change has occurred (ie all revisions between 786 
and 796 for chi-dast2pml are the same). It also scans the collection of 
*.tar.gz files, and found that the latest number I have is 787. Thus there is 
no need to build this tool again for revision 796.

I use such files for installing revisions, and for carrying usage information 
of the *.tar.gz files around. Also, I can generate a web-page of available 
revisions if I like.

This may be overkill for your application, but I find it quite convenient to 
have the computer handle all these revision-number management details.

> I am sure that you could use subversion 'properties' to access the name
> of the current branch...? Then, only make a build if you're in a
> particular branch, perhaps.

Eh, nice idea, why didn't I think of that?
Adding a branch name would make it all uniq. Tnx for the suggestion.


Albert




More information about the devel mailing list