Synchronize LoadRunner Enterprise with Git

This topic describes how to use the Micro Focus LoadRunner Enterprise integration with Git plugin to synchronize LoadRunner Enterprise with Git by uploading LoadRunner and JMeter scripts and tests stored in a GitHub repository to a LoadRunner Enterprise project.

Create a Git repository

To synchronize scripts, copy the LoadRunner scripts generated in VuGen (or JMeter tests which are also supported) to one or several sub-folders in your GitHub repository.

You can create a new Git repository, or use an existing one to store your performance test scripts.

In the example below, the Git repository contains a folder named "scripts", and within it, different folders, each containing a performance script.

The plugin identifies each folder that contains a .usr or .jmx file, which it compresses, and uploads to LoadRunner Enterprise.

Back to top

Create hooks that automatically trigger a Jenkins build on a Git commit

To trigger a Jenkins build after committing a script with changes to the Git repository, do the following:

  1. In Github, open the Settings tab and click Hooks. Click Add webhook, and create a Webhook to the Jenkins server on the “push event” (see step 2 for details on retrieving the correct URL from the Jenkins server).

  2. To create the Webhook in Git, you need to get the appropriate URL from the Jenkins server:

    1. Make sure Git Plugin and Github Plugin are installed in Jenkins. From Jenkins home, select Manage Jenkins > Manage Plugins > Installed tab, and search for both plugins. If you can’t find them, you can install them from the Available tab or from https://plugins.jenkins.io/.

    2. To retrieve the Webhook URL from the Jenkins server perform the following:

      1. From Jenkins Home, select Manage Jenkins > Configure System, and search for "GitHub Servers".

      2. In the GitHub Servers section, click the Advanced… button. The Override Hook URL section is displayed.

      3. Select the Specify another hook URL for GitHub configuration option. A text box displays the currently defined Hook URL.

    3. Copy the value displayed in the text box and use it in GitHub (as described in step 1 above).

      (Optional) Select the Just the push event option if you only want push events to trigger the build on the Jenkins server.

      Click Update webhook.

Back to top

Upload the integration plugin to the Jenkins server

The LoadRunner Enterprise-Git integration plugin enables you to synchronize performance test scripts from a Github repository to a project on the LoadRunner Enterprise server.

  1. Install the Jenkins server.

  2. Install the Micro Focus LoadRunner Enterprise integration with Git plugin.

    For details on downloading and installing this plugin, see Micro Focus Performance Center Integration With Git.

    1. Go to Jenkins home > Manage Jenkins > Manage Plugins > Advanced.

    2. In the Upload Plugin section, select the micro-focus-performance-center-integration.hpi file and click Upload.

    3. Restart Jenkins if required.

Back to top

Configure a job in Jenkins to synchronize scripts

You can create a Jenkins project to synchronize LoadRunner Enterprise with Git by uploading LoadRunner and JMeter scripts stored in a Git repository to a LoadRunner Enterprise project.

  1. In the Jenkins dashboard, click New Item, and select Freestyle project to create a new project.

  2. Enter the details of the project for the new Job:

    1. In the General section, select the GitHub project check box, and enter the URL of the Git repository in the Project URL box.

    2. In the Source Code Management section, select the Git option, and enter the Git URL in Repository URL field, and provide credentials for allowing access to this repository. Also define which branch will be cloned to the job's workspace.

    3. In the Build Triggers section, select the GitHub hook trigger for GITScm polling option.

    4. In the Build section, go to the Add build step drop down list, and select Synchronize LoadRunner Enterprise with Git.

    5. Enter the following build step details:

      Argument Description
      Description Provide your own description of the build step purpose.
      LRE Server

      Enter the hostname or IP address of the LoadRunner Enterprise server.

      If the LoadRunner Enterprise server is not using the default port (80), mention it by adding a colon (:) and then the port number.

      Example:myLREserver.mycompany.net , 182.138.255.1 or myLREserver.mycompany.net:81.

      Note: Do not use the full URL of LoadRunner Enterprise server. For example, using https://myLREserver/LoadTest will fail. Instead, just specify the myLREserver value in this field, and select the Use HTTPS Protocol option if a secured protocol is required.

      Use HTTPS Protocol Select this option if the LoadRunner Enterprise server is using a secured connection.
      Credentials Enter the user name and password of the LoadRunner Enterprise user to connect to the server.
      Domain Enter the LoadRunner Enterprise domain of the project in which the scripts will be uploaded.
      Project Enter the name of the LoadRunner Enterprise project in which the test to run is stored.
      Local Proxy

      Add your local proxy in the format: http(s)://host:port and enter the user name and password, or leave empty if not using a local proxy.

      Note: PAC (proxy auto-config) and Automatic configuration script are not supported.

      Proxy Credentials Proxy credentials or parameter pointing to such credentials.
      Test Plan folder

      The Test Plan folder path in LoadRunner Enterprise where the scripts will be loaded.

      Available paths can be found in the Test Management tree in the LoadRunner Enterprise user interface. The path must begin with "Subject" and be separated with backslashes (\). The path is case-sensitive.

      Upload script mode

      This corresponds to the similar option existing in LoadRunner Enterprise or VuGen:

      • All Files: All script files are uploaded (this takes longer to load).

      • Runtime Files: Only the required files are uploaded (script files, Runtime Settings, parameter files, etc.)

      Recommended value: Runtime Files

      Delete script

      This option enables you to synchronize script deletion from Git to LoadRunner Enterprise.

      Recommended value: Yes

      Import Tests

      (Available in plugin version 1.1.0)

      Instructs the plugin to synchronize the YAML file stored in Git. For details, see Configure a job in Jenkins to synchronize tests below.

