Background:

I setup the Gerrit Code Review Plugin for Jenkins because the Gerrit Trigger wouldn't work with our company firewall.  Your plugin works great though.

<edited to remove stuff about refspec which I'm not sure was correct>

As mentioned in the issue above, it names the jobs as the full change name (e.g. 45/21445/1). 

It would be super if the job was just named 21445 or even 45/21445 and then the patchset could become the build number (or build description and build number just incrementing number for each build).  This would make a lot more sense, I think.  Then if you wanted to use Jenkins pipeline code to kill your other patchset (still running) for a given change, you could use

milestone(buildNumber)

This would help cover some requirements met by Gerrit trigger.

This would also be more in line with how other change-request multibranch pipeline plugins work. For example, Github's pull-request are named with the branch "PR-###", so each new commit to the PR simply triggers a new build for the one change, rather than creating a whole new "branch".

The fix should be as simple as changing the generated branch name to omit the patchset portion. Should be an easy Pull Request to make. Though it's possible some might disagree, and would argue for it to be configurable instead.

I tried to use Jenkins groovy code rename the patchsets when the build started... instead of the full patchset name I used Issue # or PR #, but it got messy real fast so I deleted that and I just leave them as individual patchsets now.  Here is what I see when I click on my Gerrit pipeline job:

I then click "Changes" tab and see these.  I do configure the buildname as the PR # and that shows up ok (see Last Success column). 

I'll open a PR to name the branch with just the change number, instead of the full ref, and see what Luca thinks.

Seems it's not as simple as I'd hoped, at first glance. There is additional code that relies on the branch name to match the ##/#####/# pattern. And there aren't any unit tests to verify what revision will get checked out in the checkout stage, so I don't feel comfortable just making the change blindly, as it looks like at least some other functionality will break

Thanks Joe.  I limited the number of changes just now to 30 (previously I allowed 100 in Jenkins' Orphan Strategy) so that is manageable as it is. 

One thing I still haven't implemented in my pipeline is killing prior patchset builds when a newer one is started.  I know Gerrit Trigger does this, but I can't use Gerrit Trigger plugin due to how it communicates with Jenkins.  Plus I think gerrit-code-review plugin is better in the long run as everything is done from the pipeline code.   Pipeline's milestone will also do this, but your jobs have to be setup with a certain hierarchy for it to work (which doesn't seem so easy with Gerrit Code Review Plugin).