CI plugins

The OpenText Core Performance Engineering plugins for continuous integration enable you to trigger a OpenText Core Performance Engineering test as a build step and present the results in the CI server's user interface.

In this topic:

Use the Jenkins plugin

We recommend that you always use the latest version of the plugin. Older versions of the plugin (versions 4.8.43 or earlier) have been deprecated.

To install the latest Jenkins plugin:

Download and install the latest Jenkins Plugin which is available on the official Jenkins plugin website.

To upgrade the Jenkins plugin from an older (deprecated) version:

Uninstall the old plugin, restart Jenkins, and then install the new Jenkins plugin.

To use the deprecated Jenkins plugin:

To install and work with an old version of the Jenkins plugin (version 4.8.43 or earlier), do the following:

Get the old plugin and upload it to your Jenkins server

1. Download the old Jenkins Plugin.

2. To upload the plugin to your Jenkins server, open Jenkins in your browser, and select Manage Jenkins > Manage Plugins > Advanced from the Jenkins menu. From the Upload Plugin section, upload the “JenkinsStormPlugin.hpi” that you downloaded in the previous step.

3. Restart your Jenkins server.

Configure OpenText Core Performance Engineering on Jenkins

1. From the Jenkins menu, select Manage Jenkins > Configure System.

2. Locate the LoadRunner Cloud section and enter the OpenText Core Performance Engineering URL (see note in CI plugins for details).

3. Authenticate:

   Note: Tenants created before version 24.3 can authenticate using the username/password or OAuth authentication methods. However, tenants created for version 24.3 and higher may only authenticate with the OAuth method with a client ID and secret key. The preferred and more secure method is to always authenticate with a client ID and secret key, even for earlier versions.

   • To authenticate with a username and password, enter the credentials, for example, loadrunner.cloud@opentext.com.

   • To authenticate with an access key, select Use OAuth token. Paste in the Client ID, Client Secret, and Tenant ID values as provided by your administrator.

4. If you require Jenkins to connect to OpenText Core Performance Engineering through a proxy server, select Use proxy connecting to LoadRunner Cloud server and configure the following:

   Setting	Description
   Proxy Host	The proxy server host name.
   Proxy Port	The proxy server port number.
   Proxy Username	The username to log into the proxy server.
   Proxy Password	The password to log into the proxy server.

   These settings are only used for connections between Jenkins and OpenText Core Performance Engineering—they do not affect other areas of Jenkins or your global proxy settings.

Create and configure a new job to run a OpenText Core Performance Engineering test

You can create two types of projects—Free-style or Pipeline.

Free-style project

1. From the Jenkins menu, select New item.
2. Select Build a free-style software project.
3. Click OK.
4. Select Add build step > LoadRunner Cloud run loadtest.

5. Enter the following:

   Argument	Description
   tenant	Your tenant ID, specified in your OpenText Core Performance Engineering URL. Example: https://loadrunner-cloud.saas.microfocus.com/home/?TENANTID=354274891
   testId	The ID for the test. To see the test ID, open the test in the Load tests tab and click Test settings. Tip: To build a more flexible job, you can configure a parameter named LRC_TEST_ID with the Jenkin's String Parameter feature. After you configure the parameter, the plugin uses the parameter value instead of the “testId” entered in Build > LoadRunner Cloud run loadtest.
   projectId	Your projectId, specified in your OpenText Core Performance Engineering URL. Example: https://loadrunner-cloud.saas.opentext.com/home/?TENANTID=354274891&projectId=1 Tip: To build a more flexible job, you can configure a parameter named LRC_PROJECT_ID with the Jenkin's String Parameter feature. After you configure the parameter, the plugin uses the parameter value instead of the “projectId” entered in Build > LoadRunner Cloud run loadtest.
   SendEmail	Select the checkbox to be notified when the test ends.

Note: The string parameters LRC_TEST_ID and LRC_PROJECT_ID are not supported for pipeline style jobs.

Pipeline project

The Jenkins plugin supports using Jenkins Pipeline. By installing the Pipeline plugin, you can create Pipeline type projects and write Pipeline scripts to invoke supported steps (start a test run and generate a trending report).

The following is an example script to start a test run:

pipeline {
    agent any
    
    stages {
        stage('SRL') {
            steps {
                srlRunTest projectID: '1', sendEmail: false, tenant: '388459696', testID: '6'
             }
        }
    }
}

