timja
commented
4 years ago Hmm, after thinking about this item a bit more, i feel like...
- the hierarchy of names (as also used in the path for the url) for an individual job builds up in the order: folder(s), job, branch
- non existing names will just vanish from these chain of names
- the JOB_BASE_NAME resolves to the last name in the chain
further i might conclude for now like this:
- its up to the user to /guess/ if a certain name might originate from the branch naming
- its up to the user to trim his name so that its usable for a certain purpose - or - otherwise tick for different name from the chain that fits into his particular purpose for a descriptive string
This report is created from a single case with an issue - with guess for operation at other common cases.
case 1 - exposes the problem i am seeing:
JOB_NAME=my_job_name/my_git_branch_name
JOB_BASE_NAME=my_git_branch_name
case 2 - similar to case 1:
JOB_NAME=my_job_name/some_git_branch_category_prefix%2Fmy_git_branch_name
JOB_BASE_NAME=some_git_branch_category_prefix%2Fmy_git_branch_name
case 3 - created based upon some small test case:
JOB_NAME=jenkins_job_subfolder_for_testing/my_job_name
JOB_BASE_NAME=my_job_name
case 4 - created based upon some other small test case
JOB_NAME=my_job_name
JOB_BASE_NAME=my_job_name
expectation:
all cases will result in this for the second item - but case 1 and 2 wont do that:
JOB_BASE_NAME=my_job_name
side note - how I did discover that problem:
i found warnings_next_generation/ng plugin having problems with these (at my desk) often lengthy and %-sequences containing branch names. the visualisation was not that usable anymore due to shortening of names (at least in the web display, but maybe at even more places internally) and assume internal malfunctions due to this.
Originally reported by alexanderstohr, imported from: JOB_BASE_NAME generation might have issues in certain cases