<div dir="ltr"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">Le mar. 3 janv. 2017 à 16:57, Neil Gilmore <<a href="mailto:ngilmore@grammatech.com" class="gmail_msg" target="_blank">ngilmore@grammatech.com</a>> a écrit :<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
Hi Pierre,<br class="gmail_msg">
<br class="gmail_msg">
Thanks for the reply.<br class="gmail_msg">
<br class="gmail_msg">
The current status of my code is that all the schedulers now support
checkConfig and reconfigService. I can also (after some wrangling)
start buildbot using any of the schedulers. I have yet to test
reconfiguration, and I have not run any of the current buildbot unit
tests. Nor have I done any of the github stuff. I did subscribe to
the dev list (it was really just a matter of time).<br class="gmail_msg"></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">I highly suggest to start with the unit tests, as once it is understood help you to be much more productive than typing buildbot reconfigure all the time.</div><div class="gmail_msg"> Also, obviously creating an account of github and pushing your code will help me to help you.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
<br class="gmail_msg">
My current code (which appears to work) adds another argument for
ForceSchedulers 'properties'. The __init__() function uses
'properties', but then calls BaseScheduler.__init__() using the new
argument, which ends up in kwargs for most of the trip around to
ForceScheduler.checkConfig(). The code cribbed from the old
__init__() is adjusted to use the new name. Thus, the current API
and behavior are preserved.<br class="gmail_msg"></div></blockquote></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">We have to make sure we keep the same API, but removing properties from super's kwargs might indeed do the trick. </div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
<br class="gmail_msg">
I don't think not calling super.checkConfig is a good idea. We still
need to check the rest of the config against the base classes (in
this case BaseScheduler and BuildbotService). Incidentally, my
current code only uses super if the code in __init__() used it. Most
of the classes used explicit bases, so I left that. It's a decent
candidate for a later change.<br class="gmail_msg">
<br class="gmail_msg">
The current code changes are pretty extensive, yes, because they
affect every scheduler class. I think it might be good to stage the
PRs this way:<br class="gmail_msg">
<br class="gmail_msg">
1. Regularize compare_attrs for schedulers. In 0.9.2, several
schedulers appear to have a problem where they do not include their
base classes' compare_attrs. This wasn't as important when there was
no effective reconfiguration. <br class="gmail_msg"></div></blockquote></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">There is indeed a need for cleanup, but not the way you might think of it.</div><div class="gmail_msg">compare_attr uses <span style="background-color:rgb(248,238,199);color:rgb(51,51,51);font-family:consolas,"liberation mono",menlo,courier,monospace;font-size:12px;white-space:pre">reflect.accumulateClassList</span>, which does take in account all compare_attr of all the subclasses.</div><div class="gmail_msg"><a href="https://github.com/buildbot/buildbot/blob/master/master/buildbot/util/__init__.py#L136">https://github.com/buildbot/buildbot/blob/master/master/buildbot/util/__init__.py#L136</a><br></div><div class="gmail_msg">Some classes are explicitly adding their parents compare_attr but this is either a mistake or a legacy (I am not sure, this precedes my involvment in this project)</div><div class="gmail_msg"><br></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
<br class="gmail_msg">
2. Add the checkConfig and reconfigService functions, but leave them
empty. This will at least ensure that I have those setup up
properly.<br class="gmail_msg"></div></blockquote><div>+ remove the __init__. We should always use the BuildbotService class __init__ for correct use of checkConfig/reconfigService</div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
<br class="gmail_msg">
3. Fill the functions.<br class="gmail_msg">
<br class="gmail_msg">
My current task is to exercise actual reconfigurability. This will
involve learning how to write a buildbot test, which will probably
be predicated on learning how to run the current tests.</div></blockquote><div><br></div><div>Some useful links for that:</div><div><a href="http://docs.buildbot.net/latest/developer/tests.html">http://docs.buildbot.net/latest/developer/tests.html</a></div><div>The basic step to run the tests is the command:</div><div>trial buildbot</div><div><br></div><div>you might also like <a href="https://pypi.python.org/pypi/cctrial">https://pypi.python.org/pypi/cctrial</a></div><div><br></div><div>pip install cctrial</div><div>cctrial -sf buildbot</div><div><br></div><div>cctrial -sf allows a continuous development workflow which run only the tests that are modified by the files you just worked on, and the test automatically re-run after file save until it passes.</div><div> </div></div></div></div>