[users at bb.net] Anecdote about attempting to make scheduelrs reconfigurable.

Pierre Tardy tardyp at gmail.com
Thu Dec 22 20:11:24 UTC 2016

I think indeed, this is such a case were you would need to actually store
some part of the config in the object inside checkConfig.
Like you already pointed out there are already some of the objects (if I
recall correctly the worker are doing that) that are doing that for the
same reason.

Looks like you are at the point were you could start sharing the code. I
think it would be easier to discuss this in a PR even if this is not fully


Le jeu. 22 déc. 2016 à 17:08, Neil Gilmore <ngilmore at grammatech.com> a
écrit :

> Good morning everyone,
> As you remember, we're having a lot of trouble related to schedulers in
> 0.9.X not being reconfigurable in any meaningful sense of the word. I
> got the go-ahead to try to make a patch for this. Unfortunately, I've
> run into a fairly serious problem.
> The advice I was given was (in a nutshell) to take the code in the
> various schedulers' __init__ functions, and spread it into 2 functions.
> checkConfig() would check its arguments for validity, and
> reconfigService() would put them into the instance. Sure, there were
> some various snags at first. Partly, I'm not used to Python's
> argument-passing model. Partly, figuring out which arguments needed to
> get passed where. Partly, figuring out that name should only exist in
> the __init__'s, not the checkConfig's, etc.
> What happens when we create a scheduler is this:
> The scheduler's __init__ function is called. This calls it's base
> class's __init__, and so on, up to BuildbotService.__init__. Note that
> all arguments must be preserved during these calls. You'll see why.
> BuildbotService.__init__ calls checkConfig. Now, this call goes to the
> scheduler's checkConfig, which checks its own specific arguments, then
> passes everything else up to it's base class's checkConfig, and so on.
> Everything,s great, right? Wrong...
> At this point, we have validated everything. But only the name is in the
> instance. Because everything else is supposed to get assigned in
> reconfigService.
> But in between __init__ and reconfigService, other things happen. Such
> as check_single_master() (at least for single master systems). That
> attempts to check the builder names in the schedulers vs. the builders'
> names in the config. Naturally, this fails because the builder names
> haven't been put into the schedulers yet. And it would go on to check
> other things that probably fail, too.
> I'm not sure how to resolve this. The hacktastic way would be to just
> figure out what might ever get checked and put that back into __init__.
> But that's not very clean. The proper way would be to figure out how to
> make a scheduler reconcile it's own builderNames, et al. with the
> builders in the config. But I'd need to be able to get the config being
> checked, and I haven't figured out how to do that. There's other checks
> that go between items like this that I'd need to do, too.
> Really, I'm just uncomfortable having this task spread out into other
> areas of buildbot.
> Or I just go back to our 80% solution and hack checkConfig...
> Neil Gilmore
> grammatech.com
> _______________________________________________
> users mailing list
> users at buildbot.net
> https://lists.buildbot.net/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.buildbot.net/pipermail/users/attachments/20161222/a5769a6d/attachment.html>

More information about the users mailing list