Fix build emails blaiming wrong compiler#129
Conversation
|
Well, good news and bad news. So the correct build environment is shown for failures, however the warnings output seems to be garbage. I also spotted a debug log line in the commit, so don't merge this yet and I'll work on it. |
|
There's a current bug in Clang that is generating these 42 false positive warnings. My goal is to fix that in clang-9, but it's lower priority than some of the other bugs currently. |
|
Also: |
|
There was a problem with the modified |
|
So the remaining issue is the warning counts are wrong in the area of the email above the detailed summary. The problem is the data structure used to generate that section of the template is per defconfig, and the warning count is the last processed for a defconfig, ignoring the compiler that was used. I'm working on this ASAP. |
|
As far as I can locally test, this PR is ready for updating onto staging and running tests through. |
|
Sure, this will get tested tomorrow morning, all PRs are tested every day ;) |
|
@gctucker is that automated? I was hoping so but wasnt sure if it needed your magic script running. Where is that run btw, and is it in git? |
|
It's not automated, I have a script to pull all the PRs into a branch but the rest is manual. I can explain how that works on IRC if you want. |
|
Tested OK on staging today, the gcc-8 and clang-8 warnings appear to be consistent between the summary and in the detailed sections. See below today's build email with the changes from this PR for the record. |
gctucker
left a comment
There was a problem hiding this comment.
This seems to be functionally correct but please rework the patches to remove the WIP and make it easier to review each individual patch.
|
The WIP commit undid a lot of the changes in the previous one so it seemed best to squash them together. |
OK, well please do that and then update the PR. |
Ah sorry you just did that :) |
|
Err, all the |
|
Good point, have just squashed them in as well. |
gctucker
left a comment
There was a problem hiding this comment.
A couple of small things.
Remove the compiler string per arch and instead report an environment for each build result. Use the same way of generating the "failed" data, to generate the error and warnings data. This makes rendering build emails simpler.
|
Fixed, I wasnt aware they existed |
|
Thanks, I've updated the backend staging branch and generated one build email, looks fine. |
Remove the compiler string per arch and instead report an environment
for each build result.