Details
-
Improvement
-
Status: Fixed but Unreleased (View Workflow)
-
Major
-
Resolution: Done
-
None
Description
We're using the "Project Name" strategy, and today someone changed a project's display name (not the path) in Gitlab causing the Jenkins project to be recreated and all build history lost.
Can you add a naming strategy using the project path without namepace? This should provide stability for our projects because Gitlab warns users when changing the project path.
Attachments
Issue Links
- links to
Activity
rross
added a comment - This issue is big enough for us that I would be willing to work on the patch for this myself. Our company needs it badly.
rross
added a comment - This issue is big enough for us that I would be willing to work on the patch for this myself. Our company needs it badly. I have a fix for this in my GitHub fork.
Not sure the steps I should take to put up a PR.
rross
added a comment - - edited I have a fix for this in my GitHub fork.
Not sure the steps I should take to put up a PR. 
Agreed, this is problematic design. We have two options, neither of which are good:
This duplicates the "owner" which is already reflected by the organizational folder of the job.
This is the "Friendly" name of the project which users of GitLab may change at any time without realizing downstream impacts of doing so. Those impacts can be massive. Misaligned job history, reset build number, broken builds, confused users, etc. These names can also contain special characters and spaces which can cause other complications in builds that don't like special (even escaped) characters (e.g. `%`)
What's missing is:
This would be the path sans the first "owner" group segment.
This would be the path sans any group segments.
Both of these are desperately needed here as this has caused significant disruption in our organization and broken over 110 builds when we migrated from Bitbucket to GitLab. Bitbucket's plugin uses "Simple project path".