From: Jeff King <peff@peff.net>
Date: Sat, 23 Sep 2023 06:58:13 GMT
Subject: Re: [PATCH 2/6] coverity: cache the Coverity Build Tool
Message-ID: <20230923065813.GC1469941@coredump.intra.peff.net>
In-Reply-To: <8420a76eba3eba3afdc7747af6d609ad8dbd8cb6.1695379323.git.gitgitgadget@gmail.com>

On Fri, Sep 22, 2023 at 10:41:59AM +0000, Johannes Schindelin via GitGitGadget wrote:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> It would add a 1GB+ download for every run, better cache it.
> 
> This is inspired by the GitHub Action `vapier/coverity-scan-action`,
> however, it uses the finer-grained `restore`/`save` method to be able to
> cache the Coverity Build Tool even if an unrelated step in the GitHub
> workflow fails later on.

Nice. This is the big thing that I think the vapier action was providing
us, and it does not look too bad. I have never used actions/cache
before, but it all looks plausibly correct to me (and I assume you did a
few test-runs to check it).

One note:

> +      # The Coverity site says the tool is usually updated twice yearly, so the
> +      # MD5 of download can be used to determine whether there's been an update.
> +      - name: get the Coverity Build Tool hash
> +        id: lookup
> +        run: |
> +          MD5=$(curl https://scan.coverity.com/download/$COVERITY_LANGUAGE/$COVERITY_PLATFORM \
> +                   --data "token=${{ secrets.COVERITY_SCAN_TOKEN }}&project=$COVERITY_PROJECT&md5=1")
> +          echo "hash=$MD5" >>$GITHUB_OUTPUT

We probably want --fail here, too (and presumably &&-chaining) so that
we don't accidentally write a bogus cache entry. Possibly even check
that $MD5 isn't blank if we want to be double-paranoid.

That made me wonder: if we do end up with a bogus cache entry, how does
one clear it? And it looks like it can be managed directly via
https://github.com/$user/$project/actions/caches. Nice.

-Peff