[Buildbot-devel] make reconfig failing

[Brian Warner]

"Aaron Dulles-Coelho" <dulles at artifex.org> writes:

> For a given build factory F I construct it as follows:
>
>> F = factory.BuildFactory()
>> F.addStep(
>>  ...
>>  command = my_custom_command
>
> A given builder B is associated with that factory.
>
> If I change the value of my_custom_command and do a "make reconfig" or
> "buildbot sighup", however, my log shows
>
>> 2007/03/13 10:14 EDT [-] builder B is unchanged
>
> subsequent builds do not use the new value of my_custom_command.
>
> How can I force the buildmaster to recognize this change without
> completely restarting the daemon and killing other builds that are
> going on?

That's weird. Modifying the parameters of a step specification should
definitely trigger an update.

What is the class of the BuildStep that you are adding? And this is in 0.7.5,
right?

The short answer to your problem is to change the builder in a way that
*does* get recognized, do a reconfig, then change it back, and reconfig
again. For example, comment out that F.addStep or set slavenames=[], then
change it back.

For reference, here's how reconfig works: When you run 'buildbot reconfig',
or send SIGHUP, the master.cfg file is evaluated (so all of the expressions
inside it are executed, actually creating those BuildFactory instances, etc).
Then the buildmaster goes through all of the instances currently in use and
compares them against the potential new ones from master.cfg . If the new
instance is equal to the old instance, it decides that nothing needs to
change and leaves it alone. If they differ, it shuts down the old one and
activates the new one.

This mechanism is used for ChangeSources and Status targets to avoid
unnecessary restarts of things like timed polling loops or IRC bots. It also
gets used for Builders to allow running builds to continue uninterrupted.

Many buildbot classes inherit the 'ComparableMixin' class which overrides the
__cmp__ method to control what "equals" means. These classes have a
class-level attribute named 'compare_attrs', which is a list of strings that
names the instance attributes that should be compared for equality. If all of
these attributes are the same, we declade that the instances are the same,
and thus the buildmaster won't try to replace the object.

For ChangeSources and status targets, a common programming error is to add a
new __init__() argument but then not add it to compare_attrs. This works fine
the first time, but if the object is changed in the config file, the
buildmaster might not notice the change.

But at least in the current codebase, BuildFactories record a list of
(stepclass, stepkwargs) tuples rather than actually instantiating the
BuildSteps. [this is scheduled to change, and my 'clonesteps' branch at
http://buildbot.net/repos/clonesteps contains the first half of this effort].
Therefore a problem in 'compare_attrs' on the buildstep shouldn't matter.


So I'm puzzled. Can you give me more details about how that Builder is being
set up, and what the rest of the F.addStep() call looks like?


thanks,
 -Brian