Capomastro lacks the ability to schedule builds

[John McAleely]

When using Capomastro for an OEM project, it would be good to be able to automatically start builds when the code changes. Currently all builds must be manually triggered.

I think there would be two useful triggers:

 - Time based (once or twice a day, perhaps). It would be desirable if no build occured if no change had been detected in the source tree.

 - Change based. It would be desireable to simply build all incoming merge proposals on the gerrit source tree used for OEM phone projects. These could then be used to automatically +1 merge proposals.

[John McAleely (john.mcaleely)]

Should these be separate bugs?

[Daniel Manrique (roadmr)]

OK, this feature will need a bit of design/thought.

We've thought about having periodic builds, say daily or whatnot. This can be done via crontab (but introduces one more tool to the mix), or via celery beat (http://celery.readthedocs.org/en/latest/userguide/periodic-tasks.html) which allows us to leverage our existing infrastructure.

With celery beat we'll need to add scheduling UI to capomastro, and this implies more development work on capomastro itself. However, in the long run this solution may be more desirable than crontab, because crontab in an openstack-deployed service will be harder to manage (we may need to go through a lengthy deployment process for any changes). So perhaps the time we employ designing this UI will be well-spent so this feature can be 100% managed from the capomastro UI. Also, I don't think we need full cron semantics, so something that just checks and builds every X hours/days will probably be enough.

On the topic of change-based builds (and which interestingly also affects "only build if source has changed" periodic builds), is that capomastro has no concept or knowledge of revision control utilities, and thus has no idea that a build is for a specific revision in a tree. So this functionality would have to be implemented in the project-specific build scripts. Consecutive revnos like bzr make it easy to figure out if the tree has changed, with git it may be harder because there's no consecutive revision ID, but I'm sure we can figure something out. But again, that probably belongs in https://launchpad.net/bygmester and its per-project scripts.

[Ara Pulido (ara)]

This is pretty important.

I have created a user story for it