Share this page

# GitLab integration

The Test Execution GitLab integration enables you to trigger tests on an OpenText Enterprise Performance Engineering server, monitor the tests, generate analysis or trend reports, and get the report status. The tests can be pre-existing ones or those defined in a YAML file in the GitLab repository.

In this topic:

## Prerequisites

The following are the prerequisites for using this plug-in:

- If you are using Docker, you can configure it similar to the one defined in DockerfileForTesting, and then use the content of .gitlab-test-release.yml to run a test.

- If you need to set up a custom GitLab runner, it must be configured with node and java and have permissions to run npm, npx and node.

- If required, define the sudoers to provide permissions for those actions to the GitLab runner user, by default gitlab-runner.

- If you need the CI build to install Java, mvn, and node on the GitLab runner, you must also mention those actions in the sudoers. Use the visudo command to ensure safe editing of the file.

For example:

1. Run the following command: `sudo visudo`

2. Add an entry for the GitLab Runner user: `gitlab-runner ALL=(ALL) NOPASSWD: /path/to/command` where /path/to/command can be any elevation.

3. Replace /path/to/command with the full path to the command you want to allow. For example, to allow apt-get update: `gitlab-runner ALL=(ALL) NOPASSWD: /usr/bin/apt-get update`

4. Save and exit the editor.

Using this method in the sudoers provides the basic requirement. If your job performs other operation such as apt-get or curl commands, you may need to define additional properties, such as:

`gitlab-runner ALL=(ALL) NOPASSWD: /usr/bin/npm, /usr/bin/npx, /usr/bin/node`

Back to top

## Variables

You can define any variable that will most likely remain unchanged as a CI\CD variable, and keep the ones that need to be set in the .gitlab-ci.yml file.

Tip: We recommend defining the GitLab repository with the CI\CD variable and have them set as masked for the lre_username and lre_password parameters. If a proxy requiring authentication is used, the lre_username_proxy and lre_password_proxy should also be defined.

To set up variables:

1. Go to Settings > CI/CD > Variables in the project.

2. Add the variables lre_username and lre_password to use in your pipeline. If authenticating via a proxy, also add lre_username_proxy and lre_password_proxy.

   For token authentication to OpenText Enterprise Performance Engineering, use the value of ClientIdKey from the token (with the I_KEY_ prefix) for the lre_username and the value of ClientSecretKey (with the S_KEY_ prefix) for lre_password

3. Add any other parameter that you want to define outside the yml of the CI configuration.

   - Make sure to mark these variables as protected if you want them to be available only on protected branches or tags.

   - You can set sensitive parameters as masked.

4. Optionally, in .gitlab-test-release.yml, set the version of the release and the URL of the project in gitlab.com:

   RELEASE_TAG: "v0.1.4"

   GITLAB_LRE_ACTION_URL: "https://gitlab.com/loadrunner-enterprise/lre-gitlab-action"

   This instructs .gitlab-test-release.yml to download the artifact of the release package during the build of the release and use it to run the test. The first release has been set to be v0.1.4. As required, OpenText will issue new releases.

5. To save the test's reports to the build artifact, add the following to your test:

   Copy code

         artifacts:<br>
           paths:<br>
             - LreResult/

Back to top

## Action inputs

This table lists the action inputs for setting up and running a test.

Input | Description | Required | Default
--- | --- | --- | ---
lre_action | Action to be triggered. Current supported action: ExecuteLreTest | No | ExecuteLreTest
lre_description | Description of the action (will be displayed in console logs). | No | Not Applicable
lre_server | Server URL, port (when not mentioned, default is 80 or 433 for secured) and tenant (when not mentioned, default is ?tenant=fa128c06-5436-413d-9cfa-9f04bb738df3). e.g.: myserver.mydomain.com:81/?tenant=fa128c06-5436-413d-9cfa-9f04bb738df3' | Yes | Not Applicable
lre_https_protocol | Use secured protocol for connecting to server. Possible values: true or false. | No | false
lre_authenticate_with_token | Authenticate with a token. Required when SSO is configured. Possible values: true or false. | No | false
lre_username | Username | Yes | Not Applicable
lre_password | Password | Yes | Not Applicable
lre_domain | Domain (case sensitive) | Yes | Not Applicable
lre_project | Project (case sensitive) | Yes | Not Applicable
lre_test | A valid test ID# or relative path to yaml file in the git repo defining new test design creation | Yes | Not Applicable
lre_test_instance | The test instance. Specify AUTO to use any instance or enter a specific instance ID | No | AUTO
lre_timeslot_duration_hours | Timeslot duration in hours | No | 0
lre_timeslot_duration_minutes | Timeslot duration in minutes | No | 30
lre_post_run_action | Possible values for post run action: Collate Results, Collate and Analyze, or Do Not Collate | No | Do Not Collate
lre_vuds_mode | Use VUDS licenses. Possible values: true or false | No | false
lre_trend_report | One of the following values: ASSOCIATED (the trend report defined in the test design will be used) A valid report ID# No value or not defined indicates no trend monitoring in build, but the defined trend report will not be canceled. | No | Not Applicable
lre_proxy_out_url | Proxy URL | No | Not Applicable
lre_username_proxy | Proxy username | No | Not Applicable
lre_password_proxy | Proxy password | No | Not Applicable
lre_search_timeslot | Experimental: Search for matching timeslot instead of creating a new timeslot. Possible values: true or false. | No | false
lre_status_by_sla | Report success status according to SLA. Possible values: true or false. | No | false
lre_output_dir | The directory to read the checkout folder and to save results . Use "$CI_PROJECT_DIR". | No | ./
lre_enable_stacktrace | If set to true, a stack trace of the exception will be displayed with errors in console logs. | No | false

