[Buildbot-devel] Strategy for highly branched codebase

Jeremy Cornett jeremy.cornett at venafi.com
Thu May 30 14:35:10 UTC 2013


My company has been using the second strategy for some time now. I actually developed a separate buildbot page that allows you to choose which branches get merged into which builder (only do we do this Git repos). We're Git based (newer versions of our product) and SVN based (older versions of our product). In fact, a couple of our builders clone 3 different repos in order to build, one of them always being the repo that contains all our build scripts which buildbot runs. The only caveat to using strategy 2 is that all versions of our product must be compatible with the build system repo. I imagine that you could create separate branches in the build system repo, one for each version of your product, but we just don't do that.

Thanks,
Jeremy

From: Ludovic Chabant [mailto:ludovic at chabant.com]
Sent: Wednesday, May 29, 2013 10:18 PM
To: BuildBot Devel
Subject: [Buildbot-devel] Strategy for highly branched codebase

Hey everyone,

So this may be as much of a buildbot setup question as it is a project setup question. Our codebase is shared across several different projects, each of which has any number of branches and variants. There is a crazy total number of branches.

Now we don't have all those branches on our build server, but we need to add/remove any branch at any moment to/from the build server. Basically when we need to work with some of our clients, we would add some of their branches to the build server to monitor the changes we make there, and also have the build server do stuff for us like populate our Perforce proxies (customers are all around the world) or warm up our data caches (there is data building involved, not just code).

Now the problem lies with the various scripts that our builders execute. They're in source control, but different projects and different branches have different versions of those scripts -- and sometime they don't have them yet because that team is still on an older version of the codebase.

So far, I can think of only 2 solutions:

1. Write custom build steps with all the logic in them.
I know this is frowned upon, but this may be an edge case. The problem is that there isn't a lot of information about doing this kind of thing, so I don't know what can be done, what can't be done, etc. Does anybody have experience with this?

2. Put all the build stuff in a separate codebase.
Basically put all the scripts in a standalone repository, and have the buildslaves not only sync the normal codebase, but also sync the "scripts" codebase, so any changes to them would apply to any project, regardless of what version of our codebase they have.
This could be a problem however since, at least with Perforce, each builder is supposed to have only one workspace, located inside the "build" directory. That workspace could only include the build scripts (through some custom viewspec) if they're on the same Perforce server as the normal codebase, which is not necessarily the case.
Has anybody tried something like that?

Is there maybe a 3rd option I haven't thought about?
--
   l u d o .
   . 8 0 17 80
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20130530/7a4c8af0/attachment.html>


More information about the devel mailing list