Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
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
- relates to
-
-
- Closed
-
-
JENKINS-53382 Add option to trigger downstream even when current upstream's parent is active
-
- Open
-
Activity
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?
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?
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
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
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!
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