Jenkins integration

Watch this video to learn how to integrate Leapwork with Jenkins

In this video

  • Get an overview of the Leapwork – Jenkins integration
  • How to install the Leapwork plugin in Jenkins
  • How to setup a build in Jenkins that triggers test cases in Leapwork
  • How to get the results of the test cases returned to Jenkins


Watch this video to learn how to integrate Leapwork with Jenkins

In this video

  • Get an overview of the Leapwork – Jenkins integration
  • How to install the Leapwork plugin in Jenkins
  • How to setup a build in Jenkins that triggers test cases in Leapwork
  • How to get the results of the test cases returned to Jenkins

Jenkins is a very popular tool to orchestrate and administer build and release pipelines. Test automation is growing into a tool like Jenkins, and the community around Leapwork has build a native Jenkins plugin, that makes it very simple to trigger test cases in Leapwork to run.

This video includes the following:

  • An overview of the integration between Jenkins and Leapwork (click on thumbnail to download overview slide).
     Leaptest Jenkins integration overview
  • Downloading the Leapwork native Jenkins plugin from the GitHub repository (link:
  • Install the Leapwork plugin on a Jenkins server
  • Create a project and a build definition including the Leapwork plugin as a build step
  • Configure the Leapwork build step and get a brief introduction to schedules in Leapwork
  • Trigger test cases to run on cloud hosted machines from a build in Jenkins.
  • Inspect test results in Jenkins.


In this video I’ll show you how to install, configure and run automated test cases defined in Leaptest as part of a Jenkins build definition.

The community around Leaptest has developed an OpenSource native plugin for Jenkins that allows easy integration to Leaptest, and I will walk you through the steps involved in making it run. I’ll start by giving an overview to outline the components in the solution.

(See overview slide)

On the left we have the Jenkins server with a project defined. The project contains a build definition that is build up build steps of various kinds. One could be to check out all code from a repository or to copy a number of files to a specific destination.

Using the Leaptest plugin you can define Leaptest build step. When the build step is executed as part of a build, the plugin will use the Leaptest REST API trigger a Leaptest schedule. A schedule contains information about a number of test cases that should be triggered on a number of environments – which are in fact machines and devices.

Once all the test cases in a schedule has run on the environments defined the result of the tests are pushed back to the Leaptest plugin and added into Jenkins.

So let’s start with the beginning.


I have already installed the newest available version of Jenkins from I’m running it on my local 64-bit Windows 10, but it could have been in Linux as well – it’s the same procedure. To install the Leaptest-Jenkins plugin I start by downloading it from All links and detail can be found in the description to this video including the link to this repository.

On the GitHub page I select the Jenkins plugin. This plugin has been verified to work from version 1.635 of Jenkins and newer. I download the hpi file – which is the one I need for the installation – from the target folder.

Once downloaded I can open Jenkins and navigate to the Manage Plugin section. I choose Advanced and in the “Upload Plugin” section I select the plugin
file I just downloaded. When I click upload, I select that Jenkins can restart when the installation is done. Installation completed and the plugin is now installed. We can find it in the installed section under Manage Plugin.

The next thing to do is to create a new build definition. I click “new item” and enter a title: “Leaptest Jenkins” and press Freestyle project. This opens the new build definition, and I now have the option of specifying where my code repository is and a lot more details about the build process. In this video I will create a simple build definition that only triggers a test defined in Leaptest and not add anything more.

I add the Leaptest Jenkins plugin in the Build section as a build step. I can now specify a few things:

First the ‘Server Address’ which is the location of the Leaptest controller. If you have downloaded a trial, it will by default install it on port 9000 on localhost, which is also the case for my installation.

The ‘Report file name’ is the name of the file used to write the results of the test automation to. The result from Leaptest is converted into JUnit format which seems to be the preferred format in Jenkins.

In the ‘Schedule names’ field you can specify one or more Leaptest Schedules that you want to run as part of this build step.

When you click “Select schedules” the plugin will do a look up on the Leaptest server and give a list of all projects in the solution. If I expand the “Jenkins” project I can see a “Jenkins Demo” schedule that I can select.

Before we select the schedule, let’s just take a look into Leaptest and briefly see what a schedule is.


Under the “Scheduling” menu item we have a list of all defined schedules in Leaptest. In this case we have 3 schedules defined. A schedule defines that one or more test cases from one project should run on one or more defined environments.

An environment is a definition of a machine where the test case should run, and it can both be a local machine, an internal workstation or a cloud based

By combining the test cases and the environments, we have an entity that matches the Jenkins integration very well. In Jenkins you don’t want to define the test cases, and the machines where it should run. You basically just want to orchestrate that a test is started and the result is coming back when the test is completed. Then Jenkins can react accordingly to the test results.

(Overview slide)

If we turn to the overview drawing again, we can see that the schedule is the entity triggered from Jenkins, but Jenkins have no knowledge of what is tested and where it is tested. This is following the good principles of Segregation of Duties.


In the build definition, let’s select the schedule we just looked at.

The next thing to do is to add a Postbuild action that will read the test results and publish this into the Jenkins instance. I add a “Publish JUnit test result report” and specify “report.xml” in the “Test report XMLs” field. The value in this field should just match the file specified in the Leaptest plugin above.

When I press Save, we are now ready to run the first build. I press “Build now” and we see the first build starts.


In Leaptest we can see the schedule go into status “Running” which means the controller has picked of the test cases and are executing them on the environments. In Jenkins you will see a progress bar while it’s running. It seems like it’s using the time from the previous build to calculate the progress but I’m not entirely sure about this.

The result file has been read and we can inspect the result by clicking on the build. Before I do this I want to start another build to get a little more data.

When I click on the build I get access to the test results page. On this page I get information about the test run. In this case we have only 1 test case running and it succeeded in 40 seconds.

If I open the project page again the build I started has now ended, and we can see that a graph is added to the page if we refresh the page. This is a test result
trend graph that will show you the progress in the amount of passes and failed test cases as more builds are added.

In this video we looked at how to download, install and configure the Leaptest plugin for Jenkins and we looked at what a schedule is in Leaptest. We also saw that the schedule – and thereby the test cases in Leaptest – was triggered from the Jenkins build and a very brief look into how Jenkins handles test results.

Thank you.