Update job name calculation logic to correctly set names for builds that live inside folders#383
Conversation
…achenko/memory-consumption-optimization
…achenko/memory-consumption-optimization
…hat live inside folders
nikita-tkachenko-datadog
added
the
changelog/Fixed
There was a problem hiding this comment.
This class was formerly known as JobNameConfigurationParser, it's been renamed
| {null, EMPTY_MAP}, | ||
| {"", EMPTY_MAP}, | ||
| {"jobName", EMPTY_MAP}, | ||
| {"jobName/KEY1=VALUE1,KEY2=VALUE2", sampleMap}, |
There was a problem hiding this comment.
I think we have removed some use cases where the jobName was followed by the branch. Is this expected?
There was a problem hiding this comment.
Yes, I've examined the Jenkins Matrix Plugin docs, and could not find a way to include branch in the job name for multi-configuration projects.
It looks like the only way to have branch included in the job name is to create a Multibranch pipeline or an Organization Folder (and those cannot have parameters).
As far as I understood, historically the parser was being used both for parsing configurations and for extracting the "normalised" (i.e. without branch) job names. That seems to have been the case before the changes Albert made to job name calculation. That'd explain why it contained the logic for trimming branch.
Unless I'm missing something :)
2 participants
Requirements for Contributing to this repository
What does this PR do?
Changes logic that calculates pipeline names.
Previous version of the logic always retrieved the name from the job's parent.
This was needed, because some jobs had names that are too specific (for multibranch projects the job name contained branch, for multiconfig projects the job name contained configuration values).
This worked for regular projects, because the job parent was
Jenkins, and its full name was empty, so the logic fell back to using job name.However, this does not work for regular projects (or pipelines) that live inside folders.
In this case the job's parent is the folder, and so the logic uses folder name as the pipeline's name.
So all pipelines residing in a folder have the same name.
The logic was fixed to only use parent for name calculation if the project is either multi-branch or multi-config.
Below is the table that has multiple examples of different kinds of projects, along with the results of applying different name calculation logic to them.
<style> </style>It can help to explain the rationale behind calculating pipeline name the way it is done now.
Description of the Change
Alternate Designs
Possible Drawbacks
Verification Process
Additional Notes
Release Notes
Review checklist (to be filled by reviewers)
changelog/label attached. If applicable it should have thebackward-incompatiblelabel attached.do-not-merge/label attached.kind/andseverity/labels attached at least.