SonarQube quality gate feedback in a Slack channel

Well it is easy to agree on that Slack is awesome for team collaboration and with the hooks it has available it is rather easy to get some decent feedback into the team channels.

There is a Jenkins CI plugin available for Slack that pushes build notifications into a given channel. But that merely pushes what Jenkins provides, failed, unstable asf.. If you are working with SonarQube and want to know a bit more than if the build turned unstable, then there is an additional Jenkins plugin available for you, SonarQube-Slack-Pusher

… which would push a notification like this in a Slack channel.

sonar-slack-pusher-notification

What needs to be in place

  1. QualityGate for a SonarQube project
  2. Incoming WebHook integration to your Slack channel
  3. Installed Jenkins plugin, Sonar-Slack-Pusher
  4. Configured Jenkins job pushing to Slack

Quality gates
The notification above highlights a quality gate that has failed in SonarQube. A quality gate is a way of highlighting that we are not meeting expected quality criteria for a SonarQube project. In the SonarQube UI this is visualised by read and yellow highlighting and could be things like warnings in the code or not enough unit test coverage.

Well, yes a quality gate needs to be defined in SonarQube. It could be linked to an existing project already but it is also possible to pass the quality gate as a part of running a SonarQube analysis job.

Configure the Slack channel
The SonarQube project/’quality gate’ and the Slack channel is there. Add an Incoming WebHook to the channel and note down the hook URL, you will need it when configuring the Jenkins job, you will also need channel admin rights to perform this step.

Pushing quality gate information from Jenkins to the Slack channel
Assuming that there is a Jenkins job that triggers and runs a SonarQube pipeline, i.e. pushing the results to SonarQube. Add the Sonar-Slack-Pusher plugin to your Jenkins installation and add the corresponding Post-build Action to she SonarQube job.

Configure it to use

  • hook URL given when configuring the Slack WebHook
  • sonar URL
  • SonarQube job name and if using branches add that as well.

jenkins-config

Bam all set! Run the job and if you have any failing quality gates you will get a notification in your channel.

Setting up a Jenkins slave for Sikuli based tests

To be able to use the full power of Sikuli based test cases they have to work in the ‘bigger’ picture, running countinuosly in a Jenking master/slave setup. This post will go through the steps we needed to take to get Jenkins slaves (running Windows 7) to execute Sikuli based tests reliably in a larger Jenkins setup.

Covered …

  • Creating the local user
  • Disabling screen savers
  • Disabling screen lock
  • Hooking up the slave to the master

Basic requirements for a Sikuli test execution slave

To be able to use a Windows 7 based Jenkins slave for running Sikuli based tests there are a few things that needs to be understood first.

As soon as the the current user on a machine gets logged out or gets its screen locked any Sikuli based tests will stop working. Secondly to be able to run tests triggered through Jenkins the executing user (the user that runs the Jenkins process) needs to have access to the desktop to be able to run applications like browsers in a visible way. Running Jenkins as a web service in Windows 7 will prohibit visible execution of applications or in other words the service is not allowed to access the desktop. Meaning that things are not as simple as starting Jenkins as a Windows service and then hook it up to the Jenkins master. Java web start (JNLP) is the way to go.

Requirements in short …

  • local user that is always logged on
  • machine that never gets locked
  • node that connects to the Jenkins master using Java web start (JNLP)
  • Java and environment variables configured properly to run Sikuli-based test cases (here)

Getting the local user in place

1) Create a local superuser account on the slave node.

2) Set the following keys in the registry to ensure that the user never gets logged out.

Open the registry editor (regedit) and add a new DWORD as named DisableLockWorkstation and give it the value 1 (1 = disable) to the path below.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System

3) It also has to be made sure that the local user always gets logged on automatically if the physical machine gets restarted. Open the following entry in the registry editor.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Make sure the following keys are present and that they are set accordingly.

AutoAdminLogon Value : 1
DefaultPassword Value : 'the password set for the created local super user'
DefaultUsername Value : 'the super user name'

Reboot to try it out.

Disabling all screen savers

One again using the registry, set the ScreenSaveActive key to 0 in the location below.

HKEY_CURRENT_USER\Control Panel\Desktop

Connecting to Jenkins master

1) On the test execution slave, open any browser that has java support
2) Navigate to the URL of the Jenkins master
3) Manage Jenkins -> Manage Nodes
4) Add a new node
5) Select the new node and click on the Launch button to connect to the master using JNLP, if the node already has all the correct Java installations and environment variables we are set to go (here).

JNLP connection launch button as seen in Jenkins

Troubleshooting

Firewalls, getting the JNLP connection to work might need changes in firewalls. Jenkins is by default configured to use a randomly generated port for the JNLP connection. Change this setting to use a fixed port number then there should not be to big of a trouble getting the firewall rules in place.

Manage Jenkins -> Configure System