What would be the point of re-triggering a build for an obsolete patch-set?
I have no idea, it sounded like you wanted to do it in your first comment above. I don't want to do it, and it can't even be done. So let's forget about that. What I now realize you meant in that comment was that you think the PatchSet number in the branch name is important to be able to manually verify (e.g. when re-triggering a build) that Jenkins is up-to-date about which is the latest PatchSet in Gerrit. So you don't accidentally trigger a build before Jenkins has realized there's a new PatchSet and you end up with a build of an obsolete PatchSet. Sounds like a valid point, although I guess the commit SHA1 is a stronger check for that.
The problem I had (and have) with treating each PatchSet as a fresh new job is that you don't get the nice statistics the Jenkins provide across the build numbers (since there will only ever be one build per job). This also affects other plugins that show statistics, such as Warnings. You cannot see how a Change has evolved. This of course assumes that the branch names being unique per PatchSet instead of Change is the only issue that prevent the statistics from working. If you point me to where the names are determined in the plugin source code, I can build a custom version and see if it actually does help in this case.
If we look at the original bug report it has actually four parts:
A) On BlueOcean UI PR branches are named "C-123456/2" which is problematic for two reasons: string is too long to be correctly displayed in UI, which allows only ~6 chars.
This is still the current naming, however I'm not sure if BlueOcean still has the ~6 char limitation. I don't have so many changes... I think if this is still a problem it should be fixed in BlueOcean, right?
By the way, what is the motivation for the C- prefix, does it mean anything? Why is it different from the name each change has in the Classic UI? Even within BlueOcean, if you click on a PR C-12345/6, the header then says Pull Request: 45/12345/6 (like the Classic name), so not even consistent. What is the name of the Pull request? It seems there are two different and unless that's a feature, it should be changed.
B) BlueOcean: exposed branch name exposes internals of gerrit implementation of temporary branches which is useless to the user "56/123456/2". 56/ prefix is only the last part of the original changeset and used for hashing folder name. last number is the version of the patchset.
Yeah, this is just pointless and should be removed, the name should be just 12345, or 12345/6, whichever is chosen. Surely not 45/12345/6. This is not only for BlueOcean, the Classic change name is also on this format.
But from the logical point of view a PR/CR should be a single branch, regardless how many patchsets are build inside it. It makes sense to have a numeric only branch name, like "123456".
This could be discussed, I'm not sure of all the consequences of either choice.
C) On Classic UI, the PR branch is recognised as a normal branch and not as a PR. The PR tab is not created.
This seems to work now.
Thanks for reporting the issue: it doesn't exactly classify as a bug IMHO. However, yes, the branch name is quite misleading.
With regards to the fact that the Gerrit change-id is an internal implementation of the branch, yes I agree. However, GitHub PRs are displayed with the PR number, which is also an internal implementation of the branch.
What I could drop is the initial prefix, which is only a namespace partitioning done by Gerrit to allow a faster execution.
Last but not least, the path number suffix. That one is REALLY NEEDED because it represents what you've build. If I want to retrigger a build of a patch-set, I need that information because I want to be sure of what I am building.
Gerrit changes are very different from GitHub PRs from that point of view.
ssbarnea what do you think?