Feature Request: tracking smart commits in open source repositories

[ACyphus]

The ability to track Jira issue keys and smart commits in open source repositories that you do not have direct access to.

This would allow people to create a pull request from a fork into the parent repository with a Jira issue key in the title and have the pull request show in their Jira issue.

If this is something you'd also like, react with a thumbs up.

[Piedone]

The use case is that we use JIRA for our internal issue tracking, but sometimes a JIRA issue also needs work in an (open source) GitHub repository that we don't own (e.g. we stumbled upon a bug in a library while working on a task for a customer project, and we're contributing a fix). We'd like PRs opened for contributions like this be tracked under the same JIRA issue still.

[jnraine]

Potential solutions

• Periodic sync. Using integration UI, allow user to "watch" public repository. Once per hour, pull latest commits.
• Subscribe to webhooks. User integration UI, allow users to subscribe to public repository webhooks. This would "just work" with the existing integration but, at the moment, a GitHub App can't subscribe to webhooks outside of the org/user where it is installed.

Considerations

• If hundreds of people watch same repo, can we sync once and cache the results?

[rachellerathbone]

Hi @jnraine. I'm from a team at Atlassian that is currently in the process of migrating the ownership over to us from GitHub. As a part of this, we're currently going through the backlog of issues and prs to see what can still be addressed and what should be closed.

I've flagged this with the 'to-triage' label so my team can discuss. We'll keep you posted on the status of this.

[mboudreau]

@ACyphus At its surface, this is not possible with Github for Jira - our system is simply not made to handle this (we could, but I would argue that it's low value) and there's also some very scary security ramifications with doing so.

For example, if you were to get G4J to watch an open source repo for your incoming PR that includes an issue key (say TEST-123) in the title, it's now being linked to your Jira project. Everything's good. But what happens if the OS repo you're watching has the same project id (TEST)? You'll get a lot of bad information in your Jira project from a different repo that isn't your organizations. Then there's those that want to cause your headaches, since they now know your project id (TEST) since it was part of the title, they could just absolutely spam commits, branches, PRs, and issues in this repo which would link all this fake information to your jira issues. It gets even worse if they use smart commits to transition active issue keys to done without your consent.

The only way I can think of doing this appropriately right now, without extra work on our part, would be to create a fork of the OS repo into your organization, then make the changes in said repo with the issue key, then create a PR to the upstream repo. However, at this point, anything that happens in the PR, since it's now in the original repo, cannot be tracked.

This might be an idea for Jira itself so you can add a link to a github PR url and it would track it automatically as we can't do this functionality just from a Jira app. but then, even if it's merged doesn't mean it's been released, so how would you track that in an OS repo?

I hope that answers your question. I'll close this for now as we need to look closer to this, but it's not that high of a value proposition for the amount of work. As such, this will not be a priority for quite a while (if ever). In the end, you just have to track it yourself.