Skip to content

Commit aea7c18

Browse files
pks-tgitster
authored andcommitted
gitlab-ci: fix "msvc-meson" test job succeeding despite test failures
We have recently noticed that the "msvc-meson" test job in GitLab CI succeeds even if there are failures. This is somewhat puzzling because we use exactly the same command as we do on GitHub Actions, and there the jobs fail as exected. As it turns out, this is another weirdness of the GitLab CI hosted runner for Windows [1]: by default, even successful commands will not make the job fail. Interestingly though, this depends on what exactly the command is that you're running -- the MinGW-based job for example works alright and does fail as expected. The root cause here seems to be specific behaviour of PowerShell. The invocation of `ForEach-Object` does not bubble up any errors in case the invocation of `meson test` fails, and thus we don't notice the error. This is specific to executing the command in a loop: other build steps where we execute commands directly fail as expected. This is because the specific version of PowerShell that we use in the runner does not know about `PSNativeCommandUseErrorActionPreference` yet, which controls whether native commands like "meson.exe" honor the `ErrorActionPreference` variable. The preference has been introduced with PowerShell 7.3 and is default-enabled since PowerShell 7.4, but GitLab's hosted runners still seem to use PowerShell 5.1. Consequently, when tests fail, we won't bubble up the error at all from the loop and thus the job doesn't fail. This isn't an issue in other cases though where we execute native commands directly, as the GitLab runner knows to check the last error code after every command. The same thing doesn't seem to be an issue on GitHub Actions, most likely because it uses PowerShell 7.4. Curiously, the preference for `PSNativeCommandUseErrorActionPreference` is disabled there, but the jobs fail as expected regardless of that. It's puzzling, but I do not have enough PowerShell expertise to give a definitive answer as to why it works there. In any case, Meson 1.8 will likely get support for slicing tests [1], so we can eventually get rid of the whole PowerShell script. For now, work around the issue by explicitly exiting out of the loop with a non-zero error code if we see that Meson has failed. [1]: mesonbuild/meson#14092 Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent 7304bd2 commit aea7c18

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

.gitlab-ci.yml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -184,7 +184,7 @@ test:msvc-meson:
184184
- job: "build:msvc-meson"
185185
artifacts: true
186186
script:
187-
- meson test -C build --list | Select-Object -Skip 1 | Select-String .* | Group-Object -Property { $_.LineNumber % $Env:CI_NODE_TOTAL + 1 } | Where-Object Name -EQ $Env:CI_NODE_INDEX | ForEach-Object { meson test -C build --no-rebuild --print-errorlogs $_.Group }
187+
- meson test -C build --list | Select-Object -Skip 1 | Select-String .* | Group-Object -Property { $_.LineNumber % $Env:CI_NODE_TOTAL + 1 } | Where-Object Name -EQ $Env:CI_NODE_INDEX | ForEach-Object { meson test -C build --no-rebuild --print-errorlogs $_.Group; if (!$?) { exit $LASTEXITCODE } }
188188
parallel: 10
189189

190190
test:fuzz-smoke-tests:

0 commit comments

Comments
 (0)