You can view the detailed step description in Jenkins by navigating to Pipeline Syntax > Snippet Generator > Steps.

Configure the Jenkins Trending report for OpenText Core Performance Engineering (optional)

You can configure Jenkins to create a report that shows the trends for the last 5-10 runs of the load test configured in the job.

Configure the Trending report for a free-style project

1. In Jenkins, select your LRC job and then select Configure from the menu.
2. Select the Post-build Actions tab, and then click Add post-build action.

3. Expand the dropdown menu, select Generate LoadRunner Cloud Trending, and enter the following:

   Metric	Description
   Number of Runs	The number of last successful runs to include in the report. The valid range is 5-10.
   Benchmark	Enter a specific run ID to use as a benchmark, or leave blank to compare a run to the previous run. Note: If you change the benchmark run ID, only those load tests that run after the change are compared to the new benchmark. Load tests that ran before the change show their original comparison.
   Thresholds: TRT (Avg)	Enter a positive integer between 0-100 Set the following metrics for average TRT (transaction response time) thresholds: Improvement: The percentage decrease in average transaction response time considered to be an improvement in performance. Minor Regression: The percentage increase in average transaction response time considered to be a minor regression in performance. Major Regression: The percentage increase in average transaction response time considered to be a major regression in performance.
   Thresholds: TRT (Percentile)	Enter a positive integer between 0-100 Set the following metrics for average TRT (transaction response time) thresholds: Improvement: The percentage decrease in the 90th percentile maximum transaction response time considered to be an improvement in performance. Minor Regression: The percentage increase in the 90th percentile maximum transaction response time considered to be a minor regression in performance. Major Regression: The percentage increase in the 90th percentile maximum transaction response time considered to be a major regression in performance.

Configure the Trending report for a Pipeline project

Add the command to generate a Trending report to the script.

The following is an example script to both start a test run and generate a trending report:

pipeline {
    agent any
    
    stages {
        stage('SRL') {
            steps {
                srlRunTest projectID: '1', sendEmail: false, tenant: '388459696', testID: '6'
                srlGetTrendingReport benchmark: 0, runsCount: 5, trtAvgThresholdImprovement: 5,trtAvgThresholdMajorRegression: 10, trtAvgThresholdMinorRegression: 5, trtPercentileThresholdImprovement: 5, trtPercentileThresholdMajorRegression: 10, trtPercentileThresholdMinorRegression: 5
            }
        }
    }
}

Build the job

From the Jenkins dashboard, select the test and click Build Now.

View the output

When the build completes, click Console Output on the dashboard to view the log.

The JenkinsStormPlugin.hpi generates the following files in the workspace folder after the build completes:

File	Description
srl_report_<tenant id>-<run id>.xml	A Junit XML file containing basic information about the test, such as name, status, and duration.
srl_report_<tenant id>-<run id>.csv	A CSV file containing detailed test run results with metrics such as Vuser count and error count.
srl_report_trans-<tenant id>-<run id>.csv	A CSV file containing detailed statistics on each transaction in the test run.

View the OpenText Core Performance Engineering Trend report

If you configured Jenkins to create a OpenText Core Performance Engineering Trend report, from the Jenkins dashboard click LoadRunner Cloud Trend to view the report.

The report is displayed, showing test run metrics for the configured number of last successful runs and the status (improvement, minor regression, major regression) according to the thresholds you set.

Note: If you terminate a Jenkins job that includes a running load test, the plugin attempts to stop the load test and download any results files (such as .xml or .csv files), if they are available. This attempt may fail in the event of network problems, or if Jenkins ends the job before the plugin can stop the load test.

Back to top

Use the Azure DevOps plugin

Use the Azure DevOps Server (also known as TFS, Team Foundation Server) and Visual Studio Team Services (VSTS, also known as Azure DevOps) plugin to include a OpenText Core Performance Engineering test as part of a build script.

1. Download the LoadRunner Cloud extension for Azure DevOps.

2. Install the extension for Azure DevOps. For details, refer to the Azure DevOps extension installation help.

