### Connect GitLab with DevRev to ensure seamless synchronization between the two systems, keeping issues and statuses updated in real-time based on code activity. GitLab for DevRev acts as a snap-in option, already utilized by several organizations to link DevRev issues with Git activities, thereby removing the need for manual issue management.

## Features

- **Branch creation activity**:

Updates associated work items when a new branch is created.
- **Pull request activity**:

Manages merge requests, including creating tasks, updating work items, and posting timeline events for key actions like creation, fulfillment, or rejection.
- **Commit tracking**:

Tracks commits associated with changes and updates works accordingly.
- **Magic commands**:

Supports magic commands within commit messages or Merge request descriptions to trigger additional actions.
- **PR reminder**:

Sends reminders for open Merge request based on specified criteria.

&nbsp;

## Installation

1. In DevRev, go to **Settings** &gt; **Snap-ins** and click **Explore Marketplace** in the top-right corner.
2. In the DevRev marketplace, find **GitLab for DevRev** and click **Install**.
3. During the snap-in installation, follow the instructions for installing the webhook. The webhook can be installed for an entire GitLab org or specific repositories.

&nbsp;

## Configuration

### Work automation

You can enable GitLab work automation through GitLab snap-in by establishing a GitLab connection and setting up a webhook.

### GitLab events

**Associate GitLab events with DevRev work**

You can associate GitLab commits, branches, and pull requests with the issues they correspond to. Doing so allows you to see GitLab activity in the corresponding DevRev issue and to act on those events, allowing you to automate your manual tasks.

**Commits**

You can associate commits with their corresponding issue by either of these methods:

- Including one or more \[issue IDs\](<https://docs.devrev.ai/integrations/gitlab#work-formats>) anywhere in the commit message.

&nbsp;- For example: `Fix: paging issue (issue:123)`

&nbsp;- For example: `Disable routing table ISS-123 and default to zero ISS-231`

- Including it in a branch that's associated with an issue.

**Branches**

You can associate a branch with its corresponding issues by including one or more issue IDs in the branch name. For example, `skr/iss-123/gitlab-snap-in`. All commits in this branch are automatically associated with the issue `iss-123`, without you having to explicitly include it in the commit message.

**Pull requests**

You can track your PRs with the corresponding issues by including one or more issue IDs in the PR title. For example, the PR title `iss-123 Fixes paging issue` links the PR to **ISS-123**.

### Work formats

You can explicitly link an issue ID to a commit, branch, or PR by using the following formats:

1. Using a display ID: `ISS-123`

2. Using an issue ID: `issue:123`

The display ID and issue ID are case-insensitive, the following are all acceptable and refer to the same issue:

- `ISSUE:123`
- `Issue:123`
- `issue:123`
- `ISS-123`
- `Iss-123`
- `iss-123`

&nbsp;

### Automation

After a GitLab event is associated with an issue, the status of that issue is automatically updated according to the stages you have selected and configured in the snap-in configuration screen. An example configuration of GitLab event-to-stage mapping can be:

<table style="min-width: 50px">
<colgroup><col style="min-width: 25px"><col style="min-width: 25px"></colgroup><tbody><tr><td colspan="1" rowspan="1">GitLab Event</td><td colspan="1" rowspan="1">Stage to assign</td></tr><tr><td colspan="1" rowspan="1">New Commit</td><td colspan="1" rowspan="1">In Development</td></tr><tr><td colspan="1" rowspan="1">New Branch</td><td colspan="1" rowspan="1">In Development</td></tr><tr><td colspan="1" rowspan="1">PR Opened</td><td colspan="1" rowspan="1">In Review</td></tr><tr><td colspan="1" rowspan="1">PR Closed</td><td colspan="1" rowspan="1">In Development</td></tr></tbody>
</table>

## Magic commands

With magic commands, you can perform various actions on your DevRev issues without leaving your IDE.

Supported magic commands:

### Toward

`/toward` can be used in a PR body to associate a PR with multiple DevRev issues without having to include them in the PR title. This associates the PR with the issues and the automations for stage changes apply just as if the issue IDs had been included in the title.

For example:

```auto
Fixes various formatting issues.
/towards ISS-31 ISS-232 ISS-421
```

&nbsp;

### Close

`/close` can be used in a PR body to both associate a PR with multiple DevRev issues and close them when the PR is merged. This associates the PR with the issues and the automations for stage changes apply as soon as the PR is pushed to GitLab. Once the PR is merged, the issues are closed.

For example:

This associates and closes all 3 issues.

```auto
Fixes various formatting issues.
/close ISS-31 ISS-232 ISS-421
```

&nbsp;

The special keyword `#work` can be used to close any issues already associated with a PR without having to specify them, such as when the issue IDs are already in the title.

```auto
Fixes various formatting issues.
/close #work
```

&nbsp;

## Automatic work detection

DevRev can automatically track your coding activity, even if you don't explicitly associate it with an issue. When you create a new branch or PR, and the branch or PR isn't explicitly associated with an issue, DevRev creates an issue for you. This is called this an autonomous issue or autonomous work item. DevRev tries to fill in the details for you but you can rename the issue in DevRev, or mark it as belonging to a different, existing issue.

To make use of this feature, go to **Configurations** &gt; **Track Autonomous work**.

- You can keep it turned off if you choose to explicitly create issues and link your GitLab activity or you can enable it either for PR creation or branch creation event.
- Select the default part under **Default part for autonomous issues** as a default Part ID if you enable **Track autonomous work**. Autonomous issues originating from GitLab are attributed to a default part. You can configure the default part while setting up your snap-in. Every issue in DevRev must have a part attribution.

### Autonomous work lifecycle

The lifecycle of autonomous work is also automatically updated based on the stage of GitLab event mapping. Closing of autonomous work items based on PR close event is a user-level setting that each individual developer can opt-in for based on their preferences under **My Settings** and toggle on **Enable for Me**.

## Task creation

DevRev can help you keep track of your issues while they're in the PR process. With PR Task Creation, a task is created for each PR reviewer in the DevRev issue associated with the PR. These tasks are automatically marked as completed when the reviewer approves or denies the PR or when the PR is closed for any reason.

To make use of this feature, the following conditions must be met:

1. Create task for PR reviewers is enabled under **My Settings** and toggle on **Enable for me**.
2. Each developer that wants to use this feature links their GitLab account by going to **Settings** &gt; **Account** &gt; **External Identities** and **Link GitLab Account**.

## PR reminders

PRs can often go stale and delay the development process. With PR reminders, developers can be automatically notified when a PR has been inactive for a period of time.

To make use of this feature, the following conditions must be met:

1. Enable the **Send reminders for inactive PRs** feature in the snap-in in your DevRev organization.
2. (Optional) Set the **Days before sending PR reminders**.

gitlab.svg

DevRev Marketplace

GitLab AirSync

Bring your code to the center of your decision-making with GitLab and DevRev. The GitLab integration allows users to onboard to DevRev and automate day-to-day activities, eliminating manual tasks.