which version of the pipeline-maven-plugin are you using?

Hi! 

We are currently on 3.5.9, and tested 3.5.15.  Both with the same effect.

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.

• Please test beta version 3.6.4-beta-1
• To verify, please enable logs org.jenkinsci.plugins.pipeline.maven.listeners.DownstreamPipelineTriggerRunListener at the FINE level and see message such as

  [withMaven] downstreamPipelineTriggerRunListener - Skip triggering my-multi-jar-project » PR-1 for 
  MavenArtifact{com.example.multi-jar:shared-core:jar:0.0.1-SNAPSHOT(version: 0.0.1-20181202.224248-35, snapshot:true) } 
  because it generates artifact with same groupId:artifactId 
  MavenArtifact{com.example.multi-jar:shared-core:jar:0.0.1-20181202.224107-34(version: 0.0.1-SNAPSHOT, snapshot:true) }
  

• Please ensure that you use a MySQL database instead of the embedded H2 database as documented in "Using a MySQL Database"

To download 3.6.4-beta-1: https://github.com/jenkinsci/pipeline-maven-plugin/releases/tag/pipeline-maven-3.6.4-beta-1

Hello!  

 Thank you for your efforts so far.  It might take a few more days for us to test, but I will answer you here.

Thanks thorsten_langer_sla

Shipped in v3.6.4

dantran we brainstormed with aheritier and we felt that a reasonable default behaviour would be to not trigger pipelines that work on the same pom.xml. The implementation we chose, as we don't capture for the moment the pom.xml details (1), is to not trigger pipeline that generate the artifact that would be the reason of the trigger.

This solution is fixing all the problems of multi-module Maven projects with multiple git branches but is unfortunately excluding your scenario.

How frequent in your organisation is this scenario of chaining pipeline using same pom.xml? How many Maven apps do you build? How many Maven pipelines do you have? How many of such chain of pipelines do you have?
Did you consider merging these chained pipelines in a single pipeline job? Did you face problems trying this?

(1) SCM details + path in the SCM repo + introducing a POM entity in our data model between the builds and the dependency

Fixed in 3.6.4

We have one large repo with 400+ maven modules including both production and integration test sources.  Main repo build (~60min)  does build integration test modules abut not running them.  We also have many wrapper repos clone the main repo at build time and run

  * subset of integration tests at each repo ( ie main build trigger a number of parallel integration test builds

  * Platform sanity builds ( windows, etc)

Merge them into a single pipeline are big, complex, and long.

is there a way to disable maven pipeline event listener after we clone the main repo at the test pipelines?

on the second thought, i am going to create a delegate job to invoke my sub jobs directly.  So we good ( a --> b --> delegate --> c,e,f   etc )

but, it would be great to have this fix  https://issues.jenkins-ci.org/browse/JENKINS-53382

We can confirm, that the triggering from master to branches does not occur anymore.

We tested this using the standard DB, because changing the DB to the MySQL version mentioned above was a bit tricky in our setup.

In the log-file we cannot see any of these skip-messages you expected.

Please note, that the branches (jobs) are still listed as downstream jobs of master job in the maven tab in the classic website.

 Thank you very much!