My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 2507: REST APIs fail for reviews cherry-picked onto other branches
2 people starred this issue and may be notified of changes. Back to list
Status:  AwaitingInformation
Owner:  ----


Sign in to add a comment
 
Reported by oyvindha...@gmail.com, Feb 28, 2014
Affected Version:

What steps will reproduce the problem?
1. Create a review using Gerrit 2.8
2. Cherry-pick it to another branch using the Gerrit web interface. Cherry-pick does not assign a new unique Change-Id but reuses the Change-Id from #1. This was a surprise to me and I'm wondering if it is intentional to reuse the Change-Id or not. A new human-readable number is assigned, so why not a new unique Change-Id?
3. Abandon original review in #1
3. REST API does not work against Change-Id

What is the expected output? What do you see instead?

I would expect the REST API to work against review created in #1 and #2 whether or not the review is abandoned.

Please provide any additional information below.

Feb 28, 2014
#1 oyvindha...@gmail.com
Another side-effect of this is that the Jenkins Gerrit Trigger plugin does not handle the queue correctly because more recent patchsets doe not remove older patchsets from the build queue.

From  Jenkins Gerrit Trigger Plugin:

"Build Current Patches Only - If this is enabled, all still scheduled builds for previous patchsets are canceled when a new build is scheduled by a new patchset."
Mar 4, 2014
Project Member #2 david.pu...@sonymobile.com
It is intentional that the Change-Id is the same.  In earlier versions of Gerrit, the Change-Id was unique across all changes, but now this is not the case.  It can therefore be used to group related changes across projects and branches.

The REST API failure is surprising.  The identifier given to the REST API should include the branch.  Please give more details of the failure.
Status: AwaitingInformation
Mar 4, 2014
#3 oyvindha...@gmail.com
You should be able to reproduce this as follows:

1. create a review
2. paste an URL of the form below into a browser:

http://someserver:8080/a/changes/I2e10ca04e48c25228387839f5339ad3423ce4f5c/revisions/c376f32344c6b6f34584699bd84e2309af8205cd/review

3. the web browser offers you to download a file
4. cherry-pick the review to another branch from the Gerrit GUI
5. create an URL as in #2 above.

=> you get an error message that the web page does not exist.

Mar 4, 2014
Project Member #4 david.pu...@sonymobile.com
In step 5 how are you creating the URL?  Note that on a cherry picked commit the revision (i.e. the commit sha1) will be different.

Also note that according to the documentation [1] the change-Id part of the URL should be in the form `ProjectName~BranchName~ChangeId`.

[1] https://gerrit-documentation.storage.googleapis.com/Documentation/2.8/rest-api-changes.html#get-review

Mar 4, 2014
#5 oyvindha...@gmail.com
In #2 and #5 I'm simply copy and pasting the Change-Id and commit has from the reviews in #2 and #5 respectively.

I'll read up on the docs.

Thanks!
Mar 4, 2014
#6 oyvindha...@gmail.com
Hmmm... did we use a deprecated syntax? If that syntax is illegal(it IS ambiguous) then I'd prefer that it failed rather than worked in some cases...
Mar 4, 2014
#7 oyvindha...@gmail.com
Gotit.

The problem, as I see it, is that the Gerrit URL syntax is too permissive. I would much prefer that it requires project and branch always than that it fails with this syntax sometimes.

Specifically Gerrit will fail with the permissive syntax(that specifies only Change-Id and commit hash, but leaves out project and branch) once a review has been cherry-picked to another branch.
Sign in to add a comment

Powered by Google Project Hosting