Add abstraction layer for the build server

[g-arjones]

This would allow using the daemon to trigger i.e a gitlab pipeline or a parametrized github action instead of buildbot.

[doudou]

All for it.

The original architecture was to trigger on the push to the buildconf, and let each CI system handle the rest. Maybe it is time to come back to that ?

[g-arjones]

A push to the buildconf? We rarely push anything to the buildconf... Can you elaborate?

[doudou]

The original design idea was to get the daemon actually update branches (instead of hard-resetting them each time), pushing an overrides file that contains both the package's branches and the HEAD that the daemon just detected.

From there, the CI was to detect the push and do its stuff. Something that all CI know how to do, since they're designed to listen to a single git repo. Which could include custom steps to e.g. use some additional metadata (that could also be written by the daemon) to help with presentation and tracking of information.

[g-arjones]

Interesting... The daemon would be completely independent of the CI system. But then the CI system would have to be able to filter and trigger only branches that are managed by the daemon.

[doudou]

Not really. The other branches would also be built, allowing to also test pull requests from the buildconf itself... Something I have to do manually right now.

[g-arjones]

If the CI is going to depend on metadata (i.e project name, pull request ref, etc) and overrides pushed by the daemon how would it build a branch that wasn't pushed by the daemon and therefore doesn't have such data?

[doudou]

The same way than now ... by having sane defaults if there is no metadata.