From 712602c09e451c6c95b49b74c543817fd7477507 Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Wed, 11 Jun 2025 13:22:02 +0200 Subject: [PATCH 1/2] ci(coverity): fix building on Windows When I added the Coverity workflow in a56b6230d0b1 (ci: add a GitHub workflow to submit Coverity scans, 2023-09-25), I merely converted an Azure Pipeline definition that had been running successfully for ages. In the meantime, the current Coverity documentation describes a very different way to install the analysis tool, recommending to add the `bin/` directory to the _end_ of `PATH` (when originally, IIRC, it was recommended to add it to the _beginning_ of the `PATH`). This is crucial! The reason is that the current incarnation of the Windows variant of Coverity's analysis tools come with a _lot_ of DLL files in their `bin/` directory, some of them interferring rather badly with the `gcc.exe` in Git for Windows' SDK that we use to run the Coverity build. The symptom is a cryptic error message: make: *** [Makefile:2960: headless-git.o] Error 1 make: *** Waiting for unfinished jobs.... D:\git-sdk-64-minimal\mingw64\bin\windres.exe: preprocessing failed. make: *** [Makefile:2679: git.res] Error 1 make: *** [Makefile:2893: git.o] Error 1 make: *** [Makefile:2893: builtin/add.o] Error 1 Attempting to detect unconfigured compilers in build |0----------25-----------50----------75---------100| **************************************************** Warning: Build command make.exe exited with code 2. Please verify that the build completed successfully. Warning: Emitted 0 C/C++ compilation units (0%) successfully 0 C/C++ compilation units (0%) are ready for analysis For more details, please look at: D:/a/git/git/cov-int/build-log.txt The log (which the workflow is currently not configured to reveal) then points out that the `windows.h` header cannot be found, which is _still_ not very helpful. The underlying root cause is that the `gcc.exe` in Git for Windows' SDK determines the location of the header files via the location of certain DLL files, and finding the "wrong" ones first on the `PATH` misleads that logic. Let's fix this problem by following Coverity's current recommendation and append the `bin/` directory in which `cov-int` can be found to the _end_ of `PATH`. Signed-off-by: Johannes Schindelin --- .github/workflows/coverity.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml index 124301dbbe2fc1..d8a0497d596d4a 100644 --- a/.github/workflows/coverity.yml +++ b/.github/workflows/coverity.yml @@ -147,7 +147,7 @@ jobs: key: cov-build-${{ env.COVERITY_LANGUAGE }}-${{ env.COVERITY_PLATFORM }}-${{ steps.lookup.outputs.hash }} - name: build with cov-build run: | - export PATH="$RUNNER_TEMP/cov-analysis/bin:$PATH" && + export PATH="$PATH:$RUNNER_TEMP/cov-analysis/bin" && cov-configure --gcc && cov-build --dir cov-int make - name: package the build From 52c34977b48a26f3f6a1a62fb81015f319be6205 Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Wed, 11 Jun 2025 13:38:39 +0200 Subject: [PATCH 2/2] ci(coverity): output the build log upon error It is quite helpful to know what Coverity said, exactly, in case it fails to analyze the code. Signed-off-by: Johannes Schindelin --- .github/workflows/coverity.yml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml index d8a0497d596d4a..01a0437b2f2634 100644 --- a/.github/workflows/coverity.yml +++ b/.github/workflows/coverity.yml @@ -149,7 +149,11 @@ jobs: run: | export PATH="$PATH:$RUNNER_TEMP/cov-analysis/bin" && cov-configure --gcc && - cov-build --dir cov-int make + if ! cov-build --dir cov-int make + then + cat cov-int/build-log.txt + exit 1 + fi - name: package the build run: tar -czvf cov-int.tgz cov-int - name: submit the build to Coverity Scan