patch, 2 partsci(coverity): fix building on Windows

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

From: Johannes Schindelin <johannes.schindelin@gmx.de>

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 <johannes.schindelin@gmx.de>
---
 .github/workflows/coverity.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:

Wow, that is a very well described change.

Additionally two things are lacking explanation in the proposed log message, though, or an uninitiated will still be left scratching his head:

 - Why didn't the original need "cygpath -au"?

 - Even though many steps in this job deals with different
   env.COVERITY_PLATFORM, this part does not seem to be conditional.
   Why is $(cygpath -au ...) safe outside Windows environment?

Other than that, nicely done and very nicely explained.

Hi Junio,

On Wed, 11 Jun 2025, Junio C Hamano wrote:

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Great.  Thanks.  Will replace with v2.

From: Johannes Schindelin <johannes.schindelin@gmx.de>

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

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 .github/workflows/coverity.yml | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:

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

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

From: Johannes Schindelin <johannes.schindelin@gmx.de>

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 <johannes.schindelin@gmx.de>
---
 .github/workflows/coverity.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

From: Johannes Schindelin <johannes.schindelin@gmx.de>

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

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 .github/workflows/coverity.yml | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)