CI plugins

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

Note: This topic contains a number of instances where you need to enter the server URL. You can get the URL by copying it from the address bar of the browser. For example, if the URL in the address bar of the browser is https://myserver.com/home/?TENANTID=208294383&projectId=1, copy the address https://myserver.com.

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.

Note: If you are upgrading from an older (deprecated version), previous configuration and historical data is not saved.

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:

  1. 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.

  2. Configure OpenText Core Performance Engineering on Jenkins

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

    2. Locate the OpenText Core Performance Engineering 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 can 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.

      • 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 through a proxy server, select Use proxy connecting ... 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.

  3. Create and configure a new job to run a load 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,Core Performance Engineering run loadtest.

    5. Enter the following.

      Argument Description
      tenant

      Your tenant ID, specified in your OpenText Core Performance Engineering URL.

      Example: https://myserver.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,Core Performance Engineering run loadtest.
      projectId

      Your projectId, specified in your OpenText Core Performance Engineering URL.

      Example: https://myserver.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,Core Performance Engineering 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.

  4. 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 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
            }
        }
    }
}

  5. Build the job

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

  6. View the output

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

    Console output example

    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.

  7. View the Trend report

    If you configured Jenkins to create a Trend report, from the Jenkins dashboard click 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.

    LoadRunner Cloud trend report

    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 load test as part of a build script.

  1. Download the 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.

    Name Description
    Service Endpoint Select the service endpoint you created 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.opentext.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

    1. Set a reference name for the OpenText Core Performance Engineering test task.

    2. 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

    1. Set a name for the OpenText Core Performance Engineering test task. For example, name:LRC.

    2. 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.

    1. Set a name for the OpenText Core Performance Engineering test task. For example, in the runLRC job, set name:LRC.

    2. In the jobs in different tasks, set dependsOn to the job name in which you defined the name for the OpenText Core Performance Engineering test task in the above step. For example, dependsOn runLRC.

    3. Map the variable to the current job. For example, runIdFrom_LRC: $[ dependencies.runLRC.outputs['LRC.LRC_RUN_ID'] ].

    4. You can now refer to the variable using the mapping defined in the above step. For example, $(runIdFrom_LRC)

    For more information on how to use output variables from tasks, see the Azure DevOps documentation.

Back to top

Use GitHub Actions

A GitHub Action is provided 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:

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

For more information and examples, see GitHub Action.

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

Back to top

See also: