On Fri, Sep 25, 2015 at 10:46 AM, Josh Matthews <j...@joshmatthews.net> wrote:
> On 2015-09-25 10:06 AM, Robert O'Callahan wrote: > >> On Sat, Sep 26, 2015 at 1:46 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> >> wrote: >> >> Our static analysis builds can be easily triggered from the try server >>> (although I have been unable to get anyone interested to fix bug 1116518 >>> to >>> make those builds happen on the try server by default, which makes it all >>> too easy for people to forget to turn on these builds from their >>> trychooser >>> syntax) so as soon as the code is pushed to try (perhaps through >>> autoland) >>> the check failures will be visible as build failures. I'm not quite sure >>> what it would take to get those build failures to appear in MozReview but >>> it should be possible. >>> >>> >> The tricky bit is to determine which failures were introduced by the >> patch, >> and just display those, and display them in the context of the patch in >> some way that makes sense. >> >> Rob >> >> > If the static checkers are not a big resource drain, we could just run it > on the parent revision as well and diff the output. Alternatively, store > the results of such runs against our non-try branches somewhere where the > results are easily accessible, then again fetch and diff. > Yes, that would be the way to do it for non-CI checkers. CodeChecker has actually built good support for this workflow, but it is more focused towards post-commit detection of the regressions in what the checkers find. What makes that super interesting is that we can also add Mozilla specific checks to that framework! -- Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
