Hi Pierre,
Thanks for the reply.
I'll have a look at the worker to see what it's doing, then see what I
can do in my code. Mostly, I just needed a direction to go, and there
were several available.
I think I asked about PR before, as I'm not familiar with the acronym,
but I don't recall getting an answer. Any pointer would be helpful.
I did get the OK from on high to share the code back. I wouldn't say
it's finished by any means, but all the bones are there. I'm not going
to be around much until after New Year's, though.
Neil Gilmore
grammatech.com
On 12/22/2016 2:11 PM, Pierre Tardy wrote:
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 finished.
Pierre
Le jeu. 22 déc. 2016 à 17:08, Neil Gilmore <ngilm...@grammatech.com
<mailto:ngilm...@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 <http://grammatech.com>
_______________________________________________
users mailing list
users@buildbot.net <mailto:users@buildbot.net>
https://lists.buildbot.net/mailman/listinfo/users
_______________________________________________
users mailing list
users@buildbot.net
https://lists.buildbot.net/mailman/listinfo/users
