Crucible - get list of changesets / revisions in a review

[Richard Bradley]

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)"

[Felipe Kraemer]

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!

[Richard Bradley]

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?

[Richard Bradley]

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).

[Alexander Taler]

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

[Richard Bradley]

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

[Richard Bradley]

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?

[Richard Bradley]

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. :-(

[Alexander Taler]

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

[Richard Bradley]

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 :-))

[Alexander Taler]

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.

[Felipe Kraemer]

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!