When I added the Coverity workflow in a56b623 (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 <[email protected]>

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

Signed-off-by: Johannes Schindelin <[email protected]>

The bug is actually dotnet/install-scripts#610
and it seems that _somehow_ the logic to determine the latest version is
broken with cURL v8.14.0.

Hard-coding the latest version seems to fix this.

Note: https://dotnet.microsoft.com/en-us/download/dotnet/3.1 says that
v3.1.426 is the latest. This site also says that .NET Core 3.1 is out of
support, and therefore it is unlikely that a different "latest" version
is going to materialize, like, ever.

Signed-off-by: Johannes Schindelin <[email protected]>

The bug that lets every single Scalar Functional Test run fail in the
`macos` matrix job is actually
dotnet/install-scripts#610 and it seems that
_somehow_ the logic to determine the latest version is broken with cURL
v8.14.0.

Hard-coding the latest version seems to fix this.

Note: https://dotnet.microsoft.com/en-us/download/dotnet/3.1 says that
v3.1.426 is the latest. This site also says that .NET Core 3.1 is out of
support, and therefore it is unlikely that a different "latest" version
is going to materialize, like, ever.

As of three months ago, the [Coverity builds
fail](https://github.com/microsoft/git/actions/workflows/coverity.yml?query=branch%3Avfs-2.49.0).

The reason is most likely the most recent 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 does not mention that they
bundle JDK20 and JDK22 in addition to 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, which is a companion of
git-for-windows#5672, fixes this issue, and
while at it, enhances the Coverity workflow to print out the build log
in case of failure.

On Linux, the following command would cause the terminal to be stuck
waiting:

  git fetch origin foobar

The issue would be that the fetch would fail with the error

  fatal: couldn't find remote ref foobar

but the underlying git-gvfs-helper process wouldn't die. The
`subprocess_exit_handler()` method would close its stdin and stdout, but
that wouldn't be enough to cause the process to end, even though the
`packet_read_line_gently()` call that is run in `do_sub_cmd__server()`
in a loop should return -1 and the process should the terminate
peacefully.

While it is unclear why this does not happen, there may be other
conditions where the `gvfs-helper` process would not terminate. Let's
ensure that the gvfs-helper-client process cleans up the gvfs-helper
server processes that it spawned upon exit.

Reported-by: Stuart Wilcox Humilde <[email protected]>
Co-authored-by: Johannes Schindelin <[email protected]>
Signed-off-by: Derrick Stolee <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>

On Linux, the following command would cause the terminal to be stuck
waiting:

```
  git fetch origin foobar
```

The issue would be that the fetch would fail with the error

```
  fatal: couldn't find remote ref foobar
```

but the underlying `git-gvfs-helper` process wouldn't die. The
`subprocess_exit_handler()` method would close its stdin and stdout, but
that wouldn't be enough to cause the process to end.

This PR addresses that by skipping the `finish_command()` call of the
`clean_on_exit_handler` and instead lets `cleanup_children()` send a
SIGTERM to terminate those spawned child processes.