My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 124: Integration with bug/issue tracking systems
21 people starred this issue and may be notified of changes. Back to list
Status:  Released
Owner:  goran.lu...@gmail.com
Closed:  Mar 2012

Blocking:
issue 19


Sign in to add a comment
 
Reported by code-rev...@gtempaccount.com, Sep 24, 2009
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
#1 code-rev...@gtempaccount.com
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
Sep 24, 2009
#2 code-rev...@gtempaccount.com
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
#3 code-rev...@gtempaccount.com
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
#4 code-rev...@gtempaccount.com
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
#5 code-rev...@gtempaccount.com
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
#6 sop+code@google.com
(No comment was entered for this change.)
Status: Accepted
Owner: ---
Sep 24, 2009
#7 sop+code@google.com
(No comment was entered for this change.)
Cc: ct...@google.com
Sep 26, 2009
#8 sop+code@google.com
(No comment was entered for this change.)
Owner: lscarval
Jan 27, 2010
#9 jeffreys...@gmail.com
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
#10 sop@google.com
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
Project Member #11 Shane...@gmail.com
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
Project Member #12 goran.lu...@gmail.com
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
#13 jeffreys...@gmail.com
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
#14 sop@google.com
(No comment was entered for this change.)
Owner: goeran.l...@sonyericsson.com
Cc: -ctate+le...@google.com
May 17, 2010
Project Member #15 goran.lu...@gmail.com
Implemented in change I3ddada57240040f27329f5f26f1f8e99e94f1469
Status: Started
Jun 15, 2010
#16 sop@google.com
Fixed by I3ddada57240040f27329f5f26f1f8e99e94f1469
Status: Fixed
Labels: FixedIn-2.1.3
Dec 13, 2010
#17 arunc...@gmail.com
Would love to have some gerrit and Bugzilla integration.
Dec 17, 2010
#18 DamienVa...@gmail.com
I am also very interested in interfacing bugzilla and gerrit.
Does such an integration already exist?
Thanks a lot
Aug 10, 2011
#19 kannan.k...@gmail.com
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
#20 sop@google.com
(No comment was entered for this change.)
Status: Released
Sign in to add a comment

Powered by Google Project Hosting