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

This widget could not be displayed.

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 https://jira.mycompany.com/fisheye/cru/ABC-123 -- so where would the REST API live? I have tried https://jira.mycompany.com/fisheye/cru/rest-service/reviews-v1/ABC-123 and quite a few similar URLs (including https://jira.mycompany.com/fisheye/cru/rest-service/ ), 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:

https://jira.atlassian.com/browse/CRUC-6363

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 = REXML::Document.new review_xml

    # we have to group the revisions by file, due to
    # https://answers.atlassian.com/questions/235556/crucible-get-list-of-changesets-revisions-in-a-review/238685
    revisions_by_filename = Hash.new{|h,k| h[k] = [] }

    review.elements.each(
      'detailedReviewData/reviewItems/reviewItem/expandedRevisions') do |rev|

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

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

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.

https://marketplace.atlassian.com/plugins/biz.deref.flyover.flyoverForCrucible

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.

This widget could not be displayed.

Hi Richard,

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

https://jira.mycompany.com/fisheye/rest-service/reviews-v1/ABC-123/details

Basically, the REST API /rest-service/reviews-v1/ABC-123/details should be added right after your FishEye site URL, which is https://jira.mycompany.com/fisheye.

Please make sure to log into your instance at https://jira.mycompany.com/fisheye/login before running the REST API command above.

I hope this helps!

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted Friday in Bitbucket

What is your #1 piece of advice to new users getting started using Bitbucket?

Hello Community! My name is Claire Maynard, and I’m a Product Marketing Manager on the Bitbucket team. I’m interested in hearing what advice or tips you have for new users getting started on ...

139 views 5 2
Join discussion

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you