Question

I use cruisecontrol.rb for CI and FogBugz for bug tracking, but the more general the answers, the better.

First is the technical problem: is there an API for FogBugz? Are there good tutorials, or better yet, pre-written code?

Second is the procedural problem: what, exactly, should the CI put in the bug tracker when the build breaks? Perhaps:

Title: "#{last committer} broke the build!"

Body: "#{ error traces }"

I suppose this presupposes the answer to this question: should I even put CI breaks into my bug tracking?

Was it helpful?

Solution

All the CI setups I've worked with send an email (to a list), but if you did want—especially if your team uses FogBugz much as a todo system—you could just open a case in FogBugz 6. It has an API that lets you open cases. For that matter, you could just configure it to send the email to your FogBugz' email submission address, but the API might let you do more, like assign the case to the last committer.

Brian's answer suggests to me, if your CI finds a failure in a commit that had a case number, you might even just reopen the existing case. Like codifying a case field for every little thing, though, there's a point where the CI automation could be "too smart," get it wrong, and just be annoying. Opening a new case could be plenty.

And thanks: this makes me wonder if I should try integrating our Chimps setup with our FogBugz!

OTHER TIPS

At my company we've recently adopted the (commercial) Atlassian stack - including JIRA for issue tracking and Bamboo for builds. Much like the Microsoft world (I'm guessing - we're a Java shop), if you get all your products from a single vendor you get the bonus of tight integration.

For an example of how they've done interoperability, view their interoperability page.

Enough shilling. Generally speaking, I can summarize their general approach as:

  • Create issues in your bug tracker (ex: issue key of PROJ-123).
  • When you commit code, add "PROJ-123" to your commit comment to indicate what bug this code change fixes.
  • When your CI server checks out the code, scan the commit comments of the diffs. Record any strings matching the regex of your issue keys.
  • When the build completes, generate a report of what issue keys were found.

Specifically to your second problem:

Your CI doesn't doesn't have to put anything into your bug tracker. Bamboo doesn't put anything into JIRA. Instead, the Atlassian folks have provided a plugin to JIRA that will make a remote api call into Bamboo, asking the question "Bamboo, to what builds am I (a JIRA issue) related?". This is probably best explained with a screenshot.

CC comes with a utility that warns you when builds fail, it probably isn't worth logging the failing build in FogBugz - you don't need to track issues that are immediately resolved (as most broken builds will be)

To go the other way round (FogBugz showing checkins that fixed the issue) you need a web based repository browser - FogBugz is easy to configure so that it shows the right changes.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top