Windows MSI build: run light.exe with -sval in GitLab #10309

Al2Klimov · 2025-01-20T12:14:04Z

This is equivalent to "setting true in your WiX MSBuild project" not to require the CI/CD service to run as an admin. https://wixtoolset.org/docs/tools/validation/#errors-running-validation

Don't get me wrong. I've even re-tested On Windows, don't create C:\Program Files\Icinga2\var during MSI build #10137 and it does what it specifies.

It's just, w/o this PR our builds also perform a "package validation" which involves the installer service. Non-admins can access the latter, but only if logged in via RDP. Services can't.

Al2Klimov · 2025-01-20T12:22:58Z

Test

GitLab runner Windows service (not RDP logged in user!) runs these (not admin!) to build Icinga:

& .\tools\win32\load-vsenv.ps1
& powershell.exe .\tools\win32\configure.ps1
& powershell.exe .\tools\win32\build.ps1

Before

~~https://git.icinga.com/packaging/windows-icinga2/-/pipelines/35363~~
https://git.icinga.com/packaging/windows-icinga2/-/jobs/638022

...
CPack: Create package using WIX
  CPack: Install projects
  CPack: - Install project: icinga2 [RelWithDebInfo]
  CPack: Create package
EXEC : CPack error : Problem running WiX candle. Please check 'C:/Build/builds/t3_feTz7p/1/packaging/windows-icinga2/icinga2/Build/_CPack_Packages/win64/WIX/wix.log' for errors. [C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build\PACKAGE.vcxproj]
EXEC : CPack error : Fatal WiX Generator Error [C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build\PACKAGE.vcxproj]
EXEC : CPack error : Problem compressing the directory [C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build\PACKAGE.vcxproj]
EXEC : CPack error : Error when generating package: Icinga 2 [C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build\PACKAGE.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: Der Befehl "setlocal [C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build\PACKAGE.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: cd C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build [C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build\PACKAGE.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd [C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build\PACKAGE.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: C: [C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build\PACKAGE.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd [C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build\PACKAGE.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: "C:\Program Files\CMake\bin\cpack.exe" -C RelWithDebInfo --config ./CPackConfig.cmake [C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build\PACKAGE.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd [C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build\PACKAGE.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: :cmEnd [C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build\PACKAGE.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone [C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build\PACKAGE.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: :cmErrorLevel [C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build\PACKAGE.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: exit /b %1 [C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build\PACKAGE.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: :cmDone [C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build\PACKAGE.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd [C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build\PACKAGE.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: :VCEnd" wurde mit dem Code 1 beendet. [C:\Build\builds\t3_feTz7p\1\packaging\windows-icinga2\icinga2\Build\PACKAGE.vcxproj]
DEBUG:   27+ if ( >>>> $lastexitcode -ne 0) { exit $lastexitcode }
DEBUG:   27+ if ($lastexitcode -ne 0) {  >>>> exit $lastexitcode }
DEBUG:   20+ if ( >>>> $LastExitCode -ne 0) { throw "Error during build" }
DEBUG:   20+ if ($LastExitCode -ne 0) {  >>>> throw "Error during build" }
Error during build
In C:\build\builds\t3_feTz7p\1\packaging\windows-icinga2\build.ps1:20 Zeichen:28
+ if ($LastExitCode -ne 0) { throw "Error during build" }
+                            ~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Error during build:String) [], RuntimeException
    + FullyQualifiedErrorId : Error during build

After

~~https://git.icinga.com/packaging/windows-icinga2/-/pipelines/35364~~
https://git.icinga.com/packaging/windows-icinga2/-/jobs/638026

Works. 👍

julianbrost · 2025-01-20T13:34:28Z

That doesn't seem to be an issue on GitHub Actions, so can we disable this just in the GitLab pipelines? I mean what it does sounds useful (from your link):

