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

From: Jeff King <peff@peff.net>
Date: Oct 8, 2021, 20:19 UTC
Message-ID: <YWCn4tpr9RWsRxvr@coredump.intra.peff.net>
In-Reply-To: <xmqqsfxbjncz.fsf@gitster.g>

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

Show 15 quoted lines

> 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