---
sourceDocument: Australia IT Service Management
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/it-service-management

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia IT Service Management

ft:clusterId :

    - itsm

bundleId :

    - itsm

workflow :

    - Technology


---

# GitLab pull request configurations

# GitLab pull request configurations {#ariaid-title1}

Release version: Australia  
Updated March 12, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of GitLab pull request configurations

This configuration enables ServiceNow DevOps Change Velocity to track and manage GitLab pull (merge) request pipeline executions as part of change acceleration before production deployment.
It collects GitLab merge request metadata, linking it with change records in Change Velocity for applying change policies, reviews, and approvals.
Supported actions include creating, updating, closing, re-opening, and merging pull requests.
The integration automatically updates pipeline statuses, pauses and resumes pipelines, and supports comments.
Show full answer Show less  

## Key Features

* Tracking of pull (merge) requests and related pipeline executions with metadata persisted in DevOps Change Velocity.
* Automatic synchronization of GitLab pipeline status with pull request status after change creation.
* Support for comments, with only the latest comment shown; maximum of 100 commits displayed in Change Velocity.
* Default email format for notifications is `<username>@noreply.gitlab.com`.
* Change approval policies can leverage pull request details for gating merges.
* Support for pipeline pausing and resuming as part of change approval workflows.

## Configuration and Requirements

* The DevOps property **Enable to track GitLab pull (merge) requests** must be enabled (default) to allow tracking; disable it to ignore pull request events.
* For orchestration and change approval tracking, use the GitLab Docker image for change tracking and implement custom pipeline actions accordingly.
* In GitLab project settings (cloud or on-premises 13.x), enable **"Pipelines must succeed"** under Merge Requests to block merges until changes are approved.
* Modify the project's `.yml` pipeline file by adding rules to detect merge request events at the workflow or job level, for example:

    workflow: rules: - if: $CIPIPELINESOURCE == 'mergerequestevent' - if: $CIPIPELINESOURCE != 'mergerequestevent'

or at job level:

    changeapproval: stage: changeapproval script: - sndevopscli create change -p '{"changeStepDetails":{"timeout":3600,"interval":100},"attributes":{"shortdescription":"Automated Software Deployment","description":"Automated Software Deployment.","assignmentgroup":"a715cd759f2002002920bde8132e7018","implementationplan":"Software update is tested and results can be found in Test Summaries Tab.","backoutplan":"When software fails in production, the previous software release will be re-deployed.","testplan":"Testing if the software was successfully deployed or not"}}' rules: - if: $CIPIPELINESOURCE == 'mergerequestevent' - if: $CIPIPELINESOURCE != 'mergerequestevent'

## Practical Impact

With this configuration, ServiceNow customers can enforce change approval policies directly within GitLab merge requests, ensuring that pipelines are blocked until changes are reviewed and approved. This tight integration streamlines change governance, supports automated deployment workflows, and provides visibility into pull request statuses and metadata within DevOps Change Velocity, enhancing control over production releases.  
GitLab pull (merge) request pipeline executions, which goes through change acceleration before moving to production, can be tracked in DevOps Change Velocity. This integration also collects GitLab merge requests meta data to persist in DevOps Change Velocity. The data is linked with the change created in the merge request pipeline execution and can be used for applying change policies, review, and approval.
* Create, update, close, re-open, and merge of pull requests are supported.
* Pull request pipeline execution for change acceleration in GitLab pipelines is supported. Pull request details will be available for use in the change approval policy.
* Status of GitLab pipeline is updated with the pull request status automatically after the change creation. The pipeline is paused and resumed automatically.
* Email ids are defaulted to the format \<user_name\>@noreply.gitlab.com.
* Comments are supported as part of merge request support. Create and update to pull requests are supported, while delete and edit are not supported.
* Maximum of 100 commits will be shown in DevOps Change Velocity. If you need to access more than 100, you must refer your GitLab instance. Only the latest comment is populated.
{#gitlab-pull-request-config__ul_o4n_1n3_51c}

## Settings to enable pull (merge) requests for change approval {#gitlab-pull-request-config__section_xbk_tf3_51c}

The DevOps property Enable to track GitLab pull (merge) requests. If not enabled, then pull (merge) requests and related events will be ignored enables the tracking of pull (merge) requests from GitLab in DevOps Change Velocity.  
Note:  
The property is enabled by default. If you don't want the merge (pull) requests to be tracked, you must disable it.

When enabled, the pull (merge) request changes will be reflected in DevOps Change Velocity. When disabled, DevOps Change Velocity ignores the pull request events.  
For pull request and orchestration pipeline linking and to enable change approval tracking, the following are required:

* Use GitLab Docker for change tracking. For detailed information, see [Implement custom actions for pipelines using Docker image](https://www.servicenow.com/docs/lyDd5Y1L9yyAuDzJFwe0tg "Use the ServiceNow custom actions to collect data related to change request creation, Sonar scan, artifact registration, and package registration in your pipeline with the help of the generic Docker Container Image.").
* From your GitLab project,
  1. Navigate to
     * For GitLab cloud: SettingsMerge requests.
     * For On premises (13.x): SettingsGeneralMerge requests.
     {#gitlab-pull-request-config__ul_tzw_xg3_51c}
  2. Select the Pipelines must succeed check box.

     With this selection, only if the change is approved, you can proceed with the merge request. That is, when the check box is selected, pull requests will
     be blocked until the change is approved.

  3. Select Save changes.
  {#gitlab-pull-request-config__ol_snt_ch3_51c}
* Navigate to your project and open the .yml file.  
  To the .yml file, add the following rule at the pipeline level or at specific job levels.

      rules:
       - if: $CI_PIPELINE_SOURCE == 'merge_request event'
       - if: $CI_PIPELINE_SOURCE != 'merge_request_event'

  Example for pipeline level:

      workflow:
        rules:
        - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
        - if: $CI_PIPELINE_SOURCE != 'merge_request_event' 

  Example for job level:

      changeapproval:
         stage: changeapproval
         script:
           - sndevopscli create change -p '{"changeStepDetails":{"timeout":3600,"interval":100},"attributes":{"short_description":"Automated Software Deployment","description":"Automated Software Deployment.","assignment_group":"a715cd759f2002002920bde8132e7018","implementation_plan":"Software update is tested and results can be found in Test Summaries Tab.","backout_plan":"When software fails in production, the previous software release will be re-deployed.","test_plan":"Testing if the software was successfully deployed or not"}}'
         rules:
         - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
         - if: $CI_PIPELINE_SOURCE != 'merge_request_event'

{#gitlab-pull-request-config__ul_wkm_x1j_51c}

*[\>]: and then