On 12 October 2016 at 10:25, Pierre Tardy wrote:
> Hi Mojca,
> What I do to group those kind of reporting is to have a parent build, and
> use the triggereable scheduler.
> You can then put the reporter on the parent build only, and build a summary
> email with everything that broke.
We already have a triggerable scheduler that can create even thousands
of individual builds and makes a report out of it. But there is one
such build/report per slave at the moment, summarizing all the
(thousands?) of builds. If we would merge the jobs one level higher,
this would add so much extra troubles that it probably wouldn't be
If nothing else one of the slaves is so slow that it can take days or
weeks (not to say months as we would probably cancel those manually)
to finish the job. We don't want to wait for that slave to be done
before we can start other jobs on other slaves.
> On eight however, It is difficult to get a reference for triggerered builds.
> so that might not be the best help for you.
I'm aware of troubles with creating references between builds (parent
& child when triggering), but we'll have to live with that for a
> Your idea of the extraHeaders looks good to me, and sounds like a good
> We would have to make sure we find a correct header that we can use, and
> works well for most email clients that can group emails into conversations.
Based on reading some threads on stackexchange and based on personal
experience there are two different approaches:
(a) GMail wants the same subject (and perhaps the same sender): that's
easy to achieve and that already works for us
(b) most e-mail clients work properly with matching "In-Reply-To" fields
> Le mer. 12 oct. 2016 à 10:19, Mojca Miklavec <mo...@macports.org> a écrit :
>> Most often a "broken commit" (or known-to-be-incompatible software)
>> breaks functionality on multiple (or all) slaves.
>> So we would find it super useful if we could group failure emails from
>> different slaves by SVN revision.
>> We planned to add an additional header like
>> In-Reply-To = commit-r123...@example.com
>> I see that MailNotifier supports adding
>> but it's not clear to me how to access the svn revision or git shasum
>> at the point where MailNotifier is being added.
>> I would be grateful for ideas about how to properly implement that (in
>> version eight).
>> The next thing we would want to do is to group forced builds (when
>> someone triggers a build from the web interface to all slaves, we
>> would need some similar unique identifier to be able to add the same
>> In-Reply-To to all failure emails).
>> Thank you,
>> users mailing list
users mailing list