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