[Buildbot-devel] Buildbot supporting buildset with multiple repositories
Jared Grubb
jared.grubb at gmail.com
Thu Nov 24 05:12:48 UTC 2011
On 23 Nov 2011, at 22:42, Dustin J. Mitchell wrote:
> On Fri, Nov 18, 2011 at 12:44 AM, Jared Grubb <jared.grubb at gmail.com> wrote:
>> So, my reasoning goes like this:
>>
>> 1. As you say, most properties are universal: there's exactly one value for the entire Build
>>
>> 2. As you say, each repo in a Build should have its own got_revision.
>> * Recording these in a dictionary is the obvious choice (repo is the key, got_revision is the value)
>>
>> 3. It seems that 'revision' and 'branch' are also repo-centric values.... From #2, we already have a dictionary with repo keys, so we could put these in there as well.
>>
>> 4. It's easy to take this solution and allow any property to be optionally overridden/specialized according to a repo key.
>>
>> I've noticed this was a common feature request and thought I'd throw this out there. It's not very novel (it's really no different from local-global variable scopes or namespacing) but it does generalize the idea of properties a bit and provide some flexibility... but maybe it's too general? Just an idea.
>
> I think that our perspectives differ as follows: from my perspective,
> properties are simply a convenience for step definitions, e.g., to
> name a binary after the branch or revision it was built from. The
> values of concern to Buildbot are in the sourcestamp (or sourcestamps,
> when we start using sets of sourcestamps), and that is a bit tricky,
> but not impossible to solve. I think that the problem of properties
> for multiple sourcestamps can be solved with the existing property
> semantics, without extending both the semantics and the API.
Ah, then that means I've just learned that 'branch' and 'revision' are actually not properties at all.... which explains the trouble I just ran into in my own personal buildbot. It surprises me that there are two ways to parameterize a build, but trying to get into that in this thread will no doubt just derail things, so I'll just cede that I probably cant offer any more help here. I thought I had a proposal, but I guess I dont.
I know I've tried to twist bulidbot to do an 8 library + binary (each in a separate repo and each with unit tests), and each time I think I got it, I run into a reason I dont. Having multi-repo support would definitely help as I'm probably straining buildbot's architecture to get this to work. If there's another Bay area buildbot meeting, I'd love to attend. Maybe I can offer another use-case sample to help push a proposal forward. In any case, great job on buildbot.
Jared
More information about the devel
mailing list