Hi Pierre,

Thanks for the pointer. I think part of the problem is cognitive dissonance attacking me from a previous life, where 'PR' meant 'problem resolution'. I don't do much git at all, so while I understand pull request, the abbreviation of PR wasn't quite getting through.

Neil Gilmore
grammatech.com

On 12/22/2016 2:27 PM, Pierre Tardy wrote:
PR means pull request

This is the basic howto for our contribution.
http://trac.buildbot.net/wiki/SubmittingPatches

Have great holidays!
Pierre

Le jeu. 22 déc. 2016 à 21:20, Neil Gilmore <ngilm...@grammatech.com <mailto:ngilm...@grammatech.com>> a écrit :

    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 <http://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 <mailto:users@buildbot.net>
    https://lists.buildbot.net/mailman/listinfo/users


_______________________________________________
users mailing list
users@buildbot.net
https://lists.buildbot.net/mailman/listinfo/users

Reply via email to