We have been facing similar issue like Aaron jensen faced. As a part of decomm of Jira server (EOL of server license), we migrate one project from Jira server to Jira data center with new project key but there was old project key ref were there in commit in user's Bitbucket repo so after migration, it breaks Jira link if user try to click on it

Thank you to give priority to add this feature in Bitbucket

Another use case: we just migrated our Jira instance to another instance. The old Jira and new Jira both had a project with the same key. When our project was migrated, it got a new key. We now have a repository full of commits with the old key that link to tickets in the new Jira that are completely unrelated. This actually happened with three of our Jira projects, so now we've got commits scattered across many of our repositories that contain links to unrelated tickets.

+1

I think that git notes provide an ideal backend for this.

I agree.  We have been using Git Notes to store metadata like this for a couple years now, and have begun storing Jira issue keys in Git Notes as well.  While we've got some custom reporting tools around this data, it would be much cleaner if Bitbucket's own Jira integration would leverage this data.  Another advantage of Git Notes is that their history is also captured in Git, should you want to see what the notes value was before, and who changed it and when.

Under development, the Jira issue can contain a link to branches. It would be great if a link to commits can be manually added. 
The commit message would do this automatically, but with a commit edit field you could add multiple commits to a Jira issue, and remove them. This should then be reflected on the Bitbucket side. 

Just ran into the problem of an incorrect key put in a commit message from several months back, with no safe way to rebase and rewrite the message.

Really, the commit message shouldn't be the single source of truth for related Jira issues. The process should be:

1. Commit is pushed to Bitbucket
2. Bitbucket scans commit message and collects Jira issue keys
3. Bitbucket checks keys for validity (BSERV-2470) and adds them to a table if valid, including from multiple instances (BSERV-10537)
4. Triggers to Jira and related systems are fired as necessary for each new issue added to that list

Users with Repo Admin/Write permissions can then add or remove Jira issues manually (and via APIs). This would also fix the problem of multiple Jira instances as users could remove the links that aren't relevant.

+1

I recently migrated the version history of a project from a non-Git system to JIRA and Bitbucket Server. The old commit messages referred to issues in the old bug tracker but JIRA assigned its own issue keys. To make JIRA display the Git commits that relate to each issue, I ended up appending the JIRA issue keys to the commit messages after I converted the history to Git. However, some of the old commit messages refer to issues in another project that has not been converted yet, so I don't know what their JIRA issue keys will be. When that project is eventually converted, I will not be able to add link the Git commits to the resulting JIRA issues without rewriting history, which cannot be done with only git filter-branch because we now have pull requests, comments, and build statuses in Bitbucket Server.

kostmo wrote:

I think that git notes provide an ideal backend for this.

 git notes would be easier to script than a new REST API.

If a Git commit message refers to the wrong JIRA issue EXAMPLE-123 and I want Bitbucket Server and JIRA to disregard that reference, the git-notes blob could perhaps say "EXAMPLE-123 #unrelated" or "EXAMPLE-123 #ignore", using a keyword syntax like in smart commits.

We have linked wrong Jira issue Id to another Jira Item but after committing unable to edit the bug id. I think better to have an option to edit the link after committing.

We have a hook that tries to prevent people from pushing commits unless a properly vetted Jira issue is referenced in the commit message. One of the problems we've run into is that when we query BitBucket to see the issues related to a particular commit, it will report all issueids found in the branch name as well as in the commit message itself. So if the developer has a typo in the Jira issue mentioned in the commit message, the commit is still accepted as long as the branch contains the correct Jira issue id. This would be all well and good except that the branch gets removed after it's merged, so the association with the correct issue ID is lost at that point. All you're left with is the commit with the bad issue ID. (And no way to change it, which is why I'm commenting on this issue).

The ability to edit the JIRA bug id after a commit is required.

Especially when you link accidentally a VALID JIRA bug id.

All the pre flight hooks won't do you any good if you have a false positive in your check.

Commit Policy Plugin is Bitbucket add-on that allows implementing checks on the commit message (length, format, regex), the committer's identity (username, email, group membership), the mentioned issues (count, matching a JQL), the modified files (regex), etc. Learn more about the conditions and about commonly used policies:

In the background it implements a new hook type in Bitbucket (see the demo) which connects to JIRA via a secure application link and checks the compatibility of the commint against pre-configured policies.
It is available both for Bitbucket Server 4.x and for Stash 3.x, plus other Version Control Systems (Git, Mercurial, Subversion).

I ran into this today, and was very surprised to find this gap. Seems fundamental to me to able to track commits associated with a Jira issue and so the ability to add/remove jira issue <-> commits is required.

We recently ran into this where a mistyped issue ID closed a ticket without us realizing it. Our solution that we're testing now is to not allow Stash to transition tickets out of To Do, only once a ticket has been placed In Progress can Stash transition it. That way it's less likely that we move a ticket to Done without someone (hopefully the assignee of the open ticket) noticing but we still get most of the benefit of automatic transitions between Stash and Jira.

Yes this would be very good to get this feature, because what if people don't create the branch through JIRA, then there is no way to correct this?

Atlassian - any updates on this? This is a huge issue that needs to be addressed.

Linking an issue to a commit should be just as easy as linking an issue to another issue. You should tell it to add a link, paste in the commit ID, and that should be it. Or a "+" button in the list of issues. Or both.

The core problem is that rewriting git history is verboten, so we have two systems, neither of which is capable of being edited after the fact to reflect the state of the other. That's a pretty serious impedance mismatch, so in my mind, this isn't a feature request; it is a serious bug that causes problems on an ongoing basis.

And preventing pushes without valid issues in the commit message doesn't fix it, either. That's entirely the wrong approach, for several reasons. First, not all commits are necessarily associated with a ticket, particularly for tiny fixes. Second, just because a commit contains an issue ID does not mean that it is the correct issue ID, nor does it mean that the commit does not impact other issues besides that one. (Yes, in an ideal world, each commit should be associated with a single ticket, but reality often does not reflect this ideal.)

It is vitally important for a proper issue tracking system to be able to accurately reflect the commits associated with a ticket, because that's the only good way to determine whether to move an issue to QA testing when we roll out a build. If there's no way to edit that association, then the integration between those tools is broken by design, and needs to be fixed. Please fix this.

My team is migrating to Stash soon. Currently we use Jira 3, which will not be linked with Stash, but in the future we will migrate to the latest version of Jira. I'm writing a script to post a log message to issues in Jira when it is mentioned in a commit message. This is how our current system works. I want to support scanning git-notes for issue numbers as well so that we can retroactively link commits and issues. I'm hoping to do this in a forward compatible way, so that when we do migrate to the latest Jira, issue linkage will work with issues mentioned in the notes as well.

So my question is this: if we create an inventory of notes containing issue numbers, can we use that as linkage information in the future?

I'm aware of the challenges of using git-notes for this, but I believe that they can be solved.

Thanks rudyholtkamp+atlassian, thats a great plugin!

Hey Philip, you should definitely take a look at the YACC plugin (https://marketplace.atlassian.com/plugins/com.isroot.stash.plugin.yacc)
It will prevent developers for pushing code without (valid) issue keys in their commit message.

Rudy

This would be great if a dev missed it to write the issue key in the commit message.

I think that git notes provide an ideal backend for this.

Ideally, it should be possible in Stash to select from a list of issues to connect the current commit to (on the commits overview page).