| Issue 124: | Integration with bug/issue tracking systems | |
| 21 people starred this issue and may be notified of changes. | Back to list |
Reported by Christopher Tate <ctate@google.com> on Mon Apr 06 19:05:14 PDT 2009 Source: JIRA GERRIT-124 The internal-to-Google "Mondrian" workflow that the Android project is transitioning from has some areas of tight integration between revision control and issue tracking that are hugely useful, but which are currently absent in the repo+Gerrit workflow. Here are explanations of a few specific aspects of the Google workflow that would be most useful to have: When a change is uploaded to Mondrian, the developer can specify a "-b bugnum [,bugnum2,bugnum3,...]" flag on the command line. If this flag is omitted, the upload script prompts for it [but accepts an empty string as input]. This flag tells Mondrian what issue numbers in the bug tracker are addressed by this submission. Later, when the change is formally submitted, Mondrian injects the change description + filelist directly into the issue tracker automatically, as comments on each of the indicated bugs. The Mondrian web UI also includes these bug numbers when displaying a review/ patch, with the numbers showing as links to the issue tracker's pages for the corresponding bugs. This is INCREDIBLY useful to reviewers, who can then easily inspect the bugs and their commentary when reviewing the patch itself. Another Mondrian workflow flag currently missing in repo+Gerrit is an equivalent to the "-x" flag passed when a patch is actually submitted to the main depot. This flag means "don't just append the change description to the associated bugs, but also go ahead and mark the bugs as "Fixed" in the issue tracker." This one is useful but probably not as relevant in the Gerrit workflow, since often the developer who knows whether the fix is "complete" will not be the person actually hitting 'Submit' in the Gerrit UI. "-b" is the major currently-missing feature as far as issue tracking + repo/ Gerrit integration.
Sep 24, 2009
Comment by Shawn Pearce <sop@google.com> on Tue Apr 07 11:12:03 PDT 2009 I already use something of a common standard for noting bugs in commits with Gerrit; e.g. see http://android.git.kernel.org/?p=tools/gerrit.git;a=commit;h=759dfc4db0f28c87f2ac12c62b4c370a52610a6a This fits with the Git standard of having notation lines on the footer of the message: Signed-off-by: J. Q. Public <jqp@example.com> Acked-by: J. Doe <jdoe@example.com> Tested-by: That Other Guy <tog@example.com> CC: Important Customer <ic@example.com> We could just adopt the "Bug: nnnnn\n" standard now, and add tooling to enforce and link to it as we go.
Sep 24, 2009
Comment by Brad Larson <bklarson@gmail.com> on Wed Sep 02 09:15:29 PDT 2009 We are formatting commit messages assuming Bug: nnn is the standard. How should we tag a commit which addresses multiple bugs? Bug: nnn, mmm or separate lines? Also, some developers are curious about Jiras which are tasks or feature improvements and not bugs. They think tagging with Bug: isn't ideal, and are curious about tagging with Jira: instead. Do you have any thoughts?
Sep 24, 2009
Comment by Shawn Pearce <sop@google.com> on Wed Sep 02 09:20:26 PDT 2009 I would think both "Bug: a, b, c" and "Bug: a\nBug: b\nBug: c\n" is acceptable. Its a matter of formatting, if you have too long of a bug identifier to fit multiple on one line, it might be useful to use multiple lines, on the other hand putting multiple bugs on a single line is rather concise, especially if the bug string can't contain the pattern ", +". I'm not happy with "Jira:" because its too specific to a product. Its looking more and more like the AOSP will use http://b.android.com/ rather than JIRA for its issue tracker. As for tagging non-bugs, maybe "Issue:" or "Feature:" ?
Sep 24, 2009
Comment by Brad Larson <bklarson@gmail.com> on Wed Sep 02 09:38:30 PDT 2009 Being too specific about a product is a good point. It sounds like my team will be happy if we can support Issue: as well as Bug: as the commit tag. Feature: isn't a bad idea either, but I'm not sure where to draw the line. Our Jira install supports Task, Bug, Improvement, Inquiry, and Feature, and a Jira admin can add more issue types. For now, I'll tell people to stick with Bug: or Issue:
Sep 24, 2009
(No comment was entered for this change.)
Status:
Accepted
Owner: ---
Sep 24, 2009
(No comment was entered for this change.)
Cc:
ct...@google.com
Sep 26, 2009
(No comment was entered for this change.)
Owner:
lscarval
Jan 27, 2010
Has there been any progress on this issue? We're really looking forward to using Gerrit at our workplace but the biggest issue for management is being able to generate metrics and we can't do that without some association between changes and issues. If there hasn't been any work on this yet could someone point me in the right direction? I was thinking a change to the changes table (using mysql for the db) to contain an issueid or bugid field would make the link. I'm just not sure where in the code this belongs. Maybe in com.google.gerrit.server.git.ReceiveCommits? Any help or information would be appreciated.
Jan 27, 2010
Nope. The last work done was to close issue 19 with the commentlink configuration settings. But there has been no effort to teach Gerrit how to notify an external issue tracker about changes. Though... with the recent hook changes[1] you could do your own hook to scrape the commit message and send the data to the issue tracker. But its strictly after-the-fact so you can't use it to verify the author of the change has actually inserted a valid issue tracking id. I think it depends on what your goals are as to how you might go about working on this. If all you want is to push back to the issue tracker when possible, the hook support from [1] that will be in Gerrit 2.1.2 might be sufficient. On the other hand, if you want to verify the author did the right thing, and abort their upload if they didn't, you need to modify ReceiveCommits.java. I'm not sure that adding a new column to the changes table is quite the best approach to store the issue id number, what happens when a single commit addresses multiple issues at once? It might make more sense to add an entire new database table, and new object entity, that represents the external issue tracker links. [1] http://android.git.kernel.org/? p=tools/gerrit.git;a=commit;h=6c2b677980416b554073da1e87f0a56d2dc42f57
Owner:
---
Jan 27, 2010
We use some changes to mantis along with the hook support to have this, example: http://bugs.dmdirc.com/view.php?id=3635 (This also shows our integration with cgit as well)
Apr 21, 2010
I'd like to take on this issue, making it generic by implementing support for
configurable footer lines. In combination with the commentlink functionality this
would also support using different bug tracking systems for different projects.
The first part is to add support for a new section in the gerrit.config file and
populate a new DB table with tracking-ids matching the configuration when a new patch
is received. The table will connect the change-id with the tracking.x.system and the
tracking-id(s) parsed out by the tracking.x.match regex:
[tracking "jira-b"]
footer = JIRA-Bugfix:
match = \\d+
system = JIRA
[tracking "jira-f"]
footer = JIRA-Feature:
match = \\d+
system = JIRA
[tracking "my-tracking-sys"]
footer = MY-Bug:
match = Bug\\d{8}
system = MYBUG
This could be combined with commentlink sections to create links to the corresponding
tracking system, like:
[commentlink "jira"]
match = JIRA-(Bug|Feature):\\s*(\\d+)
html = $1: <a href=\"http://jira/?issue=$2\">$2</a>
The second part is to implement support for searching for tracking-id, using the
generic search input with eg. "issue:nnnn".
Apr 21, 2010
To goeran.l...@sonyericsson.com, if you're interested I can supply you with what I ended up doing for this problem. It's not the most elegant solution but it does allow someone to correlate an issue id with a change id. Some of the drawbacks of my solution: - Written in Python - No links displayed in the GUI - Currently Only works with MySQL (for Gerrit) and Bugzilla (via RedHat's bugzilla package) Benefits: - Uses the gerrit config - Uses a new 2 column table to associate change ids and issues ids - Uses comment footer to get issue ids - It works (for me :) ) If nothing else it might be a good starting point because it was designed as a framework for creating hooks and not as core feature of Gerrit.
Apr 21, 2010
(No comment was entered for this change.)
Owner:
goeran.l...@sonyericsson.com
Cc: -ctate+le...@google.com
May 17, 2010
Implemented in change I3ddada57240040f27329f5f26f1f8e99e94f1469
Status:
Started
Jun 15, 2010
Fixed by I3ddada57240040f27329f5f26f1f8e99e94f1469
Status:
Fixed
Labels: FixedIn-2.1.3
Dec 13, 2010
Would love to have some gerrit and Bugzilla integration.
Dec 17, 2010
I am also very interested in interfacing bugzilla and gerrit. Does such an integration already exist? Thanks a lot
Aug 10, 2011
It would be really good if we have integration with Gerrit with trac / bugzilla... This is what most of the organization and educational institutions expects. Thanks Kannan K
Mar 27, 2012
(No comment was entered for this change.)
Status:
Released
|
|
| ► Sign in to add a comment |
Comment by Andrew D. Stadler (Google) <stadler@android.com> on Mon Apr 06 19:15:41 PDT 2009 Even before adding the complexity of integrating with { buganizer, jira, buzilla, etc. } here's a big +1 for simply adding the tracking of bug id's with uploaded changes, and displaying those bug numbers with the change. The sooner we are able to associated bug #'s with changes, the less data we'll lose. Clever integration can come next. Regarding the importance of this feature in general, here are some things that are enabled once you have bug # tracking. - "click here to see the bug" in code review presentations - triggers & filters based on bug status (e.g. triaged or assigned to specific releases) - writing the change as a comment on the bug enables the bug tracker to then notify watchers of the change