Upgrading the MSI over an existing install walks the operator through the full configuration UI again — controller URL, agent secret, security mode, and every Advanced Options field — as though it were a fresh install. It should ask only for what it does not already know, and ideally for nothing at all.
It is worse than an inconvenience: the answers are discarded
The config custom actions are gated on NOT Installed AND NOT WIX_UPGRADE_DETECTED:
https://github.com/EliorMachlev/JenkinsAsService/blob/main/src/JenkinsAsService.Installer/Package.wxs#L147-L154
On an upgrade, WriteConfig / WriteAdvanced1-3 / SetDataDir do not run — UpgradeConfig runs instead and reconciles the existing appsettings.json in place. That gating is correct and deliberate: it is what stops an upgrade from destroying a working configuration.
But the UI has no matching gate. ConfigDialog.wxs sequences JenkinsConfigDlg → SecurityOptionsDlg → AdvancedOptionsDlg unconditionally, and RequiredFieldDlg blocks Next until JENKINS_URL and JENKINS_SECRET are both non-empty. So an upgrade demands the operator re-type the controller URL and paste the agent secret again — and then throws all of it away.
Two concrete consequences:
- The secret is handled for no reason. It goes onto the
WriteConfig deferred CA command line (Hidden="yes", but still) on an upgrade path that will not call WriteConfig. Asking for a credential that will not be used is the wrong default for a product whose whole posture is about keeping that secret contained.
- It reads as data loss. Fields presenting blank on upgrade strongly implies the upgrade is about to overwrite the existing config. It is not, but an operator has no way to tell that from the screen, and the safe-looking move — carefully re-entering everything — is the one that wastes the most time.
VerifyReadyDlg's Back button is already gated on NOT Installed, so the upgrade case was partly anticipated; it just was not carried through the rest of the flow.
Proposed behaviour
On upgrade (WIX_UPGRADE_DETECTED set), skip the configuration dialogs entirely and go straight to VerifyReadyDlg. UpgradeConfig already preserves in-schema values and adds new keys at their POCO defaults via ServiceSettingsNormalizer, so a silent upgrade is the behaviour that matches what actually happens on disk.
If prompting for genuinely new settings is wanted later, that needs the current values loaded first — AppSearch + RegistrySearch, or reading them back out of the installed appsettings.json — so that fields render populated rather than blank. That is the larger change; the skip is the small one and fixes the misleading part.
Either way the outcome should hold: an upgrade never asks for the agent secret.
Acceptance
- Upgrading over an existing install presents no configuration prompts and preserves the existing config.
- A fresh install is unchanged.
Test-MsiLifecycle.ps1 covers the upgrade path silently, without supplying JENKINS_SECRET.
Upgrading the MSI over an existing install walks the operator through the full configuration UI again — controller URL, agent secret, security mode, and every Advanced Options field — as though it were a fresh install. It should ask only for what it does not already know, and ideally for nothing at all.
It is worse than an inconvenience: the answers are discarded
The config custom actions are gated on
NOT Installed AND NOT WIX_UPGRADE_DETECTED:https://github.com/EliorMachlev/JenkinsAsService/blob/main/src/JenkinsAsService.Installer/Package.wxs#L147-L154
On an upgrade,
WriteConfig/WriteAdvanced1-3/SetDataDirdo not run —UpgradeConfigruns instead and reconciles the existingappsettings.jsonin place. That gating is correct and deliberate: it is what stops an upgrade from destroying a working configuration.But the UI has no matching gate.
ConfigDialog.wxssequencesJenkinsConfigDlg → SecurityOptionsDlg → AdvancedOptionsDlgunconditionally, andRequiredFieldDlgblocks Next untilJENKINS_URLandJENKINS_SECRETare both non-empty. So an upgrade demands the operator re-type the controller URL and paste the agent secret again — and then throws all of it away.Two concrete consequences:
WriteConfigdeferred CA command line (Hidden="yes", but still) on an upgrade path that will not callWriteConfig. Asking for a credential that will not be used is the wrong default for a product whose whole posture is about keeping that secret contained.VerifyReadyDlg's Back button is already gated onNOT Installed, so the upgrade case was partly anticipated; it just was not carried through the rest of the flow.Proposed behaviour
On upgrade (
WIX_UPGRADE_DETECTEDset), skip the configuration dialogs entirely and go straight toVerifyReadyDlg.UpgradeConfigalready preserves in-schema values and adds new keys at their POCO defaults viaServiceSettingsNormalizer, so a silent upgrade is the behaviour that matches what actually happens on disk.If prompting for genuinely new settings is wanted later, that needs the current values loaded first —
AppSearch+RegistrySearch, or reading them back out of the installedappsettings.json— so that fields render populated rather than blank. That is the larger change; the skip is the small one and fixes the misleading part.Either way the outcome should hold: an upgrade never asks for the agent secret.
Acceptance
Test-MsiLifecycle.ps1covers the upgrade path silently, without supplyingJENKINS_SECRET.