3. Create a service endpoint. For details, refer to the Azure manage service connections help.

   When creating the service endpoint, configure the following parameters for OpenText Core Performance Engineering:

   Name	Description
   Server URL	URL to connect to the OpenText Core Performance Engineering server (see note in CI plugins for details).
   Authentication	For username/password authentication, enter the following: User Name. Your user name to log on to OpenText Core Performance Engineering. Password. Your password to log on to OpenText Core Performance Engineering. For OAuth authentication, paste your Client ID in the User Name box, and your Client Secret in the Password box. Click Save & Test to test the connection using the credentials that you provided. Note: Tenants created before version 24.3 can authenticate using the username/password or OAuth authentication methods. However, tenants created for version 24.3 and higher may only authenticate with the OAuth method with a client ID and secret key. The preferred and more secure method is to always authenticate with a client ID and secret key, even for earlier versions.
   Proxy URL	Add your local proxy in the format http(s)://(host):(port#) or leave empty if you are not using a local proxy.
   Proxy Username	If using a proxy that requires credentials, enter the user name.
   Proxy Password	If using a proxy that requires credentials, enter the password.

4. Add a task to the build. For details, refer to the help on Azure tasks.

   When creating the task, configure the following parameters for OpenText Core Performance Engineering:

   Name	Description
   LoadRunner Cloud Service Endpoint	Select the service endpoint you created above for your OpenText Core Performance Engineering server.
   Tenant ID	Your tenant ID, specified in your OpenText Core Performance Engineering URL. Example: https://loadrunner-cloud.saas.opentext.com/home/?TENANTID=354274891
   Project ID	Your project ID, specified in your OpenText Core Performance Engineering URL. Example: https://loadrunner-cloud.saas.microfocus.com/home/?TENANTID=354274891&projectId=1
   Test ID	The ID of the test. To see the test ID, open the test in the Load tests tab and click Test settings.
   Send e-mail to the preset address	Select this checkbox if you want to receive a notification email to a preset address after the test run is finished.
   Run Test in Detached Mode	Deactivates the reporting of test run results. Select this checkbox if you don't want the task to wait for the load test run to finish.

5. For earlier versions of the Azure DevOps server, you may need to enable the Allow scripts to access the OAuth token option before running the task.

6. When the task has finished, you can view an artifact published on the Summary tab and a brief report on the OpenText Core Performance Engineering tab.

7. When finished, a variable called LRC_RUN_ID is available in the extension. This variable stores the ID of the run started by the task. You can use this variable in later steps in the same pipeline to query OpenText Core Performance Engineering public APIs for additional metrics (after the run finishes and such metrics are available).

   To use the LRC_RUN_ID variable in the pipeline:

   Pipeline	Job	Steps
   Classic	Same job	Set a reference name for the OpenText Core Performance Engineering test task. Refer to the variable in the format $(<ReferenceName>.<VariableName>). For example, if you set a reference name of LRC, refer to the variable by using $(LRC.LRC_RUN_ID).
   YAML	Same job	Set a name for the OpenText Core Performance Engineering test task. For example, name:LRC. Refer to the variable in the format $(<ReferenceName>.<VariableName>). For example, if you set a name of LRC, refer to the variable using $(LRC.LRC_RUN_ID).
   YAML	Different job Note: To use the variable in a different job, you must use the YAML pipeline.	Set a name for the OpenText Core Performance Engineering test task. For example, in the runLRC job, set name:LRC. In the jobs in different tasks, set dependsOn to the job name in which you defined the name for theOpenText Core Performance Engineering test task in the above step. For example, dependsOn runLRC. Map the variable to the current job. For example, runIdFrom_LRC: $[ dependencies.runLRC.outputs['LRC.LRC_RUN_ID'] ]. You can now refer to the variable using the mapping defined in the above step. For example, $(runIdFrom_LRC)

   For more information, see Use output variables from tasks in the Azure Devops documentation.

Back to top

Use GitHub Actions

OpenText Core Performance Engineering provides a GitHub Action to enable you to trigger a load test and collect reports as part of a workflow. You can include the action as a step in your workflow YAML file and provide the necessary input parameters. For example:

```
  - name: start a load test run
    uses: MicroFocus/lrc-gh-action@v1
    env:
      ...
    with:
      ...
```

For more information and examples, see LoadRunner Cloud GitHub Action.

For general information on GitHub Actions, refer to the GitHub Actions documentation.

Back to top

See also:

• Support Matrix
• API access keys