Re: What's cooking in git.git (Oct 2021, #02; Wed, 6)

[Jeff King <peff@peff.net>]

On Fri, Oct 08, 2021 at 01:03:08PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > They do have some limits posted here:
> >
> >   https://scan.coverity.com/faq#frequency
> >
> > It's on the order of 3 builds per day for a code base of our size. Which
> > is plenty for our integration branches, but not enough to test every
> > topic branch.
> 
> I usually have at least two pushout of 'seen' (one with the full set
> of 'seen' including known-to-be-broken topic integrations, the other
> with seen~$some_hopefully_small_number that I didn't see brekaage in
> my local build), and then on graduation days 'next' and 'master' are
> also updated, so 3 is cutting very close ;-)

Hmm, yeah. They say "21 builds per week", which would be plenty (you
don't push out integrations every day), but I think they may also have a
per-day limit.

I'm not sure what happens when you hit the limit. If it just silently
skips the analysis, that's fine (we'll pick up the changes the next
day). If it causes a CI failure that nags you, that is less good. But
probably something we could work around in the Actions commands.

TBH, though, I think just building "seen" would be sufficient for this
kind of analysis. Most CI is about "make sure we pass the tests and do
not graduate topics if it doesn't". This is much more about "generate a
set of possibly-bogus annotations for some human to look at". Given the
topic branch flow you use, it's pretty unlikely for a problem to
_appear_ in master or next. And even if they do, it will be detected the
next time seen is run.

-Peff