Re: [PATCH v2] .github/workflows: add coverity action

From: Jeff King <peff@peff.net>
Date: Sep 23, 2023, 06:10 UTC
Message-ID: <20230923061053.GA1469962@coredump.intra.peff.net>
In-Reply-To: <b23951c569660e1891a7fb3ad2c2ea1952897bd7.1695332105.git.me@ttaylorr.com>

On Thu, Sep 21, 2023 at 05:53:31PM -0400, Taylor Blau wrote:

Show 16 quoted lines

> diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml
> new file mode 100644
> index 0000000000..3ba00b3929
> --- /dev/null
> +++ b/.github/workflows/coverity.yml
> @@ -0,0 +1,22 @@
> +name: Coverity
> +
> +on: [push, pull_request]
> +
> +jobs:
> +  coverity:
> +    if: (vars.ENABLE_COVERITY == 'true') &&
> +      (vars.COVERITY_BRANCHES == '' ||
> +       contains(vars.COVERITY_BRANCHES, github.ref_name) ||
> +       contains(vars.COVERITY_BRANCHES, '*'))

I wonder if we really need this ENABLE_COVERITY flag. It's not _too_ hard to set up, but it feels like we can eliminate a setup step and just infer it from other variables. Either:

  1. Treat unset COVERITY_BRANCHES as "do not run". Unlike the CI job,
     there's not much useful signal in running this for every PR. A
     human has to go periodically look at the coverity output and make
     sense of it. So I think it's something that would get run
     periodically (say, on updates of "next") just for one or two
     branches.

  2. Use COVERITY_SCAN_EMAIL as a clue that the feature it is enabled. I
     don't think we can do that as-is because it's a secret, not a var.
     But is there a reason for the EMAIL to be a secret? I don't think
     repository vars are fully public; they're just not hidden as deeply
     as secrets. It seems like the right level of privacy for an email.

Show 11 quoted lines

> +    runs-on: ubuntu-latest
> +    steps:
> +      - uses: actions/checkout@v3
> +      - run: ci/install-dependencies.sh
> +        env:
> +          jobname: coverity
> +      - uses: vapier/coverity-scan-action@cae3c096a2eb21c431961a49375ac17aea2670ce
> +        with:
> +          email: ${{ secrets.COVERITY_SCAN_EMAIL }}
> +          token: ${{ secrets.COVERITY_SCAN_TOKEN }}
> +          command: make -j8

I ran the action and it worked out of the box for me (I have everything set up on the coverity side already from my custom workflow), modulo one hiccup. I initially had COVERITY_SCAN_EMAIL as a var, so the upload failed, complaining of an empty email.

But much to my surprise, the Action still succeeded. It didn't record the HTTP result code, so I'm not sure if we could detect this with "curl --fail-with-body" or if we'd have to scrape the output. It may not be that big a deal either way, though, since the coverity output really is useless until a human periodically scans over it (but it would be nice to know if it was routinely failing; I might not notice if it didn't).

-Peff