-
Bug
-
Resolution: Unresolved
-
Major
-
None
On "master" task, no problem, jenkins checkout good repo and branch.
But on "slave" tasks, It checkout the same branch for all scm (git in my case).
How-to reproduce?
- create a multiconfiguration project
- Add 2 scm git
- 1 for repo/branch A (on / by default, or on dir "A", irrelevant)
- 2 for repo/branch B and put it on dir "B"
- add configuration matrix, with one axis that can take multiple values
On slave the folders structure gets created correctly, but the second one is empty.
When checking the console output, the "master" task clones and checks out the two repos correctly (different revision numbers (long string, probably a hash) for each of the 2 repos).
Each of the "slave" tasks defined by the configuration matrix, will try to fetch and checkout the same revision number for both repos, and therefore will fail on the second one.
[JENKINS-23445] Can't use matrix-project with multiple-scms
| Workflow | Original: JNJira [ 156073 ] | New: JNJira + In-Review [ 179203 ] |
fabri ba
made changes -
| Description |
Original:
On "master" task, no problem, jenkins checkout good repo and branch. But on "slave" tasks, It checkout the same branch for all scm (git in my case). How-to reproduce? * Add 2 scm git ** 1 for branch master (on / by default) ** 2 for branch debian and put it on dir "debian" /debian will be the same than / and will fail :) |
New:
On "master" task, no problem, jenkins checkout good repo and branch. But on "slave" tasks, It checkout the same branch for all scm (git in my case). How-to reproduce? * create a multiconfiguration project * Add 2 scm git ** 1 for repo/branch A (on / by default, or on dir "A", irrelevant) ** 2 for repo/branch B and put it on dir "B" * add configuration matrix, with one axis that can take multiple values On slave the folders structure gets created correctly, but the second one is empty. When checking the console output, the "master" task clones and checks out the two repos correctly (different revision numbers (long string, probably a hash) for each of the 2 repos). Each of the "slave" tasks defined by the configuration matrix, will try to fetch and checkout the same revision number for both repos, and therefore will fail on the second one. |
The Jenkins Pipeline provides this facility in a more flexible, reliable, and supportable way. Rather than using a matrix configuration job, use:
If there is some critical reason that you cannot use Declarative Pipeline, then use:
Declarative Pipeline should be the first path because it intentionally limits the types of mistakes that a new user can make. It is the second generation of Jenkins Pipeline domain specific language. It uses what was learned from the first generation language (scripted) to intentionally reduce user mistakes.
Declarative Pipeline jobs can be defined graphically with Jenkins Blue Ocean. See the Jenkins Minute series for brief clips that illustrate Pipeline editing with Blue Ocean:
- Jenkins Minute Videos (9 of them)
If you prefer a longer session, you could view:
fabri ba
added a comment - Thank you markewaite I'll have a look into that, appreciate your help!
Hi kohsuke any progress on this?