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.
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.