Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Crucible - get list of changesets / revisions in a review

How can I get an accurate and exhaustive list of all changesets / revisions which have been added to a review?

I can browse all the files in the review, and note the commit hashes (with git) at the top of each page, but I'd like to be able to see this more easily.

Is there anywhere that this is listed? An API call would be acceptible.

I am using "Atlassian FishEye analysis with Crucible code review. (Version:3.1.4 Build:20131008122028 2013-10-08)"

2 answers

2 votes

Hi Richard,

You can use this REST API call. This will return, among other things, a list of files and their changesets.

I hope this helps!

Thanks, that looks promising, but I need a bit more help getting to the REST API. I have a review at -- so where would the REST API live? I have tried and quite a few similar URLs (including ), but they all give me "There is no Action mapped for namespace /cru and action name rest-service.". How can I make this work?

Thanks very much, that does return all commit hashes in the review (grouped by filename, so I'll have to do a bit of processing to get a distinct list of all commits that have been added to the review, but the data is in there).

Be aware that the listed revisions are not exactly those that have been added to the review. For example, if you're using Subversion and add revision 2507 of a single file to the review, the REST API will also return the previous revision of that file, e.g. 2290 might be included also.

Basically, revisions are grouped, and the first revision of each group is the context for the following ones, so play around with the output until you understand it.

Also, I have raised a bug about this behaviour, which you might want to be aware of:

Thanks, that's a good point Alexander. It's all tied in with the messy data model discussed in that bug and the linked bugs. (Which I'd love to see fixed, but it doesn't look hopefull.)

I wrote the following ruby code which guesses the correct revisions in most cases:

review = review_xml

    # we have to group the revisions by file, due to
    revisions_by_filename ={|h,k| h[k] = [] }

      'detailedReviewData/reviewItems/reviewItem/expandedRevisions') do |rev|

      filename = rev.elements['path'].text
      revision = rev.elements['revision'].text
      revisions_by_filename[filename] << revision

    commits =
    revisions_by_filename.each do |filename, revisions|
      if revisions.length == 1
        commits << revisions.first
        # Drop the first revision: it's Crucible adding the "before" rev to the slider
        commits += revisions

That isn't sufficient -- revisions which Crucible has "sort of included" in the review because they fall in between two revisions which the user explicitly added to the review will still be included by that code :-(

I can't see how to exclude these. Crucible clearly knows that these revisions are not "really" in the review, since it shows the revision tick box as orange when you browse to "add new content" to the review (the image is "/fisheye/static/mucnm4/images/select_some.gif" if someone with access to the code wants to look up the logic behind this state) ... but the API still returns that revision in the "expandedRevisions" section with no distinguishing features v.s. "real" included revisions.

Is there any way to make this work?

Also, how can I tell the difference between a) a file which was added + modified in this review (i.e. the review includes two commits for the file, one of which is an add and one of which is a modify) and b) a file which is modified in this review and whose previous change was a commit which added the file (but the latter commit isn't part of this review)?

These two cases appear to be identical in the API data you linked to, @Felipe, but in the first case I want to look at both commits and in the second case I want to look at only the latter commit.

I think this problem is closely tied to the ambiguities raised in CRUC-6671

It looks to me like it isn't currently possible to get an accurate and exhaustive list of all changesets / revisions which have been added to a review, which is very disappointing for such a seemingly straightforward request. :-(

Hi Richard, I took a look at your Ruby code, you need to drop the first element of each "expandedRevisions" section. Right now your code drops one element for each filename, instead of one for each expandedRevisions. (I made the same mistake the first time around.)

What are you trying to achieve? I went through this learning process in the course of creating a review coverage report for Crucible, which is on the Marketplace, except mine's all Java code in a plugin. I wonder if there's a way you could leverage my work.

Thanks, I'll look into that. As I currently understand it, the first revision for each file is the same as the first revision in each "expandedRevisions" section. Is that not the case?

My aim is similar to yours -- I am writing a tool which will grab all issues detected by static code analysis and automatically add them as review comments. To do this, I need to know which commits are included in the review. As you have found with your review coverage tool, Crucible's data model is a bit buggy around the edge cases and cannot support this apparently simple request!

Atlassian are studiously ignoring all our bugs related to this issue (CRUC-6312, CRUC-6671, CRUC-6363). Perhaps @Felipe can look into this properly, or bring it to the attention of someone who can?

(EDIT: I've raised a support ticket (CRC-6270) to see if that will get Atlassian to take a look at this :-))

I believe that for each file, consecutive revisions are grouped along with the revision immediately before the group (for context and if possible), and provided as an "expandedRevisions". e.g. assuming the simplest revision numbering scheme, if the review contains revisions 1, 2, 5, 6, 9, then we'd get three expandedRevisions groups: [1, 2], [4, 5, 6], [8, 9]

I've never looked at the code, I've only surmised this from observing its behaviour.

1 vote

Hi Richard,

Looks like you have a fisheye context in your URL, so the complete URL should be like this:

Basically, the REST API /rest-service/reviews-v1/ABC-123/details should be added right after your FishEye site URL, which is

Please make sure to log into your instance at before running the REST API command above.

I hope this helps!

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Confluence

An update on Confluence Cloud customer feedback – June 2022

Hi everyone, We’re always looking at how to improve Confluence and customer feedback plays an important role in making sure we're investing in the areas that will bring the most value to the most c...

79 views 0 0
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you