On Thu, Sep 21, 2023 at 05:53:31PM -0400, Taylor Blau wrote:
> 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.
> + 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
