Details

    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            cleclerc Cyrille Le Clerc added a comment -

            dan tran we brainstormed with Arnaud Héritier 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

            Show
            cleclerc Cyrille Le Clerc added a comment - dan tran we brainstormed with Arnaud Héritier 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
            Hide
            cleclerc Cyrille Le Clerc added a comment -

            Fixed in 3.6.4

            Show
            cleclerc Cyrille Le Clerc added a comment - Fixed in 3.6.4
            Hide
            dantran dan tran added a comment -

             

            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?

             

            Show
            dantran dan tran added a comment -   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?  
            Hide
            dantran dan tran added a comment - - edited

            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

             

             

            Show
            dantran dan tran added a comment - - edited 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    
            Hide
            thorsten_langer_sla Thorsten Langer added a comment -

            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!

            Show
            thorsten_langer_sla Thorsten Langer added a comment - 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!

              People

              • Assignee:
                cleclerc Cyrille Le Clerc
                Reporter:
                thorsten_langer_sla Thorsten Langer
              • Votes:
                1 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: