GitLab autonomous work
GitLab autonomous work
Sync GitLab and DevRev so issue status is always real time and driven by code.

GitLab autonomous work

Sync GitLab and DevRev so issue status is always real time and driven by code.



Connect GitLab with DevRev, and ensure your work stays in sync between the two systems, such that issues and statuses are always real-time and driven by code activity. GitLab autonomous work is a predefined automation that has been used by several organizations, and ties DevRev issues closely with Git activities, eliminating the need for humans to manage issues.

Why should you un-manage your work? You should use this automation if you want to reduce work about work. Let machines manage issues, including creating and updating statuses, so developers can focus on work that matters. You’ll resonate with this, if you have ever:

  • Delivered a hot-patch and realized you never had an issue to track it
  • Wasted time just updating your team on the status of an issue
  • Or just felt that creating and managing issues is a distraction

If your team’s best practice is to link your GitLab activity to an existing issue-ID during branch creation, commits and MRs, then this automation will honor that and enable a GitLab driven issue state, without auto creating issues. We can link your DevRev issue to Bitbucket activity, through mention of issue-ID in branches, commits and PRs.

However, if you choose to work in GitLab and never created or linked an issue, you shouldn’t have to sweat it. This automation will automatically create issues that track all associated commits, branches and merge requests. The auto-created issue is enriched with MR description and related GitLab events. The status of these issues is driven by GitLab activity, and the issues will auto-transition stages, from In Development to In Review, and Closed. Your work is always accounted for and more importantly your team members have visibility and know what you’ve been up to, resulting in fewer interruptions.

How it works

To enable GitLab autonomous work, click on Install and we'll walk you through a few simple steps including connecting with GitLab. You'll have a default set of configuration settings and the option to further personalize this automation. Learn more about the features in this automation.


This automation is powerful, and has several configurable features. As they say, the power is in the defaults! When you install this Flow, we'll configure defaults that are tried and tested. You always have the option to personalize further.

Automatic status updates

You can associate GitLab commits, branches and merge requests with the DevRev issue 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 away your manual tasks. Mention DevRev issues in GitLab, and route the relevant GitLab events to this issue. They can be mentioned either as display IDs (ISS-34) or object IDs (issue:34), case insensitively. A DevRev issue can be mentioned in branch names, commit messages or MR titles.

Autocreate issues from GitLab branch

If you do not explicitly associate your DevRev issue to GitLab branches, commits or MRs, then we can autocreate your issues so you have an account of all your GitLab activity. This feature automatically creates an issue when a new branch is created, and tracks all associated commits and Merge Requests on this issue. The auto-created issues will move status based on Git activity, to in development based on branch and commit activity, and in review when MRs are created and merged. If desired, when MRs are merged, you can personalize the automation to move the issue to closed status. However, this template by default will keep the issue in an open state.

Autocreate issues from GitLab MRs

You can choose to automatically create issues when a new MR is created, and it is not linked to an existing DevRev Issue. The behavior is similar to how issues are auto-created with new branches. The auto-created issues will move status based on Git activity, and events are posted on the DevRev issue timeline. If desired, when MRs are merged, you can personalize the automation to move the issue to closed status. However, this automation by default will keep the issue in an open state. It is recommended you enable either one of Autocreate issue from GitLab branch or Autocreate issue from GitLab MR, but not both.

Issues autocreated from GitLab branches or MRs are called autonomous issues, and have the tag autonomous.

Attribute part to autonomous work

Autonomous issues originating from GitLab will be attributed to a default part. You can configure the default_part, while setting up your flow, Every issue on DevRev must have a Part attribution

Enrich autonomous work descriptions

Enrich autonomous issues with information derived from GitLab MR events. The title and description of an autocreated issue is enriched with the MR data. When a new GitLab MR is opened or edited, then the related autonomous issue description is updated with the latest MR description. If the user has removed the auto generated text, then the automation will no longer update the description from MRs. Similarly, autonomous work titles are updated with the MR title, if the user hasn’t already updated it.

Link autonomous work with related issue

Create a parent-child link b/w the work-items mentioned in the MR body and the autonomous issues tagged with the branch/MR. When a new GitLab MR is opened/edited, for all the autonomous tagged work items(by branch/MR), automatically make the issues mentioned in the MR as parents.

Automatically close autonomous work

Autonomous work gets closed when its related MR is merged. However, if there is no MR activity on this work, then the autonomous work is closed after configurable period.

Frequently asked questions

What is an autonomous issue?Autonomous issue is an issue created automatically from an external event, such as a new GitLab branch or MR. These issues have the tag autonomous.
How does an issue change status?
New branchAny but not closed statusIn development
Commit pushedNo change
MR openedAny but not closed statusIn review
MR closedIn reviewIn development
MR reopenedAny but not closed statusIn review
*MR merged (without /close)In reviewIn development
MR merged (with /close)Any but not closed statusResolved
*This change happens only when change_stage_to_in_development_on_pr_close is true
What are the autonomous work configuration options?
create_work_item_on_new_branchEnabled or disabledCreates autonomous work items on a new branch when no work-id is mentioned
create_work_item_on_pr_openEnabled or disabledCreates autonomous work items on a new MR, when no work-id is mentioned
mention_work_directly_in_pr_bodyEnabled or disabledLink work-id to an MR, when its found in MR body
enable_magic_commandsEnabled or disabledUse magic commands /close and /toward in your MR
close_autonomous_work_on_mergeEnabled or disabledClose the autonomous work when the MR is merged
default_partpart display idAutonomous work is created under this default part
update_autonomous_work_from_prEnabled or disabledEnrich autonomous work item title and description with MR data
link_autonomous_issues_with_mr_mentionEnabled or disabledLink the work item mentioned in MR to the autonomous work created
change_stage_to_in_development_on_pr_closeEnabled or disabledAutonomous work changes stage to `in_development` when an MR is closed
How can autonomous work creation be disabled?You can disable the parameters create_work_item_on_new_branch and create_work_item_on_new_MR to not autocreate issues. If you choose to turn this off as an exception, you can choose to begin your branch name or MR title with nw-(e.g, nw-new-branch)
How can you attribute a part to an autonomous issue?This automation will infer the part from a repository, if possible. If not, the issue is created with a specified default part.
When is the automous issue closed?The autonomous work item is automatically closed when its source MR or an MR on its source branch is merged.