[Buildbot-devel] copying information between steps or schedulers

[Stefan Seefeld]

A.T.Hofkamp wrote:

> This may not even be good enough. I'd really like to optimize this 
> further and build only those tar.gz files that have actually changed 
> between repository revisions. Some builds take a long time, and I do not 
> want to do them if it can be avoided.

While I agree, I'm not sure I understand how this relates to the buildbot.
Build systems track dependencies precisely so they can determine what
needs to be redone after an update. And this is why buildbot supports
'update', not just 'checkout'.

> To optimize, I need knowledge of what tar.gz files are already installed 
> at the various slaves, which kind of boils down to having to know which 
> other tar.gz files exist (at the 3 slaves).

(Note that you keep referring to slaves, not builders, which I think is
not quite accurate, as you could host multiple builders on a single slave.)

Right, the build directory used by a builder is (or at least can be)
preserved between builds. Thus there is no need to rebuild things that
are still up-to-date.

> In other words, I would need history of builds done in the past which 
> have not yet been deleted.

Right.

[...]

> There is another reason why I hesitate to query the repository for its 
> revision.
> With a hook in SVN you can trigger buildbot into starting the build. At 
> that point, there is revision information available, which, ideally, 
> should be transferred to the steps so it is certain that you build what 
> buildbot asks.

but the revision *is* available to the builder: the SVN step uses it !
See http://buildbot.sourceforge.net/manual-0.7.2.html#Attributes-of-Changes
for related docs.


> If instead I run 'svn update', 'svn info' the working copy of the build 
> slave may have a different revision than the commit that originally 
> triggered buildbot (additional revisions may have been added to the 
> repository between the start of the build and the execution of 'svn 
> update').

Understood. This is the reason why the revision is indeed available
explicitely.


Regards,
		Stefan