Here at DIT we’ve used Bugzilla as our issue tracking system for nearly a decade. We’ve got a solid workflow but it has largely been absent of integration with our version control system which has gone from CVS to SVN to Git. Now that we have most of our active projects in GitHub, we’ve noticed there is some overlap in workflow. GitHub has some really great features that makes it more fun to use as a developer, with pull requests topping the list. The problem we ran into is that we still want to use Bugzilla as our issue tracking system so that we can leverage our historical bugs, bug reporting code and workflow (including tracking hours). So we ended up with a confusing back and forth between Bugzilla and GitHub, losing a lot of time to double-entry.
Enter bugzilla-github-extension, a Chrome extension that provides integration between Bugzilla and GitHub by modifying the UI. With this extension, we’ve been able to cut down on the amount of time we spend jumping back and forth between the two systems. We’ve open-sourced the code in hopes it can help out others in the same boat as us, so if that sounds like you then head on over to the source or go right ahead and install via the Chrome Web Store!
Once installed, you have to configure the extension so that it knows what your Bugzilla and GitHub pages are. To do this, simply right-click the plugin icon () and choose Options. You’ll see this:
All you need to enter is the Bugzilla URL and the GitHub URL, and you’ll be able to start using the extension!
The Bugzilla Custom Fields section lists some custom fields we’ve found useful at DIT that have made the integration even tighter:
A number of things happen when a pull request is linked to a bug, which is done by prefixing a pull request’s title with the bug number (ex: 83513, , Bug 83513, Bug83513). First, the bug number becomes a link to the bug in Bugzilla:
You can also choose to sync the bug’s summary field when editing the pull request title:
Second, the extension will place a section in the sidebar for a pull request linked to a bug that displays bug fields you can specify in the options page. It also will list any (non-obsolete) attachments as links.
Third, comments will have options to post the comment in Bugzilla or to change the status of the bug. There’s even a new input to record your time! Line comments don’t let you record time, but they do report the file and line number if you send the comment to Bugzilla.
Finally, you’ll also be able to update the bug’s status and code status when merging:
As an added convenience, if your branch is named with the bug number (ex: bug-12345, bug12345, bug_12345), then when you are creating the pull request the title will be set to the bug number plus the summary of the bug automatically. You’ll also have the option to associate the pull request with the bug via the GitHub Pull Request URL custom field:
You can also associate a GitHub repository to a product in Bugzilla. When you do this, you’ll get some convenient buttons that will open up bug lists in Bugzilla configured with fields specified in the options page. At the top of the page, you get Unresolved and Resolved buttons, and when looking at milestones you get a button for each milestone:
For the View in Bugzilla buttons to work for the milestones, the name of the milestone in GitHub needs to match the target milestone in Bugzilla. The extension provides a nice way for you to ensure the correct names when creating or editing a milestone:
To make sure everyone at DIT is correctly configured, we added an import/export feature for the configuration options. We set up everything in one install then exported the options as a JSON file that new employees can import when they install in their browser. Some settings, like what to see in the sidebar and what fields to show in Bugzilla lists, can still be personalized per install.