Re: [PATCH v4 1/2] refs: introduce reftable backend

[Jeff King <peff@peff.net>]

On Thu, Feb 08, 2024 at 06:11:57AM +0100, Patrick Steinhardt wrote:

> > > +	ret = reftable_writer_add_logs(writer, logs, logs_nr);
> > > +	if (ret < 0)
> > > +		goto done;
> > 
> > ...the first thing we do is write over it. I dunno if it's worth keeping
> > as a maintenance precaution, though (if the code after the loop changed
> > to omit that assignment, then setting "ret" would become important).
> 
> Yeah, I think this one we should keep. It's also a repeating pattern
> that we have in many other places, so it helps lower the mental burden
> when it looks similar to all the others.

That sounds quite reasonable to me.

> > Both were noticed by Coverity (along with several other false
> > positives).
> 
> Is the Coverity instance publicly accessible? If not, can you maybe
> invite me so that I get a better feeling for them?

I don't think there's a way to make it publicly accessible. Probably I
could invite you to the project if you sign up for a Coverity account.
But it's a build of next plus my personal in-progress topics, which is
probably not ideal for other people to look at.

There are instructions for setting up your own scan in a56b6230d0 (ci:
add a GitHub workflow to submit Coverity scans, 2023-09-25). The unsaid
part there is signing up for Coverity and registering a project to get
the necessary tokens. Probably start here:

  https://scan.coverity.com/users/sign_up

but I don't remember the details.

The Actions workflow is in "master", so in theory we could register a
project for git.git and get automatic builds when Junio pushes to
'next', etc. In practice I have found that it requires a human looking
over the results, but if people at least had access they could poke
around.

(I suspect it would also be easy to port the workflow over to run on
GitLab CI, as well, if you wanted to).

-Peff