JIRA Development Panel Integration

It would be awesome to have the Development Panel integration with JIRA. It really helps us tie commits to stories and makes it super helpful when referencing actual work with an issue.

The Development panel is a panel that can activated on the Issue view in Jira which provides the following functionalities:

• Bitbucket Cloud and Bitbucket Server: view and create branches, view commits, and view and create pull requests
• GitHub and GitHub Enterprise: view commits, branches and pull requests

When the Atlassian development tools are integrated with JIRA Software, a user simply needs to supply an issue key for the issue to be automatically linked:

• Commits are linked automatically if the issue key is included in the commit message.
• Branches are linked automatically if the issue key is included in the branch name.
• Pull requests are linked automatically if the issue key is included in the pull request's title or in the source branch name.
• Reviews are linked automatically if the issue key is included in the title of the review, or if the issue is linked from the review.
• Builds and deployments are linked automatically if a commit involved in the build has the issue key in its commit message.

Specification

• We need to be integrated with JIRA in the same way: view commits, branches and pull requests, all from GitLab, linked to an issue in JIRA

Added gitlab-ce~14213 label

Added gitlab-ce~26362 label

Have you guys seen this: https://github.com/dka23/gitlab-github-proxy.

I packaged it up for my purposes here: https://gitlab.com/harbottle/glghproxy-packager and have it working successfully with GitLab EE on-site. My GitLab commits now show up in the "Development" section of JIRA tickets! Anyway the point of mentioning this is is that one approach would be to implement a "GitHub Enterprise API translation layer" within GitLab. This will instantly allow GitLab to integrate with any applications that can integrate with GitHub (not just JIRA).

This seems to be working great!

Would be awesome if Gitlab could still support this on Enterprise

Thanks for the heads up Richard!

Another option would be to add support for Gitlab in the Jira DVCS connector itself. Seems to be Open Source: https://bitbucket.org/atlassian/jira-dvcs-connector/overview

@clement.moyroud Atlassian have already declined a pull request for this feature so I don't think that is going to work.

@harbottle right, I hadn't seen that. Well it's apparently not totally out of the question, as long as a tedious piece of work is done to change it I do agree with you that it'd be awesome if Gitlab had a GH translation layer available - I saw that your request to get it integrated into the Omnibus package got rejected. I wonder how complicated it'd be to rewrite this in Go or Ruby - the main part is figuring out how many GH API calls need to be translated.

See also the interesting comments in pull request 102 that originally drove Daniel Kleine-Albers to create the proxy application. One could suggest that Atlassian's refusal to add seamless integration between JIRA and GitLab is driven more by commercial considerations rather than technical ones. Not that I would ever suggest this myself...

Regardless, the ability to emulate GitHub Enterprise APIs will open up a world of integrations for GitLab, that may otherwise remain closed (JIRA being only one example). I do think that a standalone service (proxied via integrated nginx using an additional domain name. similar to the integrated docker registry and mattermost) and bundled in Omnibus is a good way to go. In that way the primary GitLab API can remain clean and the translation layer can remain an optional service that can be enabled in gitlab.rb by those who want it.

If you wanted to get really clever, you could conceive of a modular API translation layer that allowed other APIs to be translated in future (Bitbucket? Phabricator?)

Thanks for the discussion here.

I've created https://gitlab.com/gitlab-org/gitlab-ee/issues/1038 to discuss more about the initial issue, which was to be integrated with JIRA Development panel.

@ben.gabler I've updated the body of this issue to provide more explanation.

From @dblessing here , apparently,

It looks like Atlassian may need to add GitLab integration on their side. I don't see any mention of APIs we can use to integrate ourselves.

So we have to find out if we can make this happen with them.

@regisF Given Atlassian apparent lack of interest for now, I can see two things happening:

1. Gitlab takes over the world, they have to integrate as they did GitHub, to keep their market share :)
2. We create a proxy similar to what @harbottle has packaged. I proposed Ruby or Go as this is what Gitlab devs use. I write Go code myself, so I could be of help.

Let's be realistic, I think gitlab-ce#2 can happen before gitlab-ce#1

My .02,

Clément

Mentioned in issue harbottle/glghproxy-packager#1

Added gitlab-ce~874211 label

We are big users of JIRA at my company, and some way to integrate into the Development Tools features of JIRA would be a godsend.

@bullhorn_engineering thanks for your feedback. What exactly would like to see in the Development Tools?

As close to parity as to GitHub as possible. Viewing commits, branches, and MRs (with linking back to Gitlab) based on the the JIRA ticket being in the commit message.

Basically, the existing integration that adds comments can cause non-commit/MR comments to get lost in the noise. We often have multiple projects that are affected by development stories, and making sure they can be tracked in JIRA cleanly would allow us to not have to build/maintain some JIRA integrations we have that try and reduce comment noise, nor deal with "webhook hell" where we need to wire up dozens of projects to connect to JIRA.

Given that JIRA's BitBucket integration allows the creation of branches and merge requests, it'd be better to have a BitBucket/Gitlab proxy.

On the other hand, GitHub has a lot more integrations, so a GH/GL proxy would open Gitlab to more integrations "for free".

@smcgivern : here's the development panel issue for JIRA. What's the effort involved to do something like this? Smallest slice would be one of the items mentioned in the description:

Pull requests are linked automatically if the issue key is included in the pull request's title or in the source branch name.

changed milestone to %Backlog

@victorwu I think the comments in this thread are all pretty much still accurate, especially those from @harbottle and @clement.moyroud.

For us to be able to add this to JIRA itself (so that you configure GitLab 'as GitLab') seems like it's unlikely based on https://bitbucket.org/atlassian/jira-dvcs-connector/pull-requests/102/initial-gitlab-support-for-jira-65x-master/diff#comment-9865814 and below, although it might be worth checking again.

Also relevant: https://jira.atlassian.com/browse/JSWSERVER-14412

---

Assuming that's not possible, https://github.com/dka23/gitlab-github-proxy is very interesting. The main reason it seems to need to be a proxy is that we have URL clashes with GitHub in the API namespace. Ideally, if we were to build this, it wouldn't be its own service, because then we'd have to maintain changes to the API in two places at once, but that might not be feasible (for instance, the OAuth dance that the proxy does, or maybe there is no way of distinguishing JIRA API requests from normal requests to the v3 API - although once we remove the v3 API entirely, we could have that dedicated to this).

One interesting thing that I noticed: JIRA seems to let this work on a relative URL. So if we implemented this compatibility layer at /jira/, say, then we could ask people to enter their host URL as https://gitlabinstance/jira, and implement the OAuth and API level parts there.

So if we implemented this compatibility layer at /jira/, say, then we could ask people to enter their host URL as https://gitlabinstance/jira

I'd advocate implementing the compatibility layer at /github/. What you're doing is creating a GitHub API compatibility layer for GitLab that can be used by JIRA...but that could also be used be other GitHub API clients...

@harbottle thanks, that's a good point. Although the reason I picked jira was that this isn't just API compatibility: it's API compatibility for things that JIRA uses. This wouldn't exist for other APIs, necessarily.

Anyway, this is just a speculative suggestion for now, we can make a better decision if / when implementation starts.

mentioned in issue #2381 (closed)

First iteration of the development panel can be simple commits: https://gitlab.com/gitlab-org/gitlab-ee/issues/2381

requested by large prospect: https://na34.salesforce.com/0066100000F1KFT

changed milestone to %Next 2-3 months

added EE Starter label

added ~333913 and removed EE Starter labels

changed milestone to %10.0