Our current series of posts focuses on the migration of SonarQube and Jenkins from Tomcat to Windows services.

We have seen how to realize this migration for SonarQube, while still working with Jenkins on Tomcat. I mean, without losing our SonarQube repository, our dashboard, the results of our analysis, the profiles, etc. but also with the ability to launch projects already configured in Jenkins, and without losing any installed plugins, including the one used for the SonarQube Runner.

Today we will see how to migrate Jenkins to a Windows service. And finally get rid of that good old Tomcat. 

My configuration

First, a reminder of my configuration, from this article in Qualilogy: Installing SonarQube with Jenkins. In fact, I do not have quite the same configuration as the one you get by default, since I chose to install Tomcat on the port 8888 (to avoid conflicts with software that installs by default on the port 8080).

Also, I chose a specific working directory, and we will see that it will have some impact in the future.

Besides, I recommend to make a backup of it prior to any operation.

And also to stop Tomcat in order to avoid any confusion between our different Jenkins installations.

Installing Jenkins as a Windows service

If we go on the Jenkins home page, we can see that we can download it as a .war file or an auto-installer.

There are actually two ways to install Jenkins as a Windows service. The page that documents this installation on the Jenkins site is this one: https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+as+a+Windows+service.

This is not actually the installation I prefer, but as it is the official documentation, let’s go with this procedure.

For this, we download the file  jenkins.war  file corresponding to the latest version (1529 in our example). And I’ll save it in a directory ‘C:\Soft\Jenkins\Versions\1.529’.

Once the download is complete, we open a DOS window and we issue the command java -jar jenkins.war :

Note the installation in a directory ‘.jenkins’ created under the personal files of the current connected user. This is not really what I want because the rights to access these folders are limited and even if it has no impact on a personal installation on my laptop, it will not be the same for a Jenkins installation shared among multiple users with different logins.

Once the deployment of the .war file has ended …

… you can launch your preferred browser with the url http://localhost:8080/ (you understand why I use the port 8888 for Tomcat !). In the following Jenkins page, click on the menu ‘Manage Jenkins’.

In the following page, click on ‘Install as a Windows Service’.

This time, we are able to choose the directory of installation:

And I will choose to do it in the ‘C:\Soft\Jenkins’ folder, with a sub-directory specific to this version.

Eventually, a message is displayed to warn us that the installation completed correctly, and ask if we want to run the new Windows Jenkins service.

Jenkins is displayed into the Services window.

And if we have a look to its properties, we can see the executable in the folder mentioned previously during  the installation. But activating the ‘Start’ button does not lead to any expected result: Jenkins does not start.

In fact, this is the same problem than this one we met during the installation of SonarQube. 

Well, we must go to the tab ‘Log On’ in the Properties window and define ourselves as the user to start this service.

In this tab, select ‘This account:’ then the button ‘Browse…’.

Then the button ‘Advanced’,

then ‘Find Now’ to display a list of existing users.

Select a user with the adequate rights to start the Jenkins service, and validate.

And don’t forget to input his password.

We can now start the Jenkins Service without error, then again go to the Jenkins page ‘http://localhost:8080/’. One message asks for a little patience:

Then, after some seconds:

The Jenkins repository

Jenkins keeps its configuration and the different plugins used, all the jobs and the build files, in a directory specified by the environment variable ‘JENKINS_HOME’. The one we set in Tomcat. But as we do not use Tomcat anymore, we end up with a new repository initiated during the installation. How to get our existing repository with our current SonarQube analysis from our the new Jenkins service?

Jenkins recommends copying the existing directory to the new directory. In this case, the directory which I defined during the installation: ’C:\Soft\Jenkins\Versions\1.529\.jenkins’. But this is not what I want: I do not want to have to copy this directory every time I do an upgrade of Jenkins to a newer version.

What I want is that my new Jenkins service is able to work with my existing repository.

This is quite possible. Simply edit the file ‘jenkins.xml‘ present in the installation directory and indicate in the first section <service> the location of our existing repository:

You will need to restart the Jenkins service. Then after a few seconds, we get our Jenkins repository again, with its configuration and the SonarQube analysis.

So, think carefully about these two or three important points:

• The directory in which you want to keep the different versions of Jenkins that you will install over time. Necessary because you may want to return to an previous release. For instance: ‘C:\Soft\Jenkins\Versions’.
• The directory for the current version (in production), with the ‘jenkins.xml’ file pointing to …
• The working directory of Jenkins (or Jenkins Home) where are saved the différent configurations and SonarQube projects.

Now that you know how to manage these different folders, better think it a little before starting an installation or a migration like this one. Especially if you use a server shared between different users. Do not forget to look at the previous posts to get an overview of the different actions plan.

Finally, we can now uninstall Tomcat. Good job.

This post is also available in Leer este articulo en castellano and Lire cet article en français.