-
Bug
-
Resolution: Fixed
-
Critical
the setup:
- a multi-module, Jenkinsfile-based, maven project.
- builds are triggered via notifications from gitlab, manually or by SNAPSHOT builds of dependencies (per checkbox).
- only the master (and tags) gets deployed to an artifactory.
- every build uses a temp local maven repository - which is swiped afterwards.
- so we don't change the version in branches, as their artefacts never leave their sandbox (workplace directory).
I experience, that the master-build/job triggers (on success) the build of the branches. This makes some kind of sense, as formally the modules depends on the artifact build in the master, but on the other hand, it does not make sense, because the triggered branches-builds/jobs will build these triggering artifacts on their own.
I'm looking for some solution to suppress the triggering of builds by other jobs, that build the very same artifacts (at least according to their maven coordinates), the triggered build will build on their own.
The current workaroud is to change the version in the branches (random or branchname-based), but this seems to me like a hack.
A possible solution is to substract the set of own-generated artifacts from the set of triggering artifacts when deciding if another job should be executed.
- relates to
-
-
- Closed
-
-
JENKINS-53382 Add option to trigger downstream even when current upstream's parent is active
-
- Open
-
[JENKINS-54515] master triggers own branches
Hi!
We are currently on 3.5.9, and tested 3.5.15. Both with the same effect.
| Assignee | Original: Alvaro Lobato [ alobato ] | New: Cyrille Le Clerc [ cleclerc ] |
Is there something I can do to support you understand or reproduce this issue? (I'm still not sure, if it's a bug or a feature request).
thorsten_langer_sla can you please confirm that the pipeline that is triggered in an undesired manner is using the same pom.xml hosted on the same git repository and that the different branches have the same maven artifact version identifier?
I want to find a generic way to understand that 2 pipelines relate to the same pom.xml. I would like to avoid finding the relationship going through the discovery of a parent multi branch pipeline.
I can confirm this.
- identical repos in 'master' and any branch.
- identical pom.xml files in master and usually all branches. (at least in regard to all poms' own project/group|artifactId|version in top level and modules).
- identical Jenkinsfile (see below)
- but: different (git) branches. The distinction per {{when { buildingTag() } }} works quite fine
#!/usr/bin/env groovy
pipeline {
agent any
tools {
maven 'apache-maven-3.3.9'
jdk 'jdk1.8.0-latest'
}
options {
gitLabConnection('weblab.local')
gitlabBuilds(builds: ['Java-Build-And-Install'])
buildDiscarder logRotator(artifactDaysToKeepStr: '30',
artifactNumToKeepStr: '30',
daysToKeepStr: '30',
numToKeepStr: '30')
}
triggers {
gitlab(triggerOnPush: true,
triggerOnMergeRequest: true,
branchFilterType: 'All')
}
environment {
MAVEN_PROFILES = "-P continuousintegrationProfile -P slaSnapshotsProfile"
}
stages {
stage('Java-Build-And-Install') {
steps {
gitlabCommitStatus(name: 'Java-Build-And-Install') {
withMaven(
mavenLocalRepo: 'local-repo') {
sh "mvn clean install ${MAVEN_PROFILES}"
}
}
}
}
stage('Java-Deploy') {
when { anyOf {
branch "master"
buildingTag()
}}
steps {
gitlabBuilds(builds: ['Java-Deploy']) {
gitlabCommitStatus(name: 'Java-Deploy') {
withMaven(
mavenLocalRepo: 'local-repo') {
sh "mvn deploy -DskipTests=true ${MAVEN_PROFILES}"
}
}
}
}
}
}
post {
cleanup {
cleanWs()
}
}
}
Out current workaround is the following pre-install-stage:
It gives the accidently-to-be-triggered artifacts in the branches branch-specific names, so they won't be triggered by builds in master.
stage('Java-Rename-Version') { when { not { anyOf { branch "master" buildingTag() }}} steps { gitlabBuilds(builds: ['Java-Rename-Version']) { gitlabCommitStatus(name: 'Java-Rename-Version') { withMaven( mavenLocalRepo: "local-repo") { sh "mvn versions:set -DskipTests=true -DnewVersion=0.0.0-branch-${env.GIT_BRANCH}-SNAPSHOT -DgenerateBackupPoms=false ${MAVEN_PROFILES}" } } } } }
My 2 cents about a generic solution:
After identifing all to-be-triggered pipelines (per fingerprint), a.k.a. the downstreams, you/one will have to filter out those pipelines, that earlier proved (maybe in their last run) to at least generate all/any 
of the triggering artifacts. The identification of there (suppressed) triggers should be done by groupId, artifactId and version.
The bad thing in the branches pipelines is, that the identification of fingerprints of the dependencies/artifacts did obviously happen. Actually a bit too good. But: the fingerprinting of the created artifacts in the branches possibly did not occur, because they where not be released (lack of deploy phase?). So the information to decide to suppress the trigger for a certain branch (or not) might not have been retrieved in the branches yet.
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
| Link |
New:
This issue relates to |
| Status | Original: In Progress [ 3 ] | New: In Review [ 10005 ] |
which version of the pipeline-maven-plugin are you using?