Make the process of associating a Jira issue with a merge request more clear and reliable

Background

Enterprise organizations leverage change management policies and change control systems, such as Jira, to manage the changes they make to company systems and resources. This workflow provides visibility into who made a change, why, when, and what systems or resources it affected. It provides an audit trail of changes and can help isolate problematic changes or prevent non-compliant changes from making it into production systems.

Currently, users can add the associated relationship to the Title, Description, or Comment of a Merge Request by entering a ticket reference (e.g. TEST-2)

Within a Title As a mention
image image

Then using some complicated logic to crawl a Merge Request for this relationship it can be shown in other tools, like Jira.

image

Problem to solve

Currently, integrating Jira with a GitLab project allows you to associate MRs with Jira issues by typing the Jira ticket ID into the MR title or description. This process is unintuitive, unreliable, and makes external tooling more expensive to build and maintain because there is no single, predictable experience for this association. There is no way for Sidney (Systems Administrator) or Cameron (Compliance Manager) to reliably know a Jira issue will be associated with an MR.

Sasha (Software Developer) may be unaware of the current, unobvious methods to associate Merge Requests to a Jira issue.

Intended users

User experience goal

A developer should have a standard, intuitive way to add a Jira ticket ID to a MR that does not require regex or other custom tooling to determine if the relationship exists.

Proposal

Implement the following, in order:

1. Add QOL improvements to the MR to show the Jira issue is missing
Merge_request____issue_association_not_found
2. Add a button to add Jira issue to title or description
Merge_request____issue_association_not_found
3. Add a project-level toggle to require this linkage (to block an MR if it doesn't exist)
__Merge_checks_requirement
4. (probably) Add a dedicated field for entering the Jira issue ID
Dedicated_issue_dropdown
5. (maybe) Implement an auto-populating experience of some sort
Autofill

Further details

Organizations want to encourage a behavior change by making this process easier, more intuitive, and eventually enforceable. Additionally, because of how the association data is manifested today it is difficult to verify and map relationships across platforms.

The vision is to extend the auditing capability of Merge Requests to answer the question: does every merge request associate to a change ticket?

We will need to add additional capabilities to make this a great compliance experience. Some ideas:

  1. Future iteration: Extend this field to include other issues, e.g. GitLab, ServiceNow, etc
  2. Future Iteration: Accept the Jira ticket ID from a user and perform validation against the Jira instance to confirm the ticket exists
  3. Future Iteration: Allow group owners to require this field be completed before MR can be merged only for regulated projects (have a compliance framework label)
  4. Future Iteration: Make this field and value available via Merge Request API
  5. Future Iteration: Provide auto-complete capabilities to search for Jira tickets as a user types the Jira ticket ID
Edited by Austin Regnery