Re: Commit notification

[Frederic Peters <fpeters 0d be>]

[copying your answer to the list]

John Carr wrote:
> not really. when i fixed it to work against svn commits list i was
> only using the test suite to make sure parsing worked.
> 
> see the comment in master.cfg for how it normally works. for us it
> wont be enough. there is 1 change source for the whole service and all
> builders are notified of all changes. we need to give the builders an
> is interesting change function so we dont rebuild foo when bar
> changes.

So changes.py should also parse mail subject to get the module name,
that part is easy enough.  But then there is no way to pass that one
to the Change() object.

[whenever I am looking for something in buildbot source code I fear a
 grue could eat me.]

Somewhere a addChange() method will then be called, I believe on the
scheduler, so jhbuild/buildbot/scheduler.py.  There we have two kinds
of schedulers, StartSerial and Serial.  IIRC StartSerial is used for
the first module in order, (libxml2 in most cases), and Serial is used
for the others.

But then I read this in buildbot:
  class Periodic(BaseUpstreamScheduler):
      """Instead of watching for Changes, this Scheduler can just start a build
      at fixed intervals. The C{periodicBuildTimer} parameter sets the number
      of seconds to wait between such periodic builds. The first build will be
      run immediately."""

  [ So there would be no way to get change notification to go to the ]
  [ first module?  Seems strange.  It should probably be combined    ]
  [ with change notification.  But let's keep this aside.            ]

addChange() is called on Serial. Its parent is BaseUpstreamScheduler
that doesn't have addChange() either.  BaseScheduler is its parent,
and it has addChange(), it does nothing.

So let's add addChange() to our jhbuildbot Serial scheduler.  Good
thing is it is our own code, so we could have added a project
attribute to the Change() object (see 1st paragraph if you're lost
and fear a grue is approaching) and have it put to good use here.

Good use, eh?  What should happen here?  Easiest case is when all
modules have already been built once, in that case the new job can be
scheduled and happen anytime.  The other case is when all modules have
not yet been built, as it is quite useless trying to build
gnome-terminal if vte has not been.

What should addChange() look like, let's look at Scheduler and make
something similar.  First thing is we need the scheduler to know to
which project it belongs, that is easy enough (just commited).  It
is now a matter of testing that value:

    def addChange(self, change):
        if change.project != self.project:
            # ignoring change on a different project
            return

And then, it could well be a straight copy of the rest of the method,
as well as other methods, addImportantChange, addUnimportantChange,
setTimer, fireTimer, stopTimer.

And if it works for Scheduler, there is no way it wouldn't work for us
too.

I am giving it a go now.


        Frederic