-
New Feature
-
Resolution: Duplicate
-
Minor
-
None
Original reporter vernyquartara
When creating a new multibranch job, the names of the subjobs are inferred from the repository path.
For example, if the repo root is http://mysvn.com/repo/* and the include branch expression is branches/, then all the subjobs will be named using the prefix branches/.
This is not always wanted, for example in the case of a multi-project repository layout, such as
- http://mysvn.com/repo/branches/branch1/project-name
- http://mysvn.com/repo/branches/branch2/project-name
- http://mysvn.com/repo/branches/branch3/project-name
the job will have 3 subjobs named branches/branch1/project-name, branches/branch2/project-name, branches/branch3/project-name.
IMHO The user should be able to configure the naming using a configuration option, like a regular expression. For example in the above scenario, using a regex _branches/(.)/._ the subjobs will be called simply branch1, branch2, branch3.
This issue looks like an enanchement but I noticed that _subjobs defaults names cause an error into the downstream job that uses the copy-artifact plugin_, (the upstream artifact couldn't be found), so perhaps is more likely a bug.
Verny
- duplicates
-
JENKINS-34564 Give the ability to choose how the multibranch subprojects will be named.
-
- Resolved
-
[JENKINS-32239] job naming sould be configurable
| Description |
Original:
When creating a new multibranch job, the names of the subjobs are inferred from the repository path. For example, if the repo root is *http://mysvn.com/repo/* and the include branch expression is _branches/*_, then all the subjobs will be named using the prefix _branches/_. This is not always wanted, for example in the case of a multi-project repository layout, such as * http://mysvn.com/repo/branches/branch1/project-name * http://mysvn.com/repo/branches/branch2/project-name * http://mysvn.com/repo/branches/branch3/project-name the job will have 3 subjobs named _branches/branch1/project-name_, _branches/branch2/project-name_, _branches/branch3/project-name_. __IMHO The user should be able to configure the naming using a configuration option__, like a regular expression. For example in the above scenario, using a regex __branches/(.+)/.+__ the subjobs will be called simply _branch1_, _branch2_, _branch3_. This issue looks like an enanchement but I noticed that __subjobs defaults names cause an error into the downstream job that uses the copy-artifact plugin__, (the upstream artifact couldn't be found), so perhaps is more likely a bug. Verny |
New:
Original reporter [~vernyquartara] When creating a new multibranch job, the names of the subjobs are inferred from the repository path. For example, if the repo root is *http://mysvn.com/repo/* and the include branch expression is _branches/*_, then all the subjobs will be named using the prefix _branches/_. This is not always wanted, for example in the case of a multi-project repository layout, such as * http://mysvn.com/repo/branches/branch1/project-name * http://mysvn.com/repo/branches/branch2/project-name * http://mysvn.com/repo/branches/branch3/project-name the job will have 3 subjobs named _branches/branch1/project-name_, _branches/branch2/project-name_, _branches/branch3/project-name_. __IMHO The user should be able to configure the naming using a configuration option__, like a regular expression. For example in the above scenario, using a regex __branches/(.+)/.+__ the subjobs will be called simply _branch1_, _branch2_, _branch3_. This issue looks like an enanchement but I noticed that __subjobs defaults names cause an error into the downstream job that uses the copy-artifact plugin__, (the upstream artifact couldn't be found), so perhaps is more likely a bug. Verny |
| Description |
Original:
Original reporter [~vernyquartara] When creating a new multibranch job, the names of the subjobs are inferred from the repository path. For example, if the repo root is *http://mysvn.com/repo/* and the include branch expression is _branches/*_, then all the subjobs will be named using the prefix _branches/_. This is not always wanted, for example in the case of a multi-project repository layout, such as * http://mysvn.com/repo/branches/branch1/project-name * http://mysvn.com/repo/branches/branch2/project-name * http://mysvn.com/repo/branches/branch3/project-name the job will have 3 subjobs named _branches/branch1/project-name_, _branches/branch2/project-name_, _branches/branch3/project-name_. __IMHO The user should be able to configure the naming using a configuration option__, like a regular expression. For example in the above scenario, using a regex __branches/(.+)/.+__ the subjobs will be called simply _branch1_, _branch2_, _branch3_. This issue looks like an enanchement but I noticed that __subjobs defaults names cause an error into the downstream job that uses the copy-artifact plugin__, (the upstream artifact couldn't be found), so perhaps is more likely a bug. Verny |
New:
Original reporter [~vernyquartara] When creating a new multibranch job, the names of the subjobs are inferred from the repository path. For example, if the repo root is *http://mysvn.com/repo/* and the include branch expression is _branches/*_, then all the subjobs will be named using the prefix _branches/_. This is not always wanted, for example in the case of a multi-project repository layout, such as * http://mysvn.com/repo/branches/branch1/project-name * http://mysvn.com/repo/branches/branch2/project-name * http://mysvn.com/repo/branches/branch3/project-name the job will have 3 subjobs named _branches/branch1/project-name_, _branches/branch2/project-name_, _branches/branch3/project-name_. __IMHO The user should be able to configure the naming using a configuration option__ , like a regular expression. For example in the above scenario, using a regex __branches/(.+)/.+__ the subjobs will be called simply _branch1_, _branch2_, _branch3_. This issue looks like an enanchement but I noticed that __subjobs defaults names cause an error into the downstream job that uses the copy-artifact plugin__, (the upstream artifact couldn't be found), so perhaps is more likely a bug. Verny |
| Description |
Original:
Original reporter [~vernyquartara] When creating a new multibranch job, the names of the subjobs are inferred from the repository path. For example, if the repo root is *http://mysvn.com/repo/* and the include branch expression is _branches/*_, then all the subjobs will be named using the prefix _branches/_. This is not always wanted, for example in the case of a multi-project repository layout, such as * http://mysvn.com/repo/branches/branch1/project-name * http://mysvn.com/repo/branches/branch2/project-name * http://mysvn.com/repo/branches/branch3/project-name the job will have 3 subjobs named _branches/branch1/project-name_, _branches/branch2/project-name_, _branches/branch3/project-name_. __IMHO The user should be able to configure the naming using a configuration option__ , like a regular expression. For example in the above scenario, using a regex __branches/(.+)/.+__ the subjobs will be called simply _branch1_, _branch2_, _branch3_. This issue looks like an enanchement but I noticed that __subjobs defaults names cause an error into the downstream job that uses the copy-artifact plugin__, (the upstream artifact couldn't be found), so perhaps is more likely a bug. Verny |
New:
Original reporter [~vernyquartara] When creating a new multibranch job, the names of the subjobs are inferred from the repository path. For example, if the repo root is *http://mysvn.com/repo/* and the include branch expression is _branches/*_, then all the subjobs will be named using the prefix _branches/_. This is not always wanted, for example in the case of a multi-project repository layout, such as * http://mysvn.com/repo/branches/branch1/project-name * http://mysvn.com/repo/branches/branch2/project-name * http://mysvn.com/repo/branches/branch3/project-name the job will have 3 subjobs named _branches/branch1/project-name_, _branches/branch2/project-name_, _branches/branch3/project-name_. _IMHO The user should be able to configure the naming using a configuration option_, like a regular expression. For example in the above scenario, using a regex __branches/(.+)/.+__ the subjobs will be called simply _branch1_, _branch2_, _branch3_. This issue looks like an enanchement but I noticed that __subjobs defaults names cause an error into the downstream job that uses the copy-artifact plugin__, (the upstream artifact couldn't be found), so perhaps is more likely a bug. Verny |
| Link |
New:
This issue duplicates |
| Resolution | New: Duplicate [ 3 ] | |
| Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
| Workflow | Original: JNJira [ 167824 ] | New: JNJira + In-Review [ 198284 ] |
Not sure why copy artifact fails exactly, but getting rid of / in the names would be a good start.