[Buildbot-devel] master.cfg with codebaseGenerator

Harry Borkhuis harry.borkhuis at ict.nl
Thu Dec 20 21:36:39 UTC 2012


David,



First of all codebases are not ment for filtering. You should only use codebases if have to checkout from more than one repository to build your target. What I understand from your master.cfg is that you have three deliverables each having it's own repository. In that case you won't need the use of codebases.



But suppose opencog_master depends on 2 repositories to build opencog: opencog.git and opencoglib.git.

  *   In the codebaseGenerator you assign codebases to these repo's (you did that already correctly): opencog and opencoglib.
  *   You define a SingelBranchScheduler and you tell this scheduler to react on changes from the 2 codebases. For each codebase you specify the repository and optionaly a branch. Do not pass this lits to the buildsteps as you did. Each buildstep works for one codebase.
  *   The builder will have to checkout the sources for each codebase. So for each codebase a separate sourcestep is needed. You will have to assign a codebase to each sourcestep. In our case there will be a sourcestep for the open opencoglib and one for the opencog. You probably want the sources in different directories so you can specify different workdirs for each step.

What happens when you submit changes to opencog.git repository. The change is passed to the codebaseGenerator and the codebase property of the change is set to opencog. Any scheduler that has opencog in its set of codebases will receive the change. The scheduler looks in further in the set of codebases and finds out oh well I also need source from opencoglib but did not receive any changes for this repository and uses the information in the codebases set to get the sources for opencog lib (if you set the branch it will be used to get the latest sources from the repository (for example stable), assume not to set revision to get the latest sources).

The builder start all the buildsteps... The first buildstep is a sourcestep that  has a codebase set to 'opencoglib'. Looking for changes in the builder it will not find any changes  so it will check out the latest sources from opencoglib. The second step has the codebase opencog. Looking for changes the builder will find submitted changes and will checkout the sources with the revision and branch as set in the change.

Now you have all the sources to build the target.



As already said you probably won't need this but I hope this will help you und and others erstanding the value of codebases.



________________________________
Van: David Hart [dhart at opencog.org]
Verzonden: donderdag 13 december 2012 0:39
Aan: buildbot-devel at lists.sourceforge.net
Onderwerp: [Buildbot-devel] master.cfg with codebaseGenerator

Hi,

I'm looking for examples of master.cfg with a codebaseGenerator and codebases properties in schedulers & builders.

My config files are at https://github.com/githart/opencog-config-files - master.cfg for the live config, and master-codebase.cfg for the updated version that uses codebases.

I'm running into the classic problem that a checkin on one of two repos may cause an invalid sourcestamp to be passed to the source.git.Git step, leading to errors like this one: http://158.132.219.213:8010/builders/opencog_master/builds/77/steps/git/logs/stdio

I'm looking for the correct use of codebaseGenerator and codebases in schedulers & builders to act as a filter so that each builder uses the correct sourcestamp.

-dave

--
David Hart |  +852 9875 1345
OpenCog Foundation | http://opencog.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20121220/0203827c/attachment.html>


More information about the devel mailing list