Fix Coverity builds on Windows

From: Johannes Schindelin <[email protected]>

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.

---
 .github/workflows/coverity.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 124301dbbe2f..a5d99e59d4eb 100644
@@ -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:$(cygpath -au "$RUNNER_TEMP")/cov-analysis/bin" &&
           cov-configure --gcc &&
           cov-build --dir cov-int make
       - name: package the build

gitgitgadget

As of three weeks ago, Git for Windows' Coverity builds fail
[https://github.com/git-for-windows/git/actions/workflows/coverity.yml?query=branch%3Amain].

The reason is most likely the most recent Coverity release, 2025.3. Its release notes
[https://documentation.blackduck.com/bundle/coverity-docs/page/webhelp-files/relnotes_latest.html]
do not shed any light into the issue (and do not mention that they bundle JDK20 and JDK22 in addition to a JRE, because what's better than a single Java installation: three, right?).

My investigation turned up .dll files that are located in Coverity's bin/ directory which have the same name as .dll files in Git for Windows' SDK. As a consequence, the former override the latter and throw off MSYS2's logic to find the MSYS2 root directory given the location of certain .dll files.

This PR fixes this issue, and while at it, enhances the Coverity workflow to print out the build log in case of failure.

Johannes Schindelin (2):
ci(coverity): fix building on Windows
ci(coverity): output the build log upon error

 .github/workflows/coverity.yml | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

base-commit: 683c54c999c301c2cd6f715c411407c413b1d84e
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1934%2Fdscho%2Ffix-coverity-builds-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1934/dscho/fix-coverity-builds-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1934

gitgitgadget

From: Johannes Schindelin <[email protected]>

It is quite helpful to know what Coverity said, exactly, in case it fails to analyze the code.

---
 .github/workflows/coverity.yml | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

index a5d99e59d4eb..1e8bd85ecd4e 100644
@@ -149,7 +149,11 @@ jobs:
         run: |
           export PATH="$PATH:$(cygpath -au "$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

gitgitgadget

"Johannes Schindelin via GitGitGadget" <[email protected]>

Wow, that is a very well described change.

"Johannes Schindelin via GitGitGadget" <[email protected]>

Wonderful. Will queue, together with 1/2. Thanks.

Hi Junio,

I am delighted by your feedback which points out a functional problem. The cygpath -au is a left-over from some interactive debugging session where I _thought_ that RUNNER_TEMP contains a Windows path, and I wanted to make sure that it is a Unix-like path.

But yes, this is totally in a cross-platform part of the workflow (which is itself already guarded by that `if:
contains(fromJSON(vars.ENABLE_COVERITY_SCAN_FOR_BRANCHES || '[""]'), github.ref_name)` condition so that it is skipped in forks that did not enable this workflow explicitly.

As such, that cygpath call is incorrect, as it would fail on anything by Windows. It is also unnecessary, as I just verified in a manual run. Therefore I drop it from v2.

Thank you,
Johannes

As of three weeks ago, Git for Windows' Coverity builds fail
[https://github.com/git-for-windows/git/actions/workflows/coverity.yml?query=branch%3Amain].

The reason is most likely the most recent Coverity release, 2025.3. Its release notes
[https://documentation.blackduck.com/bundle/coverity-docs/page/webhelp-files/relnotes_latest.html]
do not shed any light into the issue (and do not mention that they bundle JDK20 and JDK22 in addition to a JRE, because what's better than a single Java installation: three, right?).

My investigation turned up .dll files that are located in Coverity's bin/ directory which have the same name as .dll files in Git for Windows' SDK. As a consequence, the former override the latter and throw off MSYS2's logic to find the MSYS2 root directory given the location of certain .dll files.

This patch series fixes this issue, and while at it, enhances the Coverity workflow to print out the build log in case of failure. It is a companion of
https://github.com/git-for-windows/git/pull/5672 and of
(https://github.com/microsoft/git/pull/764.

Changes since v1:

* Dropped unnecessary, non-portably cygpath call.

Johannes Schindelin (2):
ci(coverity): fix building on Windows
ci(coverity): output the build log upon error

 .github/workflows/coverity.yml | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

base-commit: 683c54c999c301c2cd6f715c411407c413b1d84e
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1934%2Fdscho%2Ffix-coverity-builds-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1934/dscho/fix-coverity-builds-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/1934

Range-diff vs v1:

1: c65120f2570 ! 1: 712602c09e4 ci(coverity): fix building on Windows

     @@ .github/workflows/coverity.yml: jobs:
             - name: build with cov-build
               run: |
      -          export PATH="$RUNNER_TEMP/cov-analysis/bin:$PATH" &&
     -+          export PATH="$PATH:$(cygpath -au "$RUNNER_TEMP")/cov-analysis/bin" &&
     ++          export PATH="$PATH:$RUNNER_TEMP/cov-analysis/bin" &&
                 cov-configure --gcc &&
                 cov-build --dir cov-int make
             - name: package the build

2: 3a829f11c07 ! 2: 52c34977b48 ci(coverity): output the build log upon error
@@ Commit message
## .github/workflows/coverity.yml ##
@@ .github/workflows/coverity.yml: jobs:
run: |
- export PATH="$PATH:$(cygpath -au "$RUNNER_TEMP")/cov-analysis/bin" &&
+ export PATH="$PATH:$RUNNER_TEMP/cov-analysis/bin" &&
cov-configure --gcc &&
- cov-build --dir cov-int make
+ if ! cov-build --dir cov-int make

gitgitgadget

From: Johannes Schindelin <[email protected]>

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.

---
 .github/workflows/coverity.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 124301dbbe2f..d8a0497d596d 100644
@@ -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

gitgitgadget

From: Johannes Schindelin <[email protected]>

It is quite helpful to know what Coverity said, exactly, in case it fails to analyze the code.

---
 .github/workflows/coverity.yml | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

index d8a0497d596d..01a0437b2f26 100644
@@ -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

gitgitgadget

Great. Thanks. Will replace with v2.