[Buildbot-devel] mult-changesource patch

[Axel Hecht]

Well, the really involving piece in my head is to actually make the
existing changesources consistently inherit a base class, and to
factor the name/tag stuff into that base class.

Not really rocket science, just some clean up that's required to turn
this from a hack (we have one ourselves) into a feature.

Axel

2008/10/4 Hans Lellelid <hans at velum.net>:
> Sorry about that; I assumed that the diff that darcs was giving me was a
> unified diff and didn't really bother to read it.  (Can you tell me what
> command I should use to diff this w/ darcs?)
>
> I'll look at your thread; I didn't find it in a quick Google search, but
> that obviously has more to do with how this stuff is being archived than
> anything else.  As for my changes they took all of 20 minutes, so I'm sure
> that the feature you're describing was something more far-reaching than
> this.
>
> Hans
>
> Axel Hecht wrote:
>>
>> Hans,
>>
>> sadly, your patch is basically impossible to read. Add more context,
>> and use unified diff?
>>
>> This is somewhat similar to what I discussed a while back on this list
>> (nag, why exchange mails in private about features?), adding a tag
>> list to Change. That'd allow a bit more flexibility, not sure if it'd
>> be needed. The thread was called "Multiple change sources and
>> scheduler issues".
>>
>> I didn't completely drop the plan to work on that, but focused on
>> other stuff while all the repo transitioning is transitioning.
>>
>> Axel
>>
>> 2008/10/3 Benoît Allard <benoit at aeteurope.nl>:
>>
>>>
>>> Hans Lellelid wrote:
>>>
>>>>
>>>> Hi folks,
>>>>
>>>> After exchanging a couple emails with Dustin yesterday, I put together a
>>>> basic patch to add multi changesource support to Buildbot (or more
>>>> specifically tracking of change source to scheduler).  I wanted to get
>>>> some
>>>> feedback on this before I wrap it up and add it to a Trac enhancement
>>>> ticket.
>>>>
>>>> What I did was to add a 'name' attribute to the ChangeSource (so far
>>>> only
>>>> to SVNPoller) and then added a 'sourcename' attribute to the Change
>>>> object
>>>> (so the system can keep track of which source a particular Change came
>>>> from) and also an optional 'sourcename' attribute to the Scheduler class
>>>> which works like the 'branch' attribute to limit the changes that a
>>>> scheduler cares about.
>>>>
>>>> This all sounds very minor (and was only a handful of lines of code),
>>>> but
>>>> it was really important for us to be able to have a single buildmaster
>>>> with
>>>> many projects and this seemed to be the easiest path to that solution.
>>>>
>>>> A few notes:
>>>>  - This isn't really "multi-project" as much as multi-changesource and
>>>> changesource filtering on schedulers (e.g. there's no change to the web
>>>> frontend to track different projects)
>>>>  - I did add the source name to the logging messages, meaning that if
>>>> it's
>>>> not specifed you may see something like
>>>> "SVNPoller(None:http://your.repo/url) initializing"
>>>>  - As mentioned I only added the parameter support to the SVNPoller, but
>>>> am
>>>> happy to add it to the other change source classes if this patch would
>>>> be
>>>> accepted
>>>>
>>>> The attached diff is against the Darcs trunk repo.
>>>>
>>>>
>>>
>>> Nice idea, I'm using here a patched buildbot with a similar something
>>> tuned
>>> for Mercurial. I called my property "repository", but the idea is there.
>>> I'll try to get an hand on a proper diff monday. I also have a new
>>> Scheduler
>>> (RepoScheduler) which schedule only for a list of repositories (via a
>>> list
>>> of regex), and some support for property expansion.
>>>
>>> (For the records, unified diff (diff -u) are easier to read and apply)
>>>
>>> Regards,
>>> Benoit
>>>
>>>
>
>