Re: [Tails-dev] Automated builds specification

Delete this message

Reply to this message
Author: bertagaz
Date:  
To: The Tails public development discussion list
Subject: Re: [Tails-dev] Automated builds specification
Hi,

On Tue, Feb 17, 2015 at 10:32:59PM +0100, intrigeri wrote:
> bertagaz wrote (16 Feb 2015 14:32:57 GMT) :
> > On Wed, Feb 11, 2015 at 11:49:02PM +0100, intrigeri wrote:
>
> > That's a logical awesome idea I'm ashamed not to have had sooner.
> > Still, it seems that it comes too late, after some searching it appears
> > that our Jenkins don't keep much stats.
>
> As discussed on IRC, we have about 10 days of logs on the filesystem
> currently, so you can still retrieve recent stats about it.
> The earlier, the better, as we're frozen and the more we wait, the
> less the numbers will be meaningful.


I've just pushed a new page in the blueprint section, that contains the
number of branches merged per release (as your script told us), and the
number of builds per day that happened since 2015-02-10.

https://tails.boum.org/blueprint/automated_builds_and_tests/autobuild_stats/

> > The Global build stats Jenkins plugin [1] seems interesting to display the
> > stats once more logs are kept. Shall I install it?
>
> Let's give it a try, yes.


I'll do that soon then.

> >>   * "Scenario 3 : RM" says "I need to know when a branch FTBFS", but
> >>     I see no notification mechanism planned, so... how is the RM
> >>     supposed to know. Also, whenever stalled topic branches start
> >>     failing, this can imply an avalanche of daily email to the RM, who
> >>     will of course start ignoring all email from Jenkins and then
> >>     we've lost. I'm particularly worried about this topic since anonym
> >>     (our RM most of the time) didn't comment on this proposal yet, and
> >>     has already expressed concerns about this kind of issues.

>
> > I think anonym did comment on this proposal, he did a review of this
> > blueprint already.
>
> OK. Let's keep in mind that he may not have thought of this potential
> problem yet.
>
> Now, I wonder if we could solve this quite simply by having the RM be
> notified for *base* branch build failure only. The RM doesn't care
> about topic branches that haven't been submitted for merging
> yet, right?


I like this idea, simple and effective. :)

So for the base branches, the RM would be the contact point for daily and
on push build failure notifications. And for topic branches, that would be
the last commiter.

> > One thing that this question also raise is the fact that the RM is not
> > always the same person, so I'm wondering how to have jenkins notifying the
> > right email depending on who is the RM for the next release. First thing
> > that come in top of my mind is... a schleuder address. :)
>
> Indeed, that's the kind of aliases the RMs can trivially update
> themselves, without asking the infra team to do anything.


Great, I'll add that to the specs and will open the corresponding tickets.

bert.