[JIRA] (JENKINS-49897) gerrit-plugin pr branch names are incorrectly name

[sorin.sbarnea@gmail.com (JIRA)]

Sorin Sbarnea updated an issue

Jenkins / JENKINS-49897 gerrit-plugin pr branch names are incorrectly name Change By: Sorin Sbarnea Component/s: multi-branch-project-plugin (not Pipeline) Add Comment

This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)

[sorin.sbarnea@gmail.com (JIRA)]

Sorin Sbarnea created an issue

Jenkins / JENKINS-49897 gerrit-plugin pr branch names are incorrectly name

Issue Type: Bug Assignee: lucamilanesio Components: gerrit-plugin Created: 2018-03-03 18:58 Priority: Major Reporter: Sorin Sbarnea It seems that there are some naming problem with how gerrit-plugin is exposing the PR branches to Jenkins. 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. 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. 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". C) On Classic UI, the PR branch is recognised as a normal branch and not as a PR. The PR tab is not created. Clearly the Classic UI is able to display PR separately because they do this correctly for GitHub based branch sources. Even more funny is that if someone configures two SCM sources on the same multibrach project, one as Gerrit and one as GitHub, the display of PR/CR is made correct. This means that simple existence of GitHub SCM branch make the multibranch display them correctly.

Add Comment

[sorin.sbarnea@gmail.com (JIRA)]

Sorin Sbarnea updated an issue

Jenkins / JENKINS-49897 gerrit-plugin pr branch names are incorrectly name

Change By: Sorin Sbarnea Component/s: workflow-multibranch-plugin Component/s: multi-branch-project-plugin (not Pipeline)

Add Comment

[lucamilanesio@java.net (JIRA)]

lucamilanesio commented on JENKINS-49897

Re: gerrit-plugin pr branch names are incorrectly name 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. Sorin Sbarnea what do you think?

Add Comment

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

[josesa@java.net (JIRA)]

Jose Sa commented on JENKINS-49897

Re: gerrit-plugin pr branch names are incorrectly name

I also consider that we should only consider the gerrit review id (6 digits number) as the branch name, and treat it the same way as the other actual branches. This way all individual patches, manual replays, etc... will be displayed in the history of that branch, retaining a build history while the review is open. As it is right now, once a new patchset is uploaded previous related builds are destroyed and only the latest patchset "job" is available, effectively loosing history and for me that is a serious bug.

Add Comment

[luca.milanesio@gmail.com (JIRA)]

Luca Domenico Milanesio commented on JENKINS-49897

Re: gerrit-plugin pr branch names are incorrectly name

The multi-branch pipeline can be configured to keep the obsolete branches (patch-sets not up to date) for a number of days. Would that resolve your issue?

Add Comment

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

[andreas@unjo.com (JIRA)]

Andreas Fritiofson commented on JENKINS-49897

Re: gerrit-plugin pr branch names are incorrectly name

I would also vote for having only the Change number field as the PR name. Having the Patchset number as part of the branch/PR makes Jenkins forget the history of the change. All PRs only get one build because Patchsets are seen as different PRs, so the statistics provided by plugins such as Warnings are meaningless. I don't really buy the motivation for the Patchset number quoted above; that it's needed to retrigger a build of a Patchset. If a newer Patchset is uploaded, it obsoletes all previous Patchsets of that Change. They cannot be submitted, so what is the point of building them at all? In fact in a comment to JENKINS-60301, it's even discussed to abort ongoing builds of older Patchsets when a new one is uploaded. Besides, since the job for the current Patchset is removed when a new is uploaded, you can't even retrigger a build.

Add Comment

[luca.milanesio@gmail.com (JIRA)]

Luca Domenico Milanesio commented on JENKINS-49897

Re: gerrit-plugin pr branch names are incorrectly name

What would be the point of re-triggering a build for an obsolete patch-set? Can you point me to the statistics that would be useful if we would keep the same job for the same change? (URL of the feature you would have the associated benefits?)

Add Comment