Hi Peff, On Sat, 23 Sep 2023, Jeff King wrote: > On Fri, Sep 22, 2023 at 10:41:59AM +0000, Johannes Schindelin via GitGitGadget wrote: > > > From: Johannes Schindelin <johannes.schindelin@xxxxxx> > > > > 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). I use `actions/cache` extensively, both in GitHub workflows via the Action as well as in custom Actions like `setup-git-for-windows-sdk`, so I am confident that I am using this tool correctly here, too. > > 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. I concur, after verifying that the scary manual page note about authentication issues often not being handled correctly by `curl --fail` does not affect this particular scenario. Ciao, Johannes
