Share this page

# Synchronize with Git

This topic describes how to synchronize with Git by uploading OpenText VuGen and/or JMeter scripts stored in a Git repository to a project.

In this topic:

## Create a Git repository

The Git integration, available for plug-in versions 1.1.0 and later, enables you to perform the following.

Action | Description
--- | ---
Synchronize scripts | Synchronize scripts by uploading OpenText VuGen and JMeter scripts stored in a Git repository to a project. For details, see Synchronize with Git.
Synchronize tests | Synchronize tests from YAML files saved in a Git repository to a project. For details, see Synchronize with Git.
Run tests | Create tests from YAML input added to a field within the Jenkins Job configuration, and then run the tests. For details, see Run a performance test.

To synchronize scripts, copy the scripts generated in VuGen (or JMeter tests which are also supported) to one or several sub-folders in your GitHub repository.

You can create a new Git repository, or use an existing one to store your performance test scripts.

In the example below, the Git repository contains a folder named "scripts", and within it, different folders, each containing a performance script.

The plug-in identifies each folder that contains a .usr or .jmx file, which it compresses, and uploads to OpenText Enterprise Performance Engineering.

Back to top

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

This section explains how to automatically trigger a Jenkins build after committing a script with changes to the Git repository.

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” (see the next step for details on retrieving 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 plug-ins. If you can’t find them, you can install them from the Available tab.

   2. To retrieve the Webhook URL from the Jenkins server perform the following:

      1. From Jenkins Home, select Manage Jenkins > Configure System, and search for "GitHub Servers".

      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.

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

      Click Update webhook.

Back to top

## Upload the plug-in to the Jenkins server

The Git integration plug-in enables you to synchronize performance test scripts from a Github repository to a project on the OpenText Enterprise Performance Engineering server.

1. Install the Jenkins server.

2. Install the OpenText Enterprise Performance Engineering integration with Git plug-in.

   For details on downloading and installing this plug-in, see Integration With Git.

   1. Go to Jenkins home > Manage Jenkins > Manage Plugins > Advanced.

   2. In the Upload Plugin section, select the micro-focus-performance-center-integration.hpi file and click Upload.

   3. Restart Jenkins if required.

Back to top

## Configure a Jenkins job to synchronize scripts

You can create a Jenkins project to synchronize OpenText Enterprise Performance Engineering with Git by uploading OpenText VuGen and JMeter scripts stored in a Git repository to an OpenText Enterprise Performance Engineering project.

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 check box, and enter 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 to clone to the job's workspace.

   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 list, and select Synchronize OpenText Enterprise Performance Engineering with Git.

   5. Enter the following build step details.

      Argument | Description
      --- | ---
      Description | Provide your own description of the build step purpose.
      Server | Enter the hostname or IP address of the OpenText Enterprise Performance Engineering server. If the server is not using the default port (80), mention it by adding a colon (:) and then the port number. Example: `myserver.mycompany.net` , `182.138.255.1` or `myserver.mycompany.net:81`. Note: Do not use the full URL of server. For example, using `https://myServer/LoadTest` fails. Instead, just specify the `myServer` value in this field, and select the Use HTTPS Protocol option if a secured protocol is required.
      Use HTTPS Protocol | Select this option if the server is using a secured connection.
      <credentials> | Depending on the authentication type required by your server, credentials can be a user name and password, or an API key for SSO or LDAP authentication. Username and password: User name. Enter the user name required to connect to the server. Password. Enter the password required to connect to the server. SSO or LDAP authentication: Select Authenticate with token. Enter the Client ID and Secret key obtained from your site administrator in the Id Key and Secret key fields. For details, see Set up API access.
      Domain | Enter the domain of the project to which the scripts are uploaded.
      Project | Enter the name of the project in which the test to run is stored.
      Local Proxy | Add your local proxy in the format: `http(s)://host:port` and enter the user name and password, or leave empty if not using a local proxy. Note: PAC (proxy auto-config) and Automatic configuration script are not supported.
      Proxy Credentials | Proxy credentials or parameter pointing to such credentials.
      Test Plan folder | The Test Plan folder path in which the scripts are loaded. Available paths can be found in the test management tree in the user interface. The path must begin with "Subject" and be separated with backslashes (\). The path is case-sensitive.
      Upload script mode | This corresponds to the similar option existing in OpenText Enterprise Performance Engineering or OpenText VuGen: All Files: All script files are uploaded. This takes longer to load. Runtime Files: Only the required files are uploaded. This includes script files, Runtime Settings, and parameter files. Recommended value: Runtime Files
      Delete script | This option enables you to synchronize script deletion from Git to OpenText Enterprise Performance Engineering. Recommended value: Yes
      Import Tests (Available in plug-in version 1.1.0) | Instructs the plug-in to synchronize the YAML file stored in Git. For details, see Configure a Jenkins job to synchronize tests below.

Back to top

## Configure a Jenkins job to synchronize tests

Available in plug-in versions: 1.1.0 and later

You can create a Jenkins project to synchronize performance tests from YAML files stored in a GitHub or GitLab repository to an OpenText Enterprise Performance Engineering project. The following procedure imports tests from YAML files that are saved in a Git repository.

To synchronize tests:

1. Perform the steps in Configure a Jenkins job to synchronize scripts, and for the Import Tests option, select Yes.

2. Copy your YAML files to a folder in your Git repository (YAML files under the root of the Git repository are ignored). The plug-in creates the test in the project according to:

   - The file name (without extension) which is used as the test name.

   - The location of the file in the Git repository which is 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 described in the tables below.

     Note:

     - All parameters must be in lowercase.

     - When a backslash (\) occurs in a value provided to a parameter (for example, a folder separator in a file path), a double backslash (\\) must be used instead.

Back to top

## YAML parameters

This section describes the YAML file parameters.

Root parameters

These are the root parameters to be used in the file content.

Parameter | Description | Required
--- | --- | ---
controller | Defines the Controller to be used during the test run (it must be an available host in the project). If not specified, a Controller is chosen from the Controllers available in the project. Available with plug-in version 1.1.1 and later: You can provision a Controller as a Docker image by specifying the value "Elastic" and providing a value for the controller_elastic_configuration parameter. For parameter details, see YAML controller_elastic_configuration parameters. | No
lg_amount | Number of load generators to allocate to the test (every group in the test is run by the same load generators). | Not required if each group defined in the group parameter defines the load generators it uses by the lg_name parameter. For details, see YAML group parameters.
group | Lists all groups or scripts defined in the test. The parameter to be used in each group are specified in the YAML group parameters table. | Yes
scheduler | Defines the duration of a test, and determines whether virtual users are started simultaneously or gradually. For parameter details, see YAML scheduler parameters. | No
lg_elastic_configuration (Available with plug-in version 1.1.1 and later) | Defines the image to be used to provision load generators. For parameter details, see YAML lg_elastic_configuration parameters. | Yes, if a load generator is defined to be provisioned from a Docker image.
controller_elastic_configuration (Available with plug-in version 1.1.1 and later) | Defines the image to be used to provision the Controller. For parameter details, see YAML controller_elastic_configuration parameters. | Yes, if the Controller is defined to be provisioned from a Docker image.
automatic_trending | Defines the association to an existing trend report. For parameter details, see YAML automatic_trending parameters. | No

YAML group parameters

The following are parameters to be used in each group.

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 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 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 an existing load generator that is 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. This option requires that the lg_elastic_configuration parameter is defined. For parameter details, see YAML lg_elastic_configuration parameters. | No
command_line | The command line applied to the group. | No
rts | Object defining the runtime settings of the script. For parameter details, see YAML rts parameters. | No

YAML rts parameters

The following are parameters to be used in runtime settings.

Parameter | Description | Required
--- | --- | ---
pacing | Can be used to define the number of iterations the script runs and the required delay between iterations. For parameter details, see pacing. | No
thinktime | Can be used to define think time. For parameter details, see thinktime. | No
java_vm | Can be used when defining Java environment runtime settings. For parameter details, see java_vm. | No
jmeter | Can be used to define JMeter environment runtime settings. For parameter details, see jmeter. | No

pacing

Parameter | Description | Required
--- | --- | ---
number_of_iterations | Specifies the number of iterations to run; this must be a positive number. | Yes
type | Possible values for type attribute are: immediately: ignores the delay and delay_random_range parameters. This is the default value when no type is specified. fixed delay: The delay parameter is mandatory. random delay: The delay and delay_random_range parameters are mandatory. fixed interval: The delay parameter is mandatory. random interval: The delay and delay_random_range parameters are mandatory. | No
delay | Non-negative number (less than delay_at_range_to_seconds when specified). | Depends on the value provided for the type parameter.
delay_random_range | Non-negative number. It is added to the value assigned to the delay parameter (the value is randomly chosen between the value provided to the 'delay' parameter and the same value to which is added the value of this parameter). | Depends on the value provided for the type parameter.

thinktime

Parameter | Description | Required
--- | --- | ---
type | The thinktime type attribute is one of: ignore: This is the default value when no type is specified. replay: Provide the limit_seconds parameter with value (optional). modify: Provide the limit_seconds parameter with a value (optional). The multiply_factor parameter must be set with value. random: Provide the limit_seconds parameter with value (optional). The min_percentage and max_percentage parameters must be set with values. | No
min_percentage | This must be a positive number. | Depends on the value provided for the type parameter.
max_percentage | This must be a positive number (it must be larger than the value provided for the min_percentage parameter). | Depends on the value provided for the type parameter.
limit_seconds | This must be a positive number. | Depends on the value provided for the type parameter.
multiply_factor | The recorded think time is multiplied by this factor at runtime. | Depends on the value provided for the type parameter.

java_vm

Parameter | Description | Required
--- | --- | ---
jdk_home | The JDK installation path. | No
java_vm_parameters | List the Java command line parameters. These parameters can be any JVM argument. The common arguments are the debug flag (-verbose) or memory settings (-ms, -mx). In additional, you can also pass properties to Java applications in the form of a -D flag. | No
use_xboot | Boolean: Instructs VuGen to add the Classpath before the Xbootclasspath (prepend the string). | No
enable_classloader_per_vuser | Boolean: Loads each Virtual User using a dedicated class loader (runs Vusers as threads). | No
java_env_class_paths | A list of classpath entries. Use a double backslash (\\) to separate folders. | No

jmeter

Parameter | Description | Required
--- | --- | ---
start_measurements | Boolean value to enable JMX measurements during a performance test run. | No
jmeter_home_path | Path to JMeter home. If not defined, the path from the %JMETER_HOME% environment variable is used. | No
jmeter_min_port | This number must be lower than the value provided in the jmeter_max_port parameter. Both jmeter_min_port and jmeter_max_port parameters must be specified otherwise the default port values is used. | No
jmeter_max_port | This number must be higher than the value provided in the 'jmeter_min_port' parameter. Both jmeter_min_port and jmeter_max_port parameters must be specified otherwise the default port values is used. | No
jmeter_additional_properties | JMeter additional properties file. Use a double backslash (\\) to separate folders. | No

YAML scheduler parameters

The following are parameters to be used in the scheduler.

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

YAML lg_elastic_configuration parameters

Available with plug-in versions: 1.1.1 and later

The following are parameters to be used to provision load generators.

Parameter | Description | Required
--- | --- | ---
image_id | The image ID can be retrieved from: Administration (contact your administrator if you do not have admin permissions). Select Configuration > Orchestration, and click the Docker Images tab to display the list of all available Docker images for Load Generator purposes with their ID. You can check that the images are available to your project from the Orchestrators tab. A REST API command applied on the project (replace the bracketed values): GET - http(s)://(Server):(PortNumber)/LoadTest/rest/domains/ (DomainName)/projects/(ProjectName)/dockerimages/ and select any valid image that does not have the value 'controller' for purpose. | Yes if one of the load generator is defined to be provisioned from the Docker image.
memory_limit | This parameter can be retrieved from the Performance testing application. In the navigation toolbar, select Test Management > Tests & Scripts. Select a performance test in the test management tree, and click Edit Test. Click the Assign LGs button , and in the Elastic section, select DOCKER1 and choose the relevant image (based on the image name). Use the values provided in the Memory (GB) dropdown list (if none specified, ignore this parameter). | Yes, if the image is defined with resource limits.
cpu_limit | This parameter can be retrieved from the Performance testing application. In the navigation toolbar, select Test Management > Tests & Scripts. Select a performance test in the test management tree, and click Edit Test. Click the Assign LGs button . In the Elastic section, select DOCKER1 and choose the relevant image (based on the image name). Use the values provided in the CPUs dropdown list (if none specified, ignore this parameter). | Yes, if the image is defined with resource limits.

YAML controller_elastic_configuration parameters

Available with plug-in versions: 1.1.1 and later

The following are parameters to be used when provisioning a Controller as a Docker image.

Parameter | Description | Required
--- | --- | ---
image_id | The image ID can be retrieved from: Administration (contact your administrator if you do not have admin permissions). Select Configuration > Orchestration, and click the Docker Images tab to display the list of all available Docker images for Controller purposes with their ID. You can check that the images are available to your project from the Orchestrators tab. A REST API command applied on the project (replace the bracketed values): GET - http(s)://(Server):(PortNumber)/LoadTest/rest/domains/ (DomainName)/projects/(ProjectName)/dockerimages/ and select any valid image that does not have the value 'controller' for purpose. | Yes if one of the Controller is defined to be provisioned from the Docker image.
memory_limit | This parameter can be retrieved from the Performance testing application. In the navigation toolbar, select Test Management > Tests & Scripts. Select a performance test in the test management tree, and click Edit Test. Click the Assign LGs button . In the Elastic section, select DOCKER1 and choose the relevant image (based on the image name). Use the values provided in the Memory (GB) dropdown list (if none specified, ignore this parameter). | Yes, if the image is defined with resource limits.
cpu_limit | This parameter can be retrieved from the Performance testing application. In the navigation toolbar, select Test Management > Tests & Scripts. Select a performance test in the test management tree, and click Edit Test. Click the Assign LGs button . In the Elastic section, select DOCKER1 and choose the relevant image (based on the image name). Use the values provided in the CPUs dropdown list (if none specified, ignore this parameter). | Yes, if the image is defined with resource limits.

YAML automatic_trending parameters

The following are parameters to be used to define the association to an existing trend report.

Parameter | Description | Required
--- | --- | ---
report_id | The ID of the trend report to associate the test run analysis with. | No
max_runs_in_report | Maximum number of trends in a report. Default: 10 | No

Back to top

## YAML file examples

This section illustrates the use of YAML files with the parameters described above.

Example 1: Run a test and upload the reports as artifacts

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.

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
    ##################################################

Example 2: Run two scripts

Copy code

    ##################################################
    group:
      - group_name: "TEstInt"
        vusers: '20'
        script_path: "plugin\\TEstInt"
        lg_name:
          - "LG1"
          - "LG2"
      - group_name: "Mtours"
        vusers: '20'
        script_path: "plugin\\mtours"
        lg_name:
          - "LG3"
          - "LG4"
     scheduler:
       rampup: '45'
       Duration: '300'
     ##################################################

In the example above:

- The plug-in 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 project.

- In the content:

  - Since no Controller and no load generator amount were specified, a random available Controller is allocated to the test just before it is run, and the lg_name parameter specified in each group is used.

  - In the group parameter:

    - Two scripts are added, each with a unique value in the group_name parameter, and the number of virtual users to run the group (vusers).

    - Since the ID of the scripts in the project is unknown, the script_path parameter (without "Subject") followed by the script name is used, with double backslashes for separators.

    - The load generators that are used by each group are specified. In this case, load generators are automatically matched as we use the 'LG' prefix.

- In the scheduler, all Vusers are initialized gradually (every 45 seconds), and the test stops after 5 minutes (300 seconds).

Example 3: Configure runtime settings

Copy code

    ##################################################
    controller: "mycontroller"
    lg_amount: 3
    group:
      - group_name: "JavaVuser_LR_Information_pacing_immediately_thinktime_ignore"
        vusers: 50
        script_id: 394
        rts:
          pacing:
            number_of_iterations: 2
            type: "immediately"
          java_vm:
            jdk_home: "C:\\Program Files\\Java\\jdk1.8.0_191"
            java_vm_parameters: "java_vm_parameters"
            enable_classloader_per_vuser: true
            use_xboot: true
            java_env_class_paths:
              - "java_env_class_path1"
              - "java_env_class_path2"
          thinktime:
            type: "ignore"

      - group_name: "JavaHTTP_BigXML_pacing_fixed_delay_thinktime_replay"
        vusers: 50
        script_path: "scripts\\java_protocols\\JavaHTTP_BigXML"
        rts:
          pacing:
            number_of_iterations: 2
            type: "fixed delay"
            delay: 10
          java_vm:
            jdk_home: "C:\\Program Files\\Java\\jdk1.8.0_191"
            java_vm_parameters: "java_vm_parameters"
            enable_classloader_per_vuser: true
          thinktime:
            type: "replay"
            limit_seconds: 30

      - group_name: "JavaVuser_LR_Information_immediately_pacing_random_delay_thinktime_modify"
        vusers: 50
        script_id: 394
        rts:
          pacing:
            number_of_iterations: 2
            type: "random delay"
            delay: 10
            delay_random_range: 20
          java_vm:
            jdk_home: "C:\\Program Files\\Java\\jdk1.8.0_191"
            java_vm_parameters: "java_vm_parameters"
            enable_classloader_per_vuser: true
            java_env_class_paths:
              - "java_env_class_path1"
              - "java_env_class_path2"
          thinktime:
            type: "modify"
            limit_seconds: 30
            multiply_factor: 2

      - group_name: "JavaHTTP_BigXML_pacing_fixed_interval_thinktime_random"
        vusers: 50
        #script_id: 392
        script_path: "scripts\\java_protocols\\JavaHTTP_BigXML"
        rts:
          pacing:
            number_of_iterations: 2
            type: "fixed interval"
            delay: 10
          java_vm:
            jdk_home: "C:\\Program Files\\Java\\jdk1.8.0_191"
            java_vm_parameters: "java_vm_parameters"
            enable_classloader_per_vuser: true
            java_env_class_paths:
              - "java_env_class_path1"
              - "java_env_class_path2"
          thinktime:
            type: "random"
            limit_seconds: 30
            min_percentage: 2
            max_percentage: 3

      - group_name: "JavaHTTP_BigXML_pacing_random_interval"
        vusers: 50
        script_path: "scripts\\java_protocols\\JavaHTTP_BigXML"
        rts:
          pacing:
            number_of_iterations: 2
            type: "random interval"
            delay: 10
            delay_random_range: 20
          java_vm:
            jdk_home: "C:\\Program Files\\Java\\jdk1.8.0_191"
            java_vm_parameters: "java_vm_parameters"
            enable_classloader_per_vuser: true
            java_env_class_paths:
              - "java_env_class_path1"
              - "java_env_class_path2"

      - group_name: "Mtours_pacing_random_interval"
        vusers: 50
        script_path: "scripts\\Mtours"
        rts:
          pacing:
            number_of_iterations: 2
            type: "random interval"
            delay: 10
            delay_random_range: 20
          jmeter:
            start_measurements: true
            jmeter_home_path: "c:\\jmeter"
            jmeter_min_port: 2001
            jmeter_max_port: 3001
            jmeter_additional_properties:
            "jmeter_additional_properties"

      - group_name: "Mtours_pacing_random_interval_Jmeter_default_port"
        vusers: 50
        script_path: "scripts\\Mtours"
        rts:
          pacing:
            number_of_iterations: 2
            type: "random interval"
            delay: 10
            delay_random_range: 20
          jmeter:
            start_measurements: true

    scheduler:
      rampup: 120
      duration: 600
    ##################################################

In the example above:

- The plug-in 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 project.

- Since the controller and the lg_amount parameters are specified, the specified Controller is used to run the test, and three automatch load generators are used and shared by all groups.

- The content of the file is defined with seven groups, all being set with the “rts” parameter:

  - The pacing parameter is used with different options for all groups.

  - The java parameter is used for five scripts with JavaVM for protocol.

  - The thinktime parameter is used with different options for four groups.

  - The jmeter parameter is used for two scripts with JMeter for protocol.

- In the scheduler, all Vusers are initialized gradually (every 120 seconds), and the test stops after 10 minutes (600 seconds).

Back to top

## Run the job

You can run the job by either:

- Merging a pull request to the master branch.

  The usual process is as follows:

  1. Commit a change to a branch (or fork).

  2. Push the change (pushing changes to master is not usually allowed unless you have admin rights).

  3. Create pull request.

  4. Merge pull request (this operation triggers the build as it pushes the change to master branch).

- Manually triggering the build from Jenkins.

Note:

- Make sure the machine running the job (the Jenkins server or a distributed node defined in the Jenkins server) can fetch everything required from the Git repository. You probably need to install Git client and configure the operating system of the machine that runs the build to allow this.

- 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 is synchronized.

Back to top

## Review the results

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

Back to top

## Configure Jenkins using GitLab (instead of GitHub)

You can perform all the GitHub configuration steps explained above using GitLab instead. Here are the steps:

1. Configure Jenkins with GitLab

   1. From Jenkins Home, select Manage Jenkins > Configure System.

   2. Define a GitLab connection and a GitLab Notifier configuration (both require a token from GitLab).

      Tokens can be retrieved from GitLab using User Settings > Access Token (you can set tokens with an expiration date, revoke them, and grant permissions and define permission levels).

2. Configure a Jenkins job

   Create a new job, or use an existing one with the following settings:

   - In the Source Code Management section, allow the job to clone the repository within the workspace. Select the Git option, enter the Git URL in Repository URL field, and provide credentials for allowing access to this repository.

   - If you want to have the build triggered at a GitLab event, define a trigger in the Build Triggers section. Jenkins can create a secret token that can be used in the next step when creating a hook in the GitLab project (as described in the next section).

3. Configure your GitLab project

   You can do this by performing either of the following.

   Option | Description
   --- | ---
   Create a GitLab Hook to trigger a Git Merge | To create a GitLab Hook to trigger a Jenkins build Git Merge: In your GitLab project, open Settings > Integrations. In the URL section, add the URL of your Jenkins job and use the secret token generated in the previous step if required.
   Define the .gitlab-ci.yml file to trigger a Jenkins job | Define the .gitlab-ci.yml file of your GitLab project to run a cURL command triggering a Jenkins job. This command can be performed from a Shell executor and send parameters which is not possible to do in the previous step. A simple command triggering Jenkins job with parameters (YAML_TEST being the parameter in the example) can be like this: curl -i -X POST http://MyJenkinsServer:8080/jenkins/job/MyJenkinsJob/buildWithParameters?YAML_TEST=Tests\yaml\yamlTest2.yaml (You can run this from a command prompt to test it. You might want to download cURL and install it in your GitLab Runners and in the machine testing the command.)

Back to top

## Tips and troubleshooting

This section provides information for troubleshooting issues related to the integration with Git.

Area | Description
--- | ---
Uploading builds | The first successful build uploads all scripts (this might take longer to sync). Subsequent builds include modifications from the previous successful build only, and should be much faster.
Deleting scripts | Synchronizing script deletion is optional in the build's configuration (it is enabled by default). However, failing to delete scripts in a project after they have been deleted in the Git repository does not cause the build to fail.
Version control | Projects with Version Control enabled are not supported.

Back to top

See also:

- Synchronize with Git
- GitHub action
- GitLab integration
- 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: