While triaging bug 12306, the reported MACHINE value (mpc8315e-rdb) on first comment does not correspond to what actually used at runtime (qemuppc) so the what is being parse to create the email is somehow wrong. According to RP, the root cause is: "> I think this is the configuration in use at the end of the build, it > wasn't the configuration in use at the time of the failure :( >"
The issue here is that the build failure email from the autobuilder comes out after all the buildsteps execute. The summary is from the last buildstep but values like MACHINE may vary as the steps execute. That failure might not be from the last buildstep. This is misleading so do we emit a build failure email per failing build step so we can have the correct info? This is confusing people at the moment, understandably.
(In reply to comment #1) > This is misleading so do we emit a build failure email per failing build > step so we can have the correct info? We could easily do this. If a failure email is deemed too excessive (though I'm not sure it would be) we could build up the message locally by writing failures to a file and then mailing the full log of failures for a triggered build at once, we have some logic we could reuse for this in the wikilog status plugin. I'm generally in favour of the simpler option and just sending an email per failed build step.
Maybe I was a little hasty in saying that this would be easy :-) The Yocto_Message_Formatter expects to receive certain objects that aren't always as expected when calling the message formatter from a stepFinished event, rather than a buildFinished event. I'll continue looking over the code to determine what is the cleanest solution to avoid this confusion.
The autobuilder no longer sends these messages (this is one of the reasons why)