Re: [GSoC] [PATCH] travis-ci: added clang static analysis

From: Siddhartha Mishra <sidm1999@gmail.com>
Date: Apr 2, 2018, 20:08 UTC
Message-ID: <CAMOtk6D9AtzNpufnv7hbCUAVYVgTiL-O_Ni=R0DB4LOHUNV=7A@mail.gmail.com>
In-Reply-To: <74BBE628-B8FC-4699-9A23-F774D4908011@gmail.com>

On Sun, Apr 1, 2018, 8:10 PM Lars Schneider <larsxschneider@gmail.com> wrote:

Show 14 quoted lines

>
> That's a good summary and I don't see a better solution. While (3)
> sounds nice, I think (2) is the fastest/most pragmatic solution.
>
> We already use the Travis cache [1]. You could use that mechanism to
> store a file with the latest number of bugs in the cache directory
> $HOME/travis-cache
>
> If the "number of bugs" file does not exist, then create it and don't
> complain. If the file exists and the previous number of bugs is higher
> or equal, then don't complain either. If the file exists and the previous
> number of bugs is lower, then let the build fail.
>
> Do you think that could work?

Apologies for having sent this message twice, the last one wasn't in plain text and were therefore not properly forwarded to the mail group.

If we only consider the number of bugs in the last pushed commit, a situation might happen that a commit creates a lot of bugs. If a subsequent commit then fixes only a few of the previously created bugs the build would still pass since the number of bugs from the last commit has decreased.

Should this be the intended behaviour or should adding the number of allowed bugs be a more deliberate process?

Thanks, Siddhartha