Hi,
Sorry, lagging a bit one my emails.
On Wed, Mar 25, 2015 at 04:44:32PM +0100, intrigeri wrote:
> Hi,
>
> anonym wrote (24 Mar 2015 16:50:06 GMT) :
> > However, I think the reason I asked for this feature was to trigger
> > rebuilds when the feature branch's APT suite has been updated. From
> > reading the blueprint it only mentions "Git", so I assume the "watchdog"
> > won't look at the feature branch's APT suite state?
That's right, good catch. I tried to add in the blueprint that we want
builds triggered by uploads on APT suites.
However, one point it raises (added to the blueprint) is determining who
would be notified of this kind of build on failure.
Multiple options are maybe to consider:
* Notify every core devs that has upload access on our reprepro.
* Change our packaging habits and put our emails in the changelog.
> Short-term mitigation:
>
> 1. if anyone really want to trigger an immediate rebuild, they can do
> it manually in the Jenkins interface (people who have upload
> rights to our APT repo also have powerful-enough access to Jenkins
> to trigger builds);
> 2. the proposal says that all active branches are built daily, in
> addition to post-Git-push => worst case, the branch will be
> rebuilt within 24h;
> 3. if in a hurry, or for whatever reason, you can still force
> a rebuild by pushing a dummy commit (ugly, but it works).
>
> Long-term: it seems quite clear to me that any upload to an APT suite
> should trigger a rebuild of the *directly* affected base branch.
>
> And also, more generally: at some point, whenever a base branch's
> current build is marked as outdated and needing to be rebuilt, be it
> because the base branch was updated in Git or via its APT suite, we'll
> want to trigger rebuilds of indirectly affected active branches as
> well (e.g. topic branches based on that base branch) somehow.
> Note that our resource estimates (and thus, our last round of hardware
> shopping) didn't take this cascade of triggered builds, so we simply
> can't implement that at the moment.
>
> BTW, I've read a bit about Zuul
> (http://ci.openstack.org/zuul/zuul.html) recently, and this made me
> aware of quite a few issues similar to the one you're raising here.
> Lots of food for thought, forwarded to bertagaz already.
>
> Now, let's put things back into perspective: what bertagaz and Jurre
> are working on so far is expending what we currently have to all
> active branches. Of course it doesn't cover everything that should
> ideally be done yet, simply because what we have so far itself
> doesn't. That's merely yet another step towards implementing the ideal
> CI system we need :)
>
> => bertagaz and Jurre, may you please capture this problem, and the
> long-term solution ideas we had, in the "Future ideas" section of
> the blueprint?
Done in scenarios 14 and 15, please review.
bert.
