[users at bb.net] One anecdote, and some unsolicited code.

Pierre Tardy tardyp at gmail.com
Thu Nov 17 20:03:26 UTC 2016

Le jeu. 17 nov. 2016 à 20:19, Neil Gilmore <ngilmore at grammatech.com> a
écrit :

> Hi everyone,
> The anecdote first.
> So we've been plagued with the non-modifiable scheduler problem. A lot.
> I finally got to look at that without distraction yesterday.
> Unfortunately, I didn't find the documentation on the reconfiguration
> process too useful other than to point me at function names.

Following is the documentation. This is quite deep in the core, so dont
expect a tutorial on this, but you still get some detailled description of
the buildbot services lifecycle. (hint: everything is a service in buildbot)

> Now for the unsolicited code.

Every unsolicited code is very welcome by the buildbot community, we are
very friendly to all contribution.

> So I first wrote an overriden version of reconfigService() in
> BaseScheduler. Goody! When I start or reconfig, my version gets called.
> But I really didn't want to have to create _config_args and
> _config_kwargs in BaseScheduler.

No you dont, but you haven't.

You just have to follow the checkConfig/reconfigService principle for all
schedulers and their subclasses.
It can only work if all the subclasses are following the process.

> It looked safe to override
> reconfigServiceWithSibling in BaseScheduler.

Arg no! dont I can't see that. please!

> It's nice that all the
> figuring out whether to reconfig or not is already computed by that
> point. The resulting function is all of 9 lines:
> (in class BaseScheduler)
>      def reconfigServiceWithSibling(self, sibling):
>          # only reconfigure if sibling is configured differently.
>          # sibling == self is using ComparableMixin's implementation
>          # only compare compare_attrs
>          if self.configured and sibling == self:
>              return defer.succeed(None)
>          self.configured = True
>          self.name = sibling.name
>          self.builderNames = sibling.builderNames
>          self.properties = sibling.properties
>          self.codesbases = sibling.codebases
>          return defer.succeed(None)

Yes, looks simple, but checkConfig/reconfigService is much more flexible.
Both functions can be seen like a contructor.
The first part of the constructor is the part that do the checks, and the
second part that actually store the configs inside the object attributes.
The good think is that the config part can be an inlineCallbacks, so you
can call deferred returning function. This is very powerful and you cannot
do that with python constructors.

The drawback of this method is that it requires a bit of code duplication,
as the two methods must have the exact same footprint.

(I know it's not in the form of a patch or anything, but if it helps
> anyone, got ahead and use it).
I am not sure if you can't contribute because of company policy or
anything, but I would recommend to try and contribute a proper fix.

I started my work with buildbot by doing such hacks in the prod, and after
4 years we have tons of big hacks in it. We can't upgrade our prod to the
new awesomeness of nine, and are stuck with 0.8.7.
This is unfortunaly the case with some other big companies (watch were my
eyes rest.).

Buildbot is helping you a lot, so maybe its time to help Buildbot.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.buildbot.net/pipermail/users/attachments/20161117/846ce16e/attachment.html>

More information about the users mailing list