On Fri, Sep 22, 2023 at 01:09:26PM +0200, Johannes Schindelin wrote: > While it is true that that Action caches the Coverity Tool, this GitHub > Action comes with a few non-niceties, too, one of them being that it > actually fails to do its job. Looking at > https://github.com/vapier/coverity-scan-action/blob/main/action.yml it can > be very easily verified that `cov-configure` is not called. But as > https://github.com/git-for-windows/git/actions/runs/6267593979/job/17020975444#step:9:12 > demonstrates, this command now _needs_ to be called: Hmm. I have been running Coverity for years without running cov-configure (using my own workflow), and I just tested Taylor's patch, which worked fine. I wonder what is different about our setups; maybe it is only an issue on the Windows version of Coverity? Or maybe it has to do with the project setup on Coverity's server side, since we have to provide the project name as part of the tool download (though I don't know if that is purely for logging/auditing on their side or if the delivered download is customized in any way). > Another issue I ran into: That Action defaults to using the URL-encoded > name of the repository (in our case, `git%2Fgit`) as Coverity project > name. That project does not exist, though, and the GitHub Action therefore > silently assumes an empty MD5 and attempts to extract a tar file that is > actually a text file instead, with the contents "Not found". It took me a minute to understand what you meant here, since the main use of the project name is for uploading our tarball. But we also must provide it (along with the token) just to download their scan software, so that step failed. And yes, I agree that the error checking in the Action could be better (I also mentioned elsewhere in the thread that it did not detect or report a failed upload). I'm not sure if it is easier to submit a patch there, or if we are better off just doing it all inline (it is not that much code either way). > Further, when I tried to specify `win64` as this GitHub Action's > `platform` input variable (whose existence suggests that platforms other > than `linux64` are allowed), it totally fell over, trying to untar a > `.zip` file. Hmm, yes, I hadn't really considered running Coverity with different build configurations. But I guess it needs to run code through the compiler to do its magic, so you'd want to be able to run it on a Windows build to hit any platform-specific code. For general git/git use, I'm not sure if we'd want to run it on multiple platforms, but I guess your plan would be to share the workflow code between git/ and git-for-windows/, and use a repo variable to select the platform for the latter. And for that case we can't rely on an Action which doesn't support Windows. I'll take a look at the patches you posted. -Peff