Back to top

Configure a job in Jenkins to synchronize tests

Available in plugin versions: 1.1.0 and later

You can create a Jenkins project to synchronize performance tests from YAML files stored in a GitHub repository to a LoadRunner Enterprise project.

To synchronize tests:

  1. Perform the steps in Configure a job in Jenkins to synchronize scripts above, and for the Import Tests option, select Yes.

  2. Copy your YAML files to a folder in your Git repository (YAML files under the root of the Git repository will be ignored). The plugin creates the test in the LoadRunner Enterprise project according to:

    • The file name (without extension) which will be used as test name.

    • The location of the file in the Git repository which will be the location of the test under the root folder ('Subject') in the Test Management tree.

    • The content of the YAML file, which must be composed according to the parameters described in the tables below.

      Note:  

      • All parameters must be in lowercase.

      • When a backslash (\) occurs in a value provided to a parameter (for example, a folder separator in a file path), a double backslash (\\) must be used instead.

YAML file Parameters

Root parameters of the YAML file:

Parameter Description Required
controller

Defines the Controller to be used during the test run (it must be an available host in the LoadRunner Enterprise project). If not specified, a Controller will be chosen from the various Controllers available in the LoadRunner Enterprise project.

Available with plugin version 1.1.1 and later: You can provision a Controller as a Docker image by specifying the value "Elastic" and providing a value for the controller_elastic_configuration parameter (see controller_elastic_configuration table below).

No
lg_amount Number of load generators to allocate to the test (every group in the test will be run by the same load generators). Not required if each group defined in the group parameter defines the load generators it will be using via the lg_name parameter (see group table below).
group Lists all groups or scripts defined in the test. The parameter to be used in each group are specified in the group table below. Yes
scheduler Defines the duration of a test, and determines whether virtual users are started simultaneously or gradually. See the scheduler table below. No
lg_elastic_configuration

 

(Available with plugin version 1.1.1 and later)

Defines the image to be used to provision load generators. See the lg_elastic_configuration table below.

Yes, if a load generator is defined to be provisioned from a Docker image.
controller_elastic_configuration

 

(Available with plugin version 1.1.1 and later)

Defines the image to be used in order to provision the Controller. See the controller_elastic_configuration table below. Yes, if the Controller is defined to be provisioned from a Docker image.

Back to top

Example scripts

Back to top

Run the job

You can run the job by either:

  • Merging a pull request to the master branch.

    The usual process is as follows:

    1. Commit a change to a branch (or fork).

    2. Push the change (pushing changes to master is not usually allowed unless you have admin rights).

    3. Create pull request.

    4. Merge pull request (this operation will trigger the build as it pushes the change to master branch).

  • Manually triggering the build from Jenkins.

Note:  

  • Make sure the machine running the job (the Jenkins server or a distributed node defined in the Jenkins server) can fetch everything required from the Git repository. You will probably need to install Git client (available from https://plugins.jenkins.io/) and configure the operating system of the machine that runs the build to allow this.

  • The synchronization process is set to find the previous build that ran successfully, and to include only the modifications from the build (if there are no differences, nothing is synchronized). If there has not been a successful build, everything will be synchronized.

Back to top

Review the results

If the Debug option was selected in the Jenkins global configuration section (Manage Jenkins > Configure System), a stack trace is published in the log report when errors occur.

Back to top

Configure Jenkins using GitLab (instead of GitHub)

You can perform all the GitHub configuration steps explained above using GitLab instead. Here are the steps:

  1. Configure Jenkins with GitLab

    1. From Jenkins Home, select Manage Jenkins > Configure System.

    2. Define a GitLab connection and a GitLab Notifier configuration (both require a token from GitLab).

      Tokens can be retrieved from GitLab via User Settings > Access Token (you can set tokens with an expiration date, revoke them, and grant permissions and define permission levels).

  2. Configure a Jenkins job

    Create a new job, or use an existing one with the following settings:

    • In the Source Code Management section, allow the job to clone the repository within the workspace. Select the Git option, enter the Git URL in Repository URL field, and provide credentials for allowing access to this repository.

    • If you want to have the build triggered at a GitLab event, define a trigger in the Build Triggers section. Jenkins can create a secret token that can be used in the next step when creating a hook in the GitLab project (as described in the next section).
  3. Configure your GitLab project

    You can do this by performing either of the following:

    Creating a GitLab Hook to trigger a Git Merge

    To create a GitLab Hook to trigger a Jenkins build Git Merge:

    1. In your GitLab project, open Settings > Integrations.

    2. In the URL section, add the URL of your Jenkins job and use the secret token generated in the previous step if required.

    Defining the .gitlab-ci.yml file to trigger a Jenkins job

    Define the .gitlab-ci.yml file of your GitLab project to run a cURL command triggering a Jenkins job.

    This command can be performed from a Shell executor and send parameters which is not possible to do in the previous step.

    A simple command triggering Jenkins job with parameters (YAML_TEST being the parameter in the example) can be like this:

    curl -i -X POST http://MyJenkinsServer:8080/jenkins/job/MyJenkinsJob/buildWithParameters?YAML_TEST=Tests\yaml\yamlTest2.yaml

    (You can run this from a command prompt to test it. You might want to download cURL from https://curl.haxx.se/ and have it install in your GitLab Runners and in the machine testing the command.)

Back to top

Tips and troubleshooting

For details, see Tips and troubleshooting.

Back to top