Package validation checks the content of MSI packages to, among other things, ensure the internal database structure follows (at least some of) the rules for MSI packages.

So doesn't sound like a bad idea to try to keep this where possible.

CMakeLists.txt

julianbrost · 2025-01-21T14:09:21Z

CMakeLists.txt

+if(DEFINED ENV{GITLAB_CI})
+  # https://wixtoolset.org/docs/tools/validation/#errors-running-validation
+  set(CPACK_WIX_LIGHT_EXTRA_FLAGS "-sval")
+endif()


That change suggests it is actually impossible to do this validation while running in the GitLab CI. However, that's not the case as we did just that for years.

This is a problem that only appeared due to planned changes to our GitLab runners, hence, that's where I'd try to adjust this. Is it possible to just pass this as -DCPACK_WIX_LIGHT_EXTRA_FLAGS=-sval to CMake in our GitLab job definition instead?

That change suggests it is actually impossible to do this validation while running in the GitLab CI. However, that's not the case as we did just that for years.

... as administrator! Only that made it possible for all these things to happen under a Windows service. 😅🙈😈

This is a problem that only appeared due to planned changes to our GitLab runners, hence, that's where I'd try to adjust this.

IMAO the problem has always been in this repo. It unnecessarily enforces such privileges for GitLab runners.

Is it possible to just pass this as -DCPACK_WIX_LIGHT_EXTRA_FLAGS=-sval to CMake in our GitLab job definition instead?

Yes, but actually no:

.gitlab-ci.yml (GitLab) calls build.ps1 (GitLab) (https://git.icinga.com/packaging/windows-icinga2/-/blob/6895e808d82b4983dcdaac21b3749f68355424e2/.gitlab-ci.yml#L20)

build.ps1 (GitLab) calls tools\win32\configure.ps1 (GitHub) (https://git.icinga.com/packaging/windows-icinga2/-/blob/6895e808d82b4983dcdaac21b3749f68355424e2/build.ps1#L14)

tools\win32\configure.ps1 calls CMake (

icinga2/tools/win32/configure.ps1

Line 59 in 866db3b

& cmake.exe "$sourcePath" `

)

I mean, I can put this flag and env check into tools\win32\configure.ps1 if you explain why*. But that would be in the very same repo.

*) IMAO CMake stuff belongs into CMake files, especially sane defaults which apply universally, across callers of CMake.

IMAO the problem has always been in this repo. It unnecessarily enforces such privileges for GitLab runners.

If this repo doesn't allow to disable this externally, that should be fixed. With your proposed change, it unnecessarily prevents performing that validation from GitLab CI altogether.

I mean, I can put this flag and env check into tools\win32\configure.ps1 if you explain why*. But that would be in the very same repo.

Why does it have to be a check on the GITLAB_CI environment variable here? What if the following would just allow passing custom CMake options?

icinga2/tools/win32/configure.ps1

Lines 59 to 66 in 866db3b

& cmake.exe "$sourcePath" `

-DCMAKE_BUILD_TYPE="$env:CMAKE_BUILD_TYPE" `

-G "$env:CMAKE_GENERATOR" -A "$env:CMAKE_GENERATOR_PLATFORM" -DCPACK_GENERATOR=WIX `

-DOPENSSL_ROOT_DIR="$env:OPENSSL_ROOT_DIR" `

-DBOOST_LIBRARYDIR="$env:BOOST_LIBRARYDIR" `

-DBOOST_INCLUDEDIR="$env:BOOST_ROOT" `

-DFLEX_EXECUTABLE="$env:FLEX_BINARY" `

-DBISON_EXECUTABLE="$env:BISON_BINARY"

With your proposed change, it unnecessarily prevents performing that validation from GitLab CI altogether.

Why does it have to be a check on the GITLAB_CI environment variable here?

It necessarily prevents it because in a sane CI infra the GitLab service is not run as admin, which makes MSI validation impossible. So what? We have GitHub actions for this, as you said.

What if the following would just allow passing custom CMake options?

icinga2/tools/win32/configure.ps1

Lines 59 to 66 in 866db3b

& cmake.exe "$sourcePath" `

-DCMAKE_BUILD_TYPE="$env:CMAKE_BUILD_TYPE" `

-G "$env:CMAKE_GENERATOR" -A "$env:CMAKE_GENERATOR_PLATFORM" -DCPACK_GENERATOR=WIX `

-DOPENSSL_ROOT_DIR="$env:OPENSSL_ROOT_DIR" `

-DBOOST_LIBRARYDIR="$env:BOOST_LIBRARYDIR" `

-DBOOST_INCLUDEDIR="$env:BOOST_ROOT" `

-DFLEX_EXECUTABLE="$env:FLEX_BINARY" `

-DBISON_EXECUTABLE="$env:BISON_BINARY"

CMake allows passing custom CMake options. This is a convenience script, its job is to fiddle together CMake options which CMake itself can't.

With your proposed change, it unnecessarily prevents performing that validation from GitLab CI altogether.

Why does it have to be a check on the GITLAB_CI environment variable here?

It necessarily prevents it because in a sane CI infra the GitLab service is not run as admin, which makes MSI validation impossible. So what? We have GitHub actions for this, as you said.

Well now I'm tempted to try whether your jobs run with admin privileges on the GitLab.com hosted Windows runners and whether you just called their infrastructure insane. 😅

What if the following would just allow passing custom CMake options?

icinga2/tools/win32/configure.ps1

Lines 59 to 66 in 866db3b

& cmake.exe "$sourcePath" `

-DCMAKE_BUILD_TYPE="$env:CMAKE_BUILD_TYPE" `

-G "$env:CMAKE_GENERATOR" -A "$env:CMAKE_GENERATOR_PLATFORM" -DCPACK_GENERATOR=WIX `

-DOPENSSL_ROOT_DIR="$env:OPENSSL_ROOT_DIR" `

-DBOOST_LIBRARYDIR="$env:BOOST_LIBRARYDIR" `

-DBOOST_INCLUDEDIR="$env:BOOST_ROOT" `

-DFLEX_EXECUTABLE="$env:FLEX_BINARY" `

-DBISON_EXECUTABLE="$env:BISON_BINARY"

CMake allows passing custom CMake options. This is a convenience script, its job is to fiddle together CMake options which CMake itself can't.

I've linked that script because my question was about that script allowing additional custom CMake options.

Well now I'm tempted to try whether your jobs run with admin privileges on the GitLab.com hosted Windows runners and whether you just called their infrastructure insane. 😅

I talked about "the GitLab service"!

I've linked that script because my question was about that script allowing additional custom CMake options.

I don't see a point in custom ones, but I can offer you #10309 (comment) if you really care about hypothetic stuff.

I talked about "the GitLab service"!

Why is this relevant? Aren't the build job permission what matters here?

…TION is set This is equivalent to "setting <SuppressValidation>true</SuppressValidation> in your WiX MSBuild project" not to require a CI/CD service to run as an admin. https://wixtoolset.org/docs/tools/validation/#errors-running-validation

Al2Klimov · 2025-01-21T15:51:07Z

CMakeLists.txt

@@ -509,6 +509,11 @@ set(CPACK_WIX_PATCH_FILE "${CMAKE_CURRENT_BINARY_DIR}/icinga-installer/icinga2.w
 set(CPACK_WIX_EXTENSIONS "WixUtilExtension" "WixNetFxExtension")
 set(CPACK_WIX_INSTALL_SCOPE NONE)

+if(DEFINED ENV{GITLAB_CI})


Suggested change

if(DEFINED ENV{GITLAB_CI})

if(DEFINED ENV{ICINGA2_NO_MSI_VALIDATION})

Better?

ICINGA2_NO_MSI_VALIDATION is better than hard-coded GITLAB_CI. Though that being an environment variable there looks a bit odd. None of the other ICINGA2_* options are environment variables but rather regular CMake options. Also, with tools/win32/configure.ps1, there's a script for mapping environment to CMake options.

So I'd rather do something like if (env:ICINGA2_NO_MSI_VALIDATION) CMAKE_OPTS+=DCPACK_WIX_LIGHT_EXTRA_FLAGS=-sval in tools/win32/configure.ps1, or, preferably unless that gets a complete whitespace quoting nightmare - just allow setting any options so that if additional CMake options are needed in the future, this doesn't need another pull request (+ backports) here.

Al2Klimov added the area/windows Windows agent and plugins label Jan 20, 2025

Al2Klimov added this to the 2.15.0 milestone Jan 20, 2025

Al2Klimov requested a review from julianbrost January 20, 2025 12:14

cla-bot bot added the cla/signed label Jan 20, 2025

Al2Klimov force-pushed the win-light-sval branch from 36d0daa to bcdb5f9 Compare January 20, 2025 14:03

Al2Klimov changed the title ~~Windows MSI build: run light.exe with -sval~~ Windows MSI build: run light.exe with -sval in GitLab Jan 20, 2025

Al2Klimov commented Jan 20, 2025

View reviewed changes

CMakeLists.txt Outdated Show resolved Hide resolved

Al2Klimov assigned julianbrost Jan 21, 2025

julianbrost reviewed Jan 21, 2025

View reviewed changes

Al2Klimov requested a review from julianbrost January 21, 2025 15:01

Al2Klimov commented Jan 21, 2025

View reviewed changes

Al2Klimov force-pushed the win-light-sval branch from bcdb5f9 to 2438339 Compare January 21, 2025 16:54

Al2Klimov mentioned this pull request Jan 21, 2025

tools/win32/configure*.ps1: allow custom $CMAKE_ARGS (JSON array) #10312

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Windows MSI build: run light.exe with -sval in GitLab #10309

Windows MSI build: run light.exe with -sval in GitLab #10309

Al2Klimov commented Jan 20, 2025

Al2Klimov commented Jan 20, 2025 •

edited

Loading

julianbrost commented Jan 20, 2025

julianbrost Jan 21, 2025

Al2Klimov Jan 21, 2025

julianbrost Jan 21, 2025

Al2Klimov Jan 21, 2025

julianbrost Jan 21, 2025

Al2Klimov Jan 21, 2025

julianbrost Jan 21, 2025

Al2Klimov Jan 21, 2025

julianbrost Jan 21, 2025

	& cmake.exe "$sourcePath" `
	-DCMAKE_BUILD_TYPE="$env:CMAKE_BUILD_TYPE" `
	-G "$env:CMAKE_GENERATOR" -A "$env:CMAKE_GENERATOR_PLATFORM" -DCPACK_GENERATOR=WIX `
	-DOPENSSL_ROOT_DIR="$env:OPENSSL_ROOT_DIR" `
	-DBOOST_LIBRARYDIR="$env:BOOST_LIBRARYDIR" `
	-DBOOST_INCLUDEDIR="$env:BOOST_ROOT" `
	-DFLEX_EXECUTABLE="$env:FLEX_BINARY" `
	-DBISON_EXECUTABLE="$env:BISON_BINARY"

	if(DEFINED ENV{GITLAB_CI})
	if(DEFINED ENV{ICINGA2_NO_MSI_VALIDATION})

Windows MSI build: run light.exe with -sval in GitLab #10309

Are you sure you want to change the base?

Windows MSI build: run light.exe with -sval in GitLab #10309

Conversation

Al2Klimov commented Jan 20, 2025

Al2Klimov commented Jan 20, 2025 • edited Loading

Test

Before

After

julianbrost commented Jan 20, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Al2Klimov commented Jan 20, 2025 •

edited

Loading