Hi Ankush,

Just checking in on whether you'd had any thoughts about how to implement this change?

Thanks,

Davod

I have some experience with Windows Installer and WiX Toolset but it has been a while.

I think the easiest way would be to move Start="install" from the ServiceControl element in the Main component, to another ServiceControl element in a new Component in a new Feature "StartService". The orchestration could then run something like "msiexec.exe jenkins.msi ADDLOCAL=ALL REMOVE=StartService".

Alternatively, one could place the new Component in the existing Feature "Complete" and give the Component a Condition that checks a public property defined for this purpose, e.g. START_JENKINS.

The new Component would need something as its a key path, or perhaps it could just have Guid="" so that Windows Installer would not even remember installing it. That should be OK because there would be nothing to uninstall.

A third alternative would be to remove Start="install" altogether and instead start the service with a custom action, which could then be made conditional. However, I don't recommend this because error handling would be much more difficult that way.

Thinking about this some more. If a major upgrade to Jenkins is later installed using an MSI package, then Windows Installer can run MigrateFeatureStates and try to install the same features as in the previously installed version. However, I think server administrators would expect the service to restart automatically after the major upgrade, even if the original installation did not start the service immediately. In this respect, it might be better to use a component condition than a feature whose state Windows Installer would remember.

This part of the installer opens a Web browser at the Jenkins localhost URL after the installation is complete: https://github.com/jenkinsci/packaging/blob/f812e960abaa36cf45aba7d7e14b5a0565c1a9bd/msi/build/jenkins.wxs#L463-L464

If the installer does not start the service, then I think this should be skipped because the Web page won’t be available. On the other hand:

• If the option not to start the service were implemented as a feature, so that the msiexec command line has to use ADDLOCAL=ALL REMOVE=StartService, then the current NOT Installed AND NOT REMOVE condition would not need to be changed. It would evaluate to false because the REMOVE property would not be empty.
• If you are scripting the Jenkins install, I presume you disable the whole UI sequence anyway.

Hi Kalle,

Thanks for your advice about this - you clearly have been digging this a lot more than I have with my quick-shot random request!

Your presumption that I want to disable the whole UI sequence is correct - this would be a scripted install initiated by a Configuration Management system. At a high level, the install sequence is:

1. Install prerequisite software packages (Java JRE/JDK, etc)
2. Install Jenkins
3. Set startup properties
4. Start Jenkins
5. Install Jenkins plugins (via jenkins-cli or REST API)
6. Configure Jenkins settings (probably REST API)
7. Configure jobs (via jenkins-cli or REST API)

In this particular pipeline, there's not many jobs, they're not very complicated and it's not mission-critical. Consequentially, the view is that this environment is mostly disposable. When/if any issues arise, the environment will be destroyed and re-created using the CM system.

Since raising this issue, I have realised that I can manually assemble the various components through the CM system, bypassing the installer completely. While probably not ideal, it addresses my immediate need, therefore I have downgraded the priority on this issue to Trivial.

Perhaps this issue can be fed into the next major update?

See https://github.com/jenkinsci/packaging/pull/219

PR was merged