Hi Taylor, thank you for continuing your work on this. The timing is a bit unfortunate, though: As I had not heard back from you in this thread, I had started work yesterday morning on converting Git for Windows' corresponding Azure Pipeline to a GitHub workflow as a consequence. I had to leave some polishing for this morning because the validation that the workflow actually runs correctly and is versatile enough to address both the needs of the Git project as well as of the Git for Windows project took longer than anticipated and revealed a couple of problems on which I will elaborate below. On Thu, 21 Sep 2023, Taylor Blau wrote: > [...] using the vapier/coverity-scan Action comes with some additional > niceties, such as caching the (rather large) Coverity tool download > between runs. 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: Error: Could not find file coverity_config.xml in directory D:/a/_temp/cov-analysis/config The cov-build.exe command needs a configuration file, generated by cov-configure, to know how to capture analysis inputs based on compiler invocations and/or scanning the filesystem. Examples of running cov-configure: cov-configure --cs Microsoft C# compiler (csc) cov-configure --gcc GNU C/C++ compiler (gcc/g++) cov-configure --java Oracle Java compiler (javac) cov-configure --javascript *.js JavaScript source code cov-configure --msvc Microsoft C/C++ compiler (cl) See cov-configure documentation for more information. I had encountered this issue already in April last year and had addressed it in https://github.com/git-for-windows/build-extra/commit/cec961d2536c, so it came as an unwelcome surprise to me that this GitHub Action leaves this problem unaddressed. 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". 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. For this and for various other reasons detailed in the cover letter of https://lore.kernel.org/git/pull.1588.git.1695379323.gitgitgadget@xxxxxxxxx, it would appear that unfortunately that GitHub Action won't be helpful here. Ciao, Johannes
