Link to GitLab deployments from Jira issues mentioned in commits since last deploy

Release notes

Click to read release notes

From applications that integrate with Jira, Jira requires that all entities are associated with one or more Jira issue keys, otherwise the information is rejected and not stored on the Jira side.

To link deployments, we currently look for associated Merge Requests to link deployments through them. This considers branch names, description and title.

This is inconvenient for many users as it enforces that users do their deployments from a merge request, which is not the typical flow.

In this issue we will associate deployments with Jira issue keys in ways that are convenient for users.

Problem

In !49757 (merged) we implemented a mechanism to send deployment information to Jira using the Jira Connect application infrastructure (see: #27986 (closed)).

Jira requires that all entities are associated with one or more Jira issue keys (if not, the information is rejected and not stored). For deployments, we currently look for associated Merge Requests, and use the existing mechanism for linking them (this considers branch names, description and title).

This is inconvenient for many users, and understandably so, as it enforces that users do their deployments from a merge request, which is not the typical flow.

Instead, we should find ways to associate deployments with Jira issue keys in ways that are convenient for users.

Personas

This affects Parker (Product Manager) and Sasha (Software Developer).

Click to read original proposals

Proposal

The most logical places to configure this information is either in Build that runs the deployment or in the Environment that the deployment is associated with, or in git in the commit messages.

In the Build

We could add arbitrary tags to builds, or inspect the build names to find issue references.

The downsides of this is that this would place Jira issue references in the CI yaml, which seems like a confusion of responsibilities

In commit messages

We could read the commit message of the HEAD ref for the build. This would not require building any extra tooling, but depending on how many commits we read, this could get slow. If we deploy the same commit to multiple environments, it could confusingly associate them both with the same issue reference.

In the Environment

We could add a description to the Environment, and use that to scan for issue references. This has the advantage of mapping most closely to how users think about their deployments (typically the identity is the environment, and the state is the ref).

This would involve changes to our models and view to accommodate.

In merged MRs

This is similar to the implemented behaviour where we look for issue references in an MR's title and branch name, but would also work for pipelines triggered by a merge commit after merging an MR. We can use the pipeline's sha to look up MRs with a matching merged_commit_sha.

This would address the problem described in #328200 (closed).

Proposal

As outlined in #300031 (comment 649257271):

We will extract Jira issue keys from all the commits (up to a certain limit) that will be deployed to the environment since the last deployment to that environment.

When a deployment occurs in Gitlab, we already have the information about its related commit. Gitlab could do something like git log --oneline ${SHA_LAST_DEPLOYMENT_ON_THAT_ENV}..HEAD to list all the commits that will be deployed on that env since last time.

UPDATE:

Scan commit messages for Jira keys when syncing... (!112898 - merged) introduced the ability for deployments to be associated by mentioning Jira issue keys in a pipeline's commit message.

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.