GitLab integration

The LoadRunner Enterprise Test Execution GitLab integration allows you to trigger load tests on a LoadRunner Enterprise 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 will most likely provide 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.

To set up variables (subject to change depending on GitLab UI):

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 LRE, 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 will instruct .gitlab-test-release.yml to download the artifact of the release package during the build of the release and use it to run the LRE 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.

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

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:

##################################################
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 plug-in
• Plug-ins