turn autoproj-daemon into a buildbot change source instead of directly triggering builds

[doudou]

There are a few important advantages in doing so:

• one can see which changes triggered a particular build
• allows to filter what builds actually gets triggered at the buildbot level, with no changes needed at the autoproj-daemon level.
• autoproj stops having to know about builds. It becomes a buildbot change source, and buildbot takes care of reacting to the changes.

I have now 7 manifests in a single buildconf, managing both the main development build and separate builds for each machine in the system. This change allowed us to decide where to build only mainline, where to build pull request, to ignore pull requests from certain packages we're not interested in ....

It really adds flexibility at the buildbot configuration level, without needing to change autoproj-daemon (which, by nature, is less visible)

[g-arjones]

This is a very good idea, the AnyScheduler thing really is what's supposed to be triggering builds in a buildbot-based CI system. :+1:

If I may, I'm a bit curious about your use case... Usually, the "main development build" is a superset of all other builds (assuming the other "builds" are just different manifests in the same build configuration). What kind of failures are you expecting to catch with this kind of setup?

[doudou]

What kind of failures are you expecting to catch with this kind of setup?

One thing you do catch are bad interactions between the excludes (which avoid building e.g. GUI) and the necessary packages.

But the main driver is to use these builds for CD - generating the artifacts needed to deploy the software.

[doudou]

This is a very good idea, the AnyScheduler thing really is what's supposed to be triggering builds in a buildbot-based CI system. +1

Does this mean this is approved ? :P

[g-arjones]

Yes! Sorry :P