| Thanks for taking a look into this, from my point of view I won't say it is a bug but more a feature request, that's why I marked it as a new function, and would expect to find it as a new behavior or maybe added to the 'advanced checkout behaviors'.
Our build combines artifacts from different source repositories int one final artifact, for different reasons we can't just merge them or build them independently, but beside from that the case can be generalized to have two source.repositories Master + Child:
- Master contains a Jenkinsfile and is used in a multi-branch-pipeline, and uses 'checkout scm'
- The Jenkinsfile of Master later on contains 'checkout scm Child'
a Jenkinsfile might look something like this:
steps {
checkout([$class: 'GitSCM', branches: [[name: '*/master']], userRemoteConfigs: [[url: 'http://master/repro']]])
sh 'mvn clean install master/pom.xml'
checkout([$class: 'GitSCM', branches: [[name: '*/master']], userRemoteConfigs: [[url: 'http://child/repro']]])
sh 'mvn clean install child/pom.xml'
sh 'aggregation.sh'
}
What happens now is, that while the part in Jenkinsfile is running before the 'checkout scm Child' someone pushes a new commit to Child and when the pipeline reaches that step it fetches the new commit and thus building 'Child' in a different (from the point of happens-before-relation) version than 'Master' So what would be needed is some kind of checkout behavior that not checkouts 'specific revision which triggered this Pipeline run but checkouts 'most recent revision when the build starts', something like
git checkout 'master@{BUILD_DATE}'
|
