[Buildbot-devel] Strategy for highly branched codebase

[Philippe McLean]

another approach

-- keep all the details on how to build in the branches themselves, and
keep buildbot steps as simple as possible (shell command).

benefits:

- a branch can be checked out and built by a dev in the same way as buildbot
- avoids master.cfg being bottleneck (and the people who understand it)
- the product and how to build it is in one place, and versioned at the
same time
- scales out faster for new variant

downsides:

- different branches will diverge in their build scripts (maintenance,
failures, artifact discrepancies)

then, buildbot is responsible for scheduling, repository checkouts,
reporting, and cascading builds and tests.
adding a new build for a branch becomes a relatively straightforward
process.



On Thu, May 30, 2013 at 7:35 AM, Jeremy Cornett
<jeremy.cornett at venafi.com>wrote:

>  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****
>
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Buildbot-devel mailing list
> Buildbot-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/buildbot-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20130530/6c1304f3/attachment.html>