Find plugins

Micro Focus Performance Center integration With Git
1.0.0Minimum Jenkins requirement: 2.60.3ID: micro-focus-performance-center-integration

This plugin integrates Micro Focus Performance Center with Git via Jenkins.

Using this plugin, you can upload LoadRunner and JMeter scripts from a GitHub repository to a project on the Performance Center server.

There is another plugin for running performance tests using Performance Center. For details, see Micro Focus Application Automation Tools - Performance Center Integration.

Submit issues and feedback through JIRA

This plugin is open source. If you identify any issues or want to submit enhancement requests, please use JIRA. The component for this plugin is the micro-focus-performance-center-integration component. Your feedback and involvement will allow us to stabilize and enhance the capabilities of the plugin. The latest, early access, beta versions of this plugin are available here

Version 1.0.0

This version provides the following enhancements:

Git synchronization 

  • Ability to synchronize Performance Center with Git by uploading LoadRunner and JMeter scripts stored in a Git repository to a Performance Center project.

Version 1.1.0 (not yet released)

This version provides the following enhancements:

  • Git Synchronization: ability to create Performance Center test from yaml files stored in Git.
  • Test Execution: Ability to create a test (from yaml file or from yaml content) before running it.


You can download the plugin from this link: https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/micro-focus-performance-center-integration/1.0.0/micro-focus-performance-center-integration-1.0.0.hpi


  1. Java version 8 or higher. To verify your Java version, go to http://www.java.com/en/download/installed.jsp.
  2. Performance Center server.
  3. Git Repository and Github server.
  4. Jenkins versions: This plugin supports only the latest five LTS versions of Jenkins (currently 2.60.3). This is a result of the Jenkins policy to no longer support older update centers. Jenkins 2.54 and higher requires you to have Java 8 installed on the machine.
  5. Content Security Policy: Starting with version 1.641 (or 1.625.3), Jenkins introduced the Content-Security-Policy header. This causes some of the integration links, such as links to reports, to become inoperable. For details, see Configuring Content Security Policy and Jenkins Security Advisory . For suggested workarounds until the issue is resolved, see Content Security Policy Header.
  6. Performance Center projects having Version Control enabled are not supported.

Support for Pipelines

