Share this page

# GitLab CI integration

Integrate GitLab CI with OpenText Software Delivery Management, utilizing webhooks and secure credentials.

The integration enables you to receive and process pipeline events from GitLab, providing enhanced visibility and traceability for your CI/CD workflows.

In this topic:

## Supported features

The GitLab CI integration provides the following functionality within OpenText Software Delivery Management.

Pipelines and builds

- Collect pipeline step results
- Run pipeline
- Run pipeline with parameters

Hierarchy in topology

- Multi-branch pipeline
- Multiple spaces

Test automation

- Run on-demand automated JUnit tests
- Run UFT One automated tests

Back to top

## Prerequisites

Before starting the integration, ensure you have the following:

- GitLab.com, GitLab dedicated, or self-managed GitLab version 18.5 and above
- Administrator access on space and workspace
- Administrator access to your GitLab projects
- (Optional) Ultimate GitLab license for group/instance-level features

Back to top

## Configuration parameters

Configure the following parameters to support the GitLab integration. They can be set at the site or space level.

Parameter | Default | Description
--- | --- | ---
CI_INTEGRATION_GITLAB_ARTIFACT_NAME | N/A | Name of the artifact file containing parameters and values.
CI_INTEGRATION_GITLAB_USE_PARAMETERS | false | Decide on whether to use inputs or variables.
CI_INTEGRATION_GITLAB_VARIABLE_SOURCES | GROUP, PROJECT | Where variables can be sourced from: GROUP, PROJECT, INSTANCE, or NONE.
ENABLE_CI_INTEGRATION_FOR_GITLAB | false | Enables or disables GitLab integration. Enable the parameter on the space in which the CI server is defined.
GITLAB_CONNECTION_TIMEOUT_IN_SECONDS | 10 | Defines a timeout (in seconds) for connection to GitLab servers.
GITLAB_READ_REQUEST_TIMEOUT_IN_SECONDS | 30 | Defines a timeout (in seconds) for any read request to GitLab.

For details, see Configuration parameters.

Back to top

## Prepare GitLab access tokens

To allow interaction with GitLab, you need an access token. The token must be able to read repository data and variables as needed for your integration scenario. You can create one of the following token types: Personal access token, Project-level token, Group/instance-level token.

Token requirements:

- Minimum required permission:

  - All tokens (except Group): Maintainer

  - Group token: Owner

- Required scopes: api and read_api

For details, refer to the GitLab documentation.

Back to top

## Set up credentials

Add the GitLab token as credentials in OpenText Software Delivery Management.

To add credentials:

1. Open the global menu and select Administration > General Settings.

2. Select a shared space or workspace.

3. Select the Credentials tab.

4. Click the + Credentials button.

5. Paste the GitLab token into the password field.
6. In the Name and User Name fields, assign descriptive values that help identify the credential, such as the associated GitLab user or purpose.

Back to top

## Add a GitLab CI server

CI servers are defined at the workspace level.

To add a GitLab CI server:

1. Select a workspace.
2. Select the DevOps > CI Servers tab.
3. Click the + CI Server button.
4. Enter a name for the CI server and select GitLab as the CI Server Type.
5. Enter the base URL for your GitLab instance. Example: `http://example.gitlab.com`.
6. After the CI server is created successfully, add the Credential field to the CI server grid and assign the previously created credential.

Back to top

## Create API access tokens

Create API access tokens to use in the GitLab wekhooks.

To create API access tokens:

1. Select the shared space .
2. Select the API Access tab.
3. Click the + API access button.
4. Select Token as the type.
5. Assign the CI/CD Integration role for the relevant workspace.
6. Copy the generated token and store it securely. It is displayed only once. If lost, the token needs to be regenerated.

Back to top

## Configure GitLab webhooks

Webhooks can be defined at the project or group level (depending on your GitLab license). Go to your GitLab project or group, and add a webhook with the settings below.

- URL: `{{SDM_url}}/api/shared_spaces/{{space_id}}/analytics/ci/gitlab_ci/webhook-events`
  - SDM_url: The base URL of OpenText Software Delivery Management.
  - space_id: The ID of the shared space where the CI Server was added
- Custom headers:
  - `ALM-OCTANE-TECH-PREVIEW: true`
  - `Authorization: Bearer {{SDM_token}}` (where SDM_token is the API access token generated by OpenText Software Delivery Management)
- Triggers:
  - Job Events
  - Pipeline Events

Back to top

## Work with pipelines

Use the following procedures to work with GitLab pipelines in OpenText Software Delivery Management.

Add a GitLab pipeline

1. Open the global menu and select Quality Management > Pipelines > Management.
2. Click the + Pipeline button.
3. Select the GitLab CI server you configured, then choose the relevant job from your GitLab project.

A multi-branch pipeline is created in OpenText Software Delivery Management, which serves as a reference to the corresponding GitLab project.

Manage multi-branch pipelines

Multi-branch pipelines automatically track runs from any branch in your GitLab project. Users can configure branch filters to control which branches are monitored and injected into OpenText Software Delivery Management.

Note: The pipeline must be executed at least once in GitLab for it to appear in OpenText Software Delivery Management.

View pipeline runs and test results

Pipeline runs are displayed in OpenText Software Delivery Management from GitLab. Note the following:

- Configure your `.gitlab-ci.yml` to archive XML test result files at the end of each test job.
- Test results are automatically detected and injected if they are archived as XML artifacts.
- After the job completes, the results are analyzed and displayed in the pipeline run.

Back to top

## Run pipelines

You can run single-branch pipelines directly from OpenText Software Delivery Management. Multi-branch pipelines can only be run from GitLab.

Set the CI_INTEGRATION_GITLAB_USE_PARAMETERS accordingly to support pipelines with parameters or variables. It is recommended to use input parameters rather than variables.

Pipeline configuration | Run details
--- | ---
Pipelines without parameters or variables | Run directly from OpenText Software Delivery Management without any additional configuration.
Pipelines with parameters | Ensure the pipeline uses the standard `gitlab-ci.yml` file name. Parameters are securely fetched from a JSON file located in the root of the GitLab repository. The file name must match the value configured in the CI_INTEGRATION_GITLAB_ARTIFACT_NAME parameter. JSON file structure:
    [
    	{
    	"{{param_name}}": {{param_value}}
    	}
    ]
Where `param_name` is the name defined in the YAML file.
Pipelines with variables | The variables defined in GitLab are used. To fetch current parameter values from GitLab, select Sync with CI.

Back to top

## Run tests

Test runners in OpenText Software Delivery Management enable users to execute automated tests through dedicated GitLab pipelines.

The corresponding pipeline for the test runner needs to be added to OpenText Software Delivery Management prior to running automated tests.

Configure the following variables at the instance, group, or project level in GitLab: `testsToRun`, `suiteId`, `suiteRunId`, `executionId`, `testRunnerBranch` (optional)

Example (Maven): `mvn clean test -DTest=$testsToRun`

When creating a test runner in OpenText Software Delivery Management, select the appropriate testing framework (for example, JUnit or UFT). The `testsToRun` parameter is generated automatically based on the selection.

Back to top

https://admhelp.microfocus.com Software Delivery Management 8942
Tips to improve your search results... OpenText™ Software Delivery Management Help Center OpenText™ Software Delivery Management Help 26.1 All View Local Help Center View Online Help Center Version: