-
Bug
-
Resolution: Unresolved
-
Minor
-
Jenkins 1.609.1
Workflow 1.9-beta-1
git 2.4.0
git-client 1.18.0
-
-
Pipeline - October, Pipeline - April 2018
if you have a workflow which uses multiple git repositories the actions and data contributed to the build by the git plugin produce almost unusable visual spam.
The tag action does not let you know which repository you are tagging, nor does the build data tell you which repository it is that has the specified hash.
Coupled with this you end up with 2 * the number of repos used (plus another 2 if you use workflow from SCM) actions - which simply does not scale. The actions should be refactored so there is one action that can display the data from multiple repositories / invocations and it should be clear which revision comes from which repo.
node { git url: 'git@github.com:jenkinsci/git-client-plugin.git' git url: 'git@github.com:jenkinsci/git-plugin.git' git url: 'git@github.com:jenkinsci/github-plugin.git' // just add more random repos to get the picture... }
- depends on
-
JENKINS-29326 Workflow sidebar has duplicated Git Build Data links
-
- Reopened
-
- is related to
-
JENKINS-35176 "Tag this build" link repeated in Pipeline job with multiple svn step
-
- Resolved
-
-
JENKINS-54868 Display Organization/Project and Repository name(s) on the job details page
-
- In Review
-
- links to
In the Additional Behaviors section of the git plugin config, you can specify a "Custom SCM Name" - this is particularly useful historically when using the Multiple SCMs plugin, e.g., in part because it makes the UI a bit nicer as things are now. So while most cases aren't going to have this set, I'd still like to use that as the first possibility when it is set, since it gives more user control, etc.
The third scenario is for Weird Git Usage Cases - i.e., when in the normal Git SCM UI, you're specifying multiple remote repositories but not multiple clones...it's a weird feature, IMO, but it is there, so I need to factor it in. Pretty much every Workflow scenario wouldn't fit that - each "git" Workflow DSL step call would result in a separate BuildData with a single remote repo/repo name, so falling into the second scenario.
I'm...not sure how to deal with the conditional tagging rights thing. That's an interesting question, but not an easy answer. I don't see a smooth way to do that.