Generate pipeline code
  1. To set up a pipeline test job for your Micro Focus testing tool:
    1. From Jenkins Dashboard, click New Job or select an existing one.
    2. On the page that opens, enter a job name (for a new job), click Build a Pipeline project, and click OK.
    3. In the Project Configuration page, scroll down to the Pipeline section.
    4. Enter the stage and node arguments into the Script area. For example,

      stage('RunTestFromFS'){ // The stage name
          node('Test'){ //  The name of the node in which to run the test.

  2. Prepare the code for your testing tool:
    1. Click the Pipeline Syntax link.
    2. In the Snippet Generator drop down, select the desired step, for example, pcGitBuild: Synchronize Performance Center with Git.
    3. Fill in the fields as required. Fields marked in red are mandatory. Note: For fields that take multiple values, such as in the Tests field, separate multiple entries with a line break.
    4. Click Generate Pipeline Script. Copy the code to the clipboard.
  3. Return to the Project Configuration page, and paste the generated Groovy script into the Script field in the Pipeline section.
  4. Repeat the above steps to add other commands to your script.
  5. Save the script and run or schedule the job as you would with any standard Jenkins job.

Supported Pipeline job types

The available Pipeline job types are pcGitBuild.


Pipeline step name


Performance Center


Synchronize Performance Center with Git

Enable Non-English Languages

In order to allow the add-in to support non-English languages, make the following changes to your Jenkins Master and nodes configuration:

Master configuration
  1. Open the Jenkins.xml file in the Jenkins installation folder, for example: c:\Jenkins\Jenkins.xml.
  2. Go to the <service> -> <arguments> section and add the -Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8 flags after the -jar flag.

For example:

<description>This service runs Jenkins continuous integration system.</description>
<env name="JENKINS_HOME" value="%BASE%"/>
This example assumes that you have java in your PATH.
To run Jenkins with a specific version of Java, specify a full path to the desired java.exe.
<arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar -Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8 "%BASE%\jenkins.war" --httpPort=8080 --webroot="%BASE%\war"</arguments>
The *interactive* flag causes the empty black Java window to be displayed.
<interactive />
<onfailure action="restart" />

Slave configuration
  1. Open the jenkins-slave.xml file on the Jenkins slave (node) machine in the folder that you designated.
  2. Go to the <service> -> <arguments> section and add the -Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8 flags after the -jar flag.
<description>This service runs a slave for Jenkins continuous integration system.</description>
This example assumes that you have java in your PATH.
To run Jenkins with a specific version of Java, specify a full path to the desired java.exe.
<executable>C:\Program Files (x86)\Java\jre1.8.0_91\bin\java.exe</executable>
<arguments>-Xrs -jar "%BASE%\slave.jar" -Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8 -jnlpUrl http://xxx.xxx.xxx.xxx:8080/jenkins/computer/VM112233/slave-agent.jnlp -secret xyzabc</arguments>
The *interactive" flag causes the empty black Java window to be displayed.
<interactive />
<onfailure action="restart" />

Configuration for Java Web Start clients
  1. On the Jenkins master machine, go to Manage Jenkins -> Manage Nodes. Click the relevant node or slave. and select Slave -> Configure -> Advanced.
  2. Add the following to the JVM options text box – “-Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8”.
  3. Restart your Jenkins master, node, and slave.
  4. Verify that your changes took effect:
    1. For the Master: Go to Manage Jenkins -> System information -> “file.encoding”, “sun.jnu.encoding”. The value should be “UTF-8”.
    2. For the node/slave: On the master machine, go to Manage Jenkins -> Manage Nodes.
      Click on the relevant node or slave and select System information-> “file.encoding”, “sun.jnu.encoding”. The value should be “UTF-8”.
      Workaround: If you find that the slave machine still does not support localized encoding, launch the slave from the command line as shown in the image below:

     For example:

java -Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8 -jar slave.jar -jnlpUrl http://xxx.xxx.xxx.xxx:8080/jenkins/computer/VM112233/slave-agent.jnlp -secret xyzabc


Synchronize Performance Center With Git

You can integrate Performance Center with Git by running a Jenkins job set with the build step "Synchronize Performance Center with Git. This will upload LoadRunner and JMeter scripts found in your Git repository to your Performance Center project.

Create a Git repository

You can create a new Git repository, or use an existing one to store LoadRunner scripts. 
For example, the Git repository in the image below contains a folder named "scripts", and within it, different folders, each containing a performance script.

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

To trigger a Jenkins build when the Git repository is being modified, 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” (review the next step to retrieve 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 follow the next steps: 
      1. From the Jenkins server home page, select Manage Plugins > Configure System, and search (Ctr + F keys) for "GitHub Servers" to find this section.
      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.
      4. 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.

Upload the plugin to the Jenkins server

  1. Go to the Jenkins server home page > Manage Jenkins > Manage Plugins > Advanced.
  2. In the Upload Plugin section, upload the plugin's file ("micro-focus-performance-center-integration.hpi").

  3. Restart the Jenkins server if required.

Synchronizing scripts (available in version 1.0.0)

Place, within one or several sub folder in your git repository (preferably not under the root), LoadRunner scripts generated by VuGen (Jmeter test are also supported). The plugin will identify as script, every folder containing a usr or jmx file, compress each of them and upload them to Performance Center.

Synchronizing tests (available in version 1.1.0)

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 will create the test in the Performance Center 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 below.

Note: all parameters must be in lowercase.


Parameter Description Required
controller Defines the Controller to be used during the test run (it must be an available host in the Performance Center project). If not specified, a Controller will be chosen from the different controllers available in the Performance Center project. 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


Parameter Description Required
group_name Name of the group (it must be a unique name if several groups are defined). Yes
vusers Number of virtual users to allocate to the group for running the script. Yes
script_id ID of the script in the Performance Center project. Not required if the 'script_path' parameter is specified.
script_path Path and name of the script to be added to the group, separated by double backslashes (\\). For example "MyMainFolder\\MySubFolder\\MyScriptName'. Do not include the Performance Center root folder (named "Subject"). Not required if 'script_id' parameter is specified
lg_name List of load generators to allocate to the group for running the script. The supported values are:
  • The hostname, as defined in Performance Center, of an existing load generator in Performance Center allocated as a host.
  • "LG" followed by a number, to use an automatically matched load generator (recommended).
  • "DOCKER" followed by a number, to use a dynamic load generator (available if your Performance Center server and project are set to work with Docker).


Parameter Description Required
rampup Time, in seconds, to gradually start all virtual users. Additional virtual users will be added every 15 seconds until the time specified in the parameter ends. If not specified, all virtual users will be started simultaneously at the beginning of the test. No
duration Time, in seconds, that it will take to run the test after all virtual users are started. After this time, the test run ends. If not specified, the test will run until completion. No

In the example below:

  • The plugin automatically assigns the file name as the test name, and the folder path of the file in the Git repository is used to create the location of the test under the root folder ('Subject') in the Performance Center project.
  • In the content:
    • Since no Controller or load generator amount were specified, a random available Controller will be used to run the test, and the 'lg_name' parameter specified in each group will be used.
    • In the 'group' parameter:
      • We added two scripts. For each, we provided a unique value in the 'group_name' parameter, and the number of virtual users to run the group.
      • Since we did not know the ID of the scripts, we used the 'script_path' parameter in which we entered the script path (without "Subject") followed by the script name, and used double backslashes for separators.
      • We specified the load generators that will be used by each group (in this case, load generators will automatically be matched as we use the 'LG' prefix).
  • In the scheduler:
    • We want all Virtual Users to be initialized gradually (45 seconds).
    • We want the test to stop after 5 minutes (300 seconds).

#controller: "mycontroller"
#lg_amount: '2'
  - group_name: "TEstInt"
    vusers: '20'
#    script_id: '1'
    script_path: "plugin\\TEstInt"
      - "LG1"
      - "LG2"
  - group_name: "Mtours"
    vusers: '20'
#    script_id: '2'
    script_path: "plugin\\mtours"
      - "LG3"
      - "LG4"
  rampup: '45'
  duration: '300'

Configure a new job in Jenkins

  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 checkbox and set 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 (master in the screenshot below).

    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 dropdown list, and select Synchronize Performance Center with Git.

    5. Enter the following build step details:
      • Description: Provide your own description of the build step purposes. 
      • PC Server: Enter the hostname or IP address of the Performance Center server. If the Performance Center server is not using the default port (8080), mention it by adding a colon (:) and then the port number.
        Examplemypcserver.mycompany.net or or mypcserver.mycompany.net:81 
        Important: Do not use the full URL of Performance Center server. 
        For example, using https://mypcserver/LoadTest will fail. Instead, just specify 'mypcserver' value in the 'PC Server' field and select the 'Use HTTPS Protocol' option if a secured protocol is required.
      • Use HTTPS Protocol: Select this option if the Performance Center server is using a secured connection.
      • Credentials: Enter the user name and password of the Performance Center user to connect to the server.
      • Domain: Enter the Performance Center domain of the project in which the scripts will be uploaded.
      • Project: Enter the name of the Performance Center project in which the test to run is stored.
      • Local Proxy: Add your local proxy in the format: http(s)://host:port or leave empty if not using a local proxy.
        The following proxy configurations are not supported:
        • PAC (proxy auto-config).
        • Automatic configuration script.
      • Proxy Credentials: Proxy credentials or parameter pointing to such credentials.
      • Test Plan folder: The Test Plan folder path in Performance Center where the scripts will be loaded. Available paths can be found in the Test Management Tree from Performance Center interface. The path must begin with "Subject" and be separated with backslashes (\). The path is case-sensitive!
        Important: For Performance Center Server versions earlier than 12.60:
        • The specified folder must exist at the time of the build (the plugin cannot create folders independently).

        • Scripts saved in Git sub-folders will be synchronized to the specified subject, and in case of duplicated script names in Git, the last uploaded script to Performance Center will overwrite any previously uploaded script(s) with the same name.

      • Upload script mode: This corresponds to the similar option existing in Performance Center / 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 allows you to synchronize script deletion from Git to Performance Center.
        Recommended value"Yes".

      • Import Tests: This drop down list was added in version 1.1.0. It instructs the plugin to also synchronize yaml file stored in Git.

Run the job

You can run the job by either:

  • Merging a pull request to the master branch (in the example illustrated in screenshots from "Configure a new job in Jenkins" section → point 2.b). The usual process is like this (pushing changes to master branch is usually not something allowed unless if you have admin rights)
    1. Commit a change to a branch (or fork).
    2. Push the change.
    3. Create a pull request.
    4. Merge the pull request (this operation will trigger the build as it pushes the change to master branch).
  • Manually triggering the build from Jenkins.


  • Make sure that the machine executing the job (it can be the Jenkins server itself 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 and configure the operating system of the machine executing the build to allow this. For details, see Git Plugin.
  • 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.

Review the results

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

Tips and Troubleshooting

  • The PC-Git plugin is supported in Performance Center versions 12.60 and later; it is compatible with Performance Center versions 12.55-12.57 with the following limitations:
    • In Performance Center, you need to manually create the Test Plan folder specified in the Test Plan folder field of the step build (see step 3 in "Configure a new job in Jenkins" above) before running any build. 
    • All scripts found in the Git repository will be uploaded to the same root folder in Performance Center 12.55-12.57. As a result, any scripts with the same name will overwrite each when uploaded to the Performance Center project.
  • The first successful build uploads all scripts (it might take longer to sync). Subsequent builds include modifications only from the previous successful build, and should be much faster.
  • Synchronizing script deletion is optional in the build's configuration (it is enabled by default). However, failing to delete scripts in a Performance Center project after they have been deleted in the Git repository will not cause the build to fail.

For details on this and other Performance Center integrations, see the Performance Center plugins topic in the Performance Center help.

ArchivesGet past versions
This plugin has no labels