Back to top

## Example

This section illustrates the running of a test and generation of reports using the actions described above.

The example below:

1. Authenticates using the token provided by the user.

2. Creates an load test according to the YamlTest/createTestFromYaml.yaml file from the Git repository.

3. Executes the test.

4. Waits for the analysis and trending to complete and download the reports.

5. Uploads the reports to the build artifact.

Copy code

    stages:
      - test

    variables:
      lre_description: "my lre test execution"
      # lre_server: "mylreserver" #value provided as CI/CD variable
      lre_https_protocol: true
      lre_authenticate_with_token: true
      # lre_domain: "MYDOMAIN" #value provided as CI/CD variable
      # lre_project: "myproject" #value provided as CI/CD variable
      lre_test: "YamlTest/createTestFromYaml.yaml"
      lre_test_instance: "AUTO"
      lre_timeslot_duration_hours: 0
      lre_timeslot_duration_minutes: 30
      lre_post_run_action: "Collate and Analyze"
      lre_vuds_mode: false
      lre_trend_report: "ASSOCIATED"
      lre_status_by_sla: false
      lre_enable_stacktrace: true
      lre_output_dir: "$CI_PROJECT_DIR"
      RELEASE_TAG: "latest"  # Default value for manual runs, to be overridden

    # The following commented-out section is not required if your gitlab runner is already configured to have them
    # Otherwise you will need to have them installed manually or installed by the following commands
    # (which will require the sudoers to provide permission to gitlab-runner)
    # before_script:
      # - apt-get update -qq
      # - apt-get install -y openjdk-11-jdk curl
      # - curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
      # - apt-get install -y nodejs

    test-release:
      stage: test
      script:
        - if [ -z "$RELEASE_TAG" ]; then echo "No RELEASE_TAG specified. Exiting."; exit 1; fi
        - echo "Testing release $RELEASE_TAG"
        - URL="$CI_PROJECT_URL/-/jobs/artifacts/$RELEASE_TAG/raw/release/release-package.zip?job=package"
        - echo "Downloading from $URL"
        - curl --location --output release-package.zip "$URL"
        - echo "Downloaded file details:"
        - ls -lh release-package.zip
        - file release-package.zip
        - mkdir release  # Create a release directory
        - unzip release-package.zip -d release  # Extract contents into the release directory
        - echo "List of files extracted from release-package.zip:"
        - ls -l release  # List files in the release directory
        - cd release
        - node app.js
      artifacts:
        paths:
          - LreResult/
      when: manual  # Allow manual triggering
      allow_failure: false

The contents of the YAML file are:

Copy code

    ##################################################
    group:
      - group_name: "demo_script_new"
        vusers: '2'
        #script_id: 175
        script_path: "daniel\\scripts\\demo_script_new"
        lg_name:
          - "LG1"
    scheduler:
      rampup: '10'
      duration: '60'
    automatic_trending:
      report_id: 6
      max_runs_in_report: 3
    ##################################################

Back to top

See also:

- Synchronize with Git
- GitHub action
- Plug-ins

https://admhelp.microfocus.com Enterprise Performance Engineering,LoadRunner Enterprise 8942
Tips to improve your search results...OpenText™ Enterprise Performance Engineering Help Center OpenText™ Enterprise Performance Engineering Help 26.1 All View Local Help Center View Online Help Center Version: