GitLab plugin

6 minute readExtensibilityDeveloper productivity

Plugin version 1.0.0

Revised on October 26, 2022

Overview

This plugin provides integration with GitLab REST API to create, manage, and manipulate Git repositories.

This plugin also adds support for GitLab CI/CD:

  • Continuous Integration (CI)

  • Continuous Delivery (CD)

  • Continuous Deployment (CD)

  • Trigger GitLab Pipeline

  • Webhook event processing support

Differences between Git and Git services

Git

Provides the main functionality for managing Git repositories and their data, which can be deployed anywhere.

GitHub

Provides additional GitHub REST API functionality.

Bitbucket

Provides additional Bitbucket REST v2 API functionality.

GitLab

Provides additional GitLab REST API functionality.

DevOps setup

The Git Setup for DevOps Insight procedure lets you configure the plugin and set up schedules to get the details periodically on the latest commits that were submitted by developers to the Git repositories.

You can run the following setup procedures:

  • Builds for DevOps Insight

  • Deployments for DevOps Insight

  • Incidents for DevOps Insight

  • Features for DevOps Insight

After you install the GitLab plugin, the setup procedures are available in the CloudBees project. When you uninstall the plugin, the setup procedures are no longer available in the CloudBees project.

To run the setup procedure:

  1. Select DevOps Essentials  Projects.

    • For the EC-Git Setup for DevOps Insight procedure, select Electric Cloud from the All Projects pulldown list. The list of procedures for the Electric Cloud project appears.

    • For the Git Setup for DevOps Insight procedure, select CloudBees from the All Projects pulldown list. The list of procedures for the CloudBees project appears.

  2. Select the Run Immediately button for the Git Setup for DevOps Insight procedure.

  3. Enter your parameter values into the dialog box. For descriptions of the parameters for this procedure, refer to Managing procedures

  4. Select OK.

Supported versions

The plugin has been tested with the following versions:

  • GitLab REST API v4

Plugin configurations

Plugin configurations are sets of parameters that can be applied across some, or all, of the plugin procedures. They can reduce the repetition of common values, create predefined parameter sets, and securely store credentials. Each configuration is given a unique name that is entered in the designated parameter for the plugin procedures that use them.

Creating plugin configurations

To create plugin configurations in CloudBees CD/RO, complete the following steps:

  1. Navigate to DevOps Essentials  Plugin Management  Plugin configurations.

  2. Select Add plugin configuration to create a new configuration.

  3. In the New Configuration window, specify a Name for the configuration.

  4. Select the Project that the configuration belongs to.

  5. Optionally, add a Description for the configuration.

  6. Select the appropriate Plugin for the configuration.

  7. Configure the parameters per the descriptions below.

Configuration procedure parameters

Parameter Description

Configuration name

The name for the created configuration.

Description

The configuration description.

URL base

The base URL to connect to. This is the GitLab API endpoint by default.

Request timeout

The timeout in milliseconds used when requesting a connection. Accepts only integer positive values.

Ignore SSL issues

Turns SSL verification off for instances with self-signed certificates.

PAT token

Bearer token to connect to the GitLab API.

Check Connection?

If checked, the connection endpoint and credentials entered as part of the configuration will be tested. If this option is checked, configuration will not be saved if the test fails.

Debug level

This option sets the debug level for logs. If Info is selected, only a summary is displayed. If Debug is selected, debug information is displayed. If Trace is selected, all requests and responses are displayed.

Plugin procedures

For all parameter descriptions in this section, required parameters are shown in bold italics.

Trigger GitLab Pipeline

Triggers a GitLab pipeline from CloudBees CD/RO.

Trigger GitLab Pipeline parameters

Parameter Description

Configuration name

The unique name for the configuration.

GitLab project ID or path

A path or identifier of a GitLab project.

Branch or tag name

A branch or tag name of a GitLab repository.

Trigger token

A token value of a trigger in the GitLab repository.

Collect Reporting Data

Collect Reporting Data parameters

Parameter Report Description

Configuration name

all

The previously defined plugin configuration name.

GitLab project ID or path

all

A path or identifier of a GitLab project.

Branch or tag name

build, deployment

A branch or tag name of a GitLab project.

Starting commit ID

build, deployment

A starting commit identifier. This commit ID is used to get the starting build number of a GitLab project.

Test category

quality

The category for the tests.

Assignee username

incident, feature

Return issues assigned to the given username. In GitLab CE, the assignee_username array can only contain a single value, otherwise, an invalid parameter error is returned.

Author username

incident, feature

Return issues created by the given username.

Iteration title

incident, feature

Return issues assigned to the iteration with the given title.

Labels

incident, feature

Newline-separated list of label names, issues must have all labels to be returned. None lists all issues with no labels. Any lists all issues with at least one label. Pre-defined names are case-insensitive.

Milestone

incident, feature

The milestone title. None lists all issues with no milestone. Any lists all issues that have an assigned milestone.

Initial records count

all

The count of records to retrieve from the server for the first time. If omitted, it is set to 10.

Metadata property path

all

Property sheet where run metadata will be stored. If omitted, /mySchedule/GitLab-%JobName%-%Report Object Type% is used for schedule contest. For all other contexts, the root is /myProject.

Transform script

all

Allows a user to provide Groovy closure for payload customization. This script is invoked by the plugin with one or two parameters. * If one parameter, it is a payload object. * If two parameters, the first parameter is a context object (FlowPlugin) and the second parameter is a payload object. In this example, the "flagsStale" field is changed in the payload object:

{ Object pluginObject, Map flag ->
        if (!flag) {
            return flag
        }

        flag["flagsStale"] *= 10

        return flag
    }

or

{ Map flag ->
        if (!flag) {
            return flag
        }

        flag["flagsStale"] *= 10

        return flag
    }

Preview

all

If selected, data is not sent to the reporting system. Use this option to preview gathered data.

Debug

all

If selected, the log level is set to Debug for the job.

Release name

all

The name of the CloudBees CD/RO release related to the collected data. Required for incident and feature procedures. This parameter is not required for build or deploy procedures.

Release project name

all

The name of the CloudBees CD/RO release related to the collected project data. Required for incident and feature procedures. This parameter is not required for build or deploy procedures.

Schedule frequency

all

Frequency (in minutes) for the schedule created to gather data.

Schedule project name

all

Name of the project where the schedule for gathering commit data for DevOps Insight will be created. The project is created if it does not already exist.

Schedule and procedure name to use

all

Name of the schedule and the procedure that will be created to gather commit data for DevOps Insight.

Report object type

all

The report object type.

Incidents: the report-specific notes

In the case of custom reports/dashboards, the plugin supports special features.

For specifying category use labels in format category::<category_name>.

For specifying status use labels in format status::<status_name>.

GitLab state Label Status

opened

Active

opened

status::active

Active

opened

status::new

New

closed

Resolved

closed

status::resolved

Resolved

closed

status::closed

Closed

Features: the report-specific notes

In the case of custom reports/dashboards, the plugin supports special features.

For specifying type use labels in format type::<type_name>.

Label Type

type::improvement

Improvement

type::new_feature

New Feature

type::story

Story

Story

For specifying resolution use labels in format resolution::<resolution_name>.

Label Resolution

resolution::cannot_reproduce

Cannot Reproduce

resolution::duplicate

Duplicate

resolution::fixed

Fixed

resolution::incomplete

Incomplete

resolution::wont_fix

Won’t Fix

For specifying status use labels in format status::<status_name>.

GitLab state Label Status

opened

Open

opened

status::open

Open

opened

status::inprogress

In Progress

opened

status::reopened

Reopened

closed

Resolved

closed

status::resolved

Resolved

closed

status::closed

Closed

For calculating story points, use the Time tracking: Estimated where 1 story point equals 1 work day.

Webhook support

The following trigger model was introduced in CloudBees CD/RO v10.9.

EC-GitLab allows the automated launch of CloudBees CD/RO runtimes for:

  • Push events

  • Merge request events

  • Pipeline event

  • Issue event

  • Confidential Issue event

For more information, refer to Configuring triggers.

Runtime values according to the event type

When a procedure or pipeline is triggered by a webhook event, additional properties are available under the /myWebhook property sheet. These properties are parsed from the event payload, which is saved in /my(Job|PipelineRuntime|etc.)/webhookData. The list of parsed properties depends on the event type. In some cases, the event payload may not contain the data for a property.

Push event

The runtime includes the following properties:

  • branch

  • repository

  • eventType

  • commitId

  • commitMessage

  • commitAuthorName

  • commitAuthorEmail

  • webhookData/ref

  • webhookData/branch

Merge Request event

The runtime includes the following properties:

  • branch

  • repository

  • eventType

  • commitId

  • commitAuthorName

  • commitAuthorEmail

  • webhookData/number

  • webhookData/title

  • webhookData/description

  • webhookData/state

  • webhookData/url

Pipeline event

The runtime includes the following properties:

  • branch

  • repository

  • eventType

  • commitId

  • commitAuthorName

  • commitMessage

  • webhookData/name

  • webhookData/number

  • webhookData/stage

  • webhookData/status

Issue event

The runtime includes the following properties:

  • branch

  • repository

  • eventType

  • webhookData/action

  • webhookData/description

  • webhookData/number

  • webhookData/state

  • webhookData/title

  • webhookData/url

Confidential Issue event

The runtime includes the following properties:

  • branch

  • repository

  • eventType

  • webhookData/action

  • webhookData/description

  • webhookData/number

  • webhookData/state

  • webhookData/title

  • webhookData/url

Branch names in Include Branches and Exclude Branches are patterns; the value main corresponds to any branch containing main, for example, test-*main*ing-data. To specify the exact branch, use line start and line end symbols, for example, ^main$’.

Release notes

GitLab 1.0.0

  • Initial Version. The following functionality was added.

    • Continuous Integration (CI)

    • Continuous Delivery (CD)

    • Continuous Deployment (CD)

    • Trigger GitLab Pipeline

    • Webhook event processing support