Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-65754

Add MSI parameter to not auto-start Jenkins service

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Trivial
    • Resolution: Unresolved
    • Component/s: packaging
    • Labels:
      None
    • Environment:
      Windows
    • Similar Issues:

      Description

      Based on https://github.com/jenkinsci/packaging/blob/master/msi/build/jenkins.wxs, it seems that the MSI installer automatically starts the Jenkins service as soon as it is created.

      I am looking script/orchestrate the install of Jenkins and want to adjust some settings through system properties (https://www.jenkins.io/doc/book/managing/system-properties/) before Jenkins starts and the JENKINS_HOME directory is populated, 

        Attachments

          Activity

          Hide
          dgilbert David Gilbert` added a comment -

          Hi Ankush,

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

          Thanks,

          Davod

          Show
          dgilbert David Gilbert` added a comment - Hi Ankush, Just checking in on whether you'd had any thoughts about how to implement this change? Thanks, Davod
          Hide
          kon Kalle Niemitalo added a comment -

          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.

          Show
          kon Kalle Niemitalo added a comment - 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.
          Hide
          kon Kalle Niemitalo added a comment -

          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.

          Show
          kon Kalle Niemitalo added a comment - 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.
          Hide
          kon Kalle Niemitalo added a comment -

          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.
          Show
          kon Kalle Niemitalo added a comment - 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.
          Hide
          dgilbert David Gilbert` added a comment -

          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?

          Show
          dgilbert David Gilbert` added a comment - 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: Install prerequisite software packages (Java JRE/JDK, etc) Install Jenkins Set startup properties Start Jenkins Install Jenkins plugins (via jenkins-cli or REST API) Configure Jenkins settings (probably REST API) 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?

            People

            Assignee:
            ankushbarkade Ankush
            Reporter:
            dgilbert David Gilbert`
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated: