On Thursday, March 21, 2019 at 4:20:54 PM UTC+1, Cyrille Le Clerc wrote: > > > >> Please see new FAQ entry > https://wiki.jenkins.io/display/JENKINS/Pipeline+Maven+Plugin#PipelineMavenPlugin-HowcanItroubleshootproblemsoftriggerofdownstreampipelines > > I have improved the FAQ entry based on your feedback, can you please have > a look? >
Much better. Only the last sentence looks cut off: "Troubleshooting details are added". Did you mean "You will find details to troubleshoot the issue below that line"? > > > I had to add a "Pipeline Graph Publisher" with the dropdown "Add > Publisher Options". In there, I could switch the option "Maven lifecycle > phase threshold" from "deploy" to "install". > > Good that you figured this out. The User Experience is not great but I > didn't find better so far. > How about printing "downstream not triggered because project used "mvn install" and the lower limit for triggering is "mvn deploy" + link to config where you can change that or a help page? > > > That leaves the weird behavior of the artifactsPublisher and my comments > about the new FAQ item. > > There is a non intuitive UX on the Pipeline Maven Plugin here: the > artifactPublisher is just about "fingerprinting" and "archiving" the > generated artifacts, it is NOT about updating the dependency graph that > tracks (in a database) the produced and consumed artifacts. The > "pipelineGraphPublisher" was introduced way after the "artifactsPublisher" > (~6/12 months after). > I suspect that the "pipelineGraphPublisher" is invoked twice in your > pipeline. > I searched for "pipelineGraphPublisher" which got me no hits. Then "graph" which produces exactly one hit: [withMaven] Publishers: Pipeline Graph Publisher: 12 ms, Generated Artifacts Publisher: 31 ms, Junit Publisher: 52 ms, Dependencies Fingerprint Publisher: 4 ms, Jacoco Publisher: 12 ms, Open Task Scanner Publisher: 14 ms Seems like that plugin is a quiet one :-) Any hints? > That triggers the downstream builds of feature branches. Now, I have to > figure out how to share the artifacts. See my post "Chained builds" for my > thoughts on that. > > I'll have a look, it is a difficult problem to solve. I didn't yet deep > dive in https://maven.apache.org/maven-ci-friendly.html that seem to be > related to the problem you want to solve. > I read through the document and it seems an attempt to solve something but after reading it, I'm unsure what exactly. Maybe what they try is to give the build result of each branch a unique version? So you could deploy all of them to Nexus and the next build would pick the right one to use. The use of the Flatten Maven Plugin worries me a bit but I think this is necessary because Maven doesn't support variables in the project.version property (for good reason). But some things like removing dependencyManagement elements seems completely wrong to me. Still, the idea to solve the "Maven doesn't support branches" by using one version per branch sounds promising. Does Jenkins take the version into account when building downstream projects i.e. if the downstream project has a dependency on 2.x-SNAPSHOT, it will not get triggered when I build 2.x-FOO-SNAPSHOT? Regards, -- Aaron Digulla -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/37b50674-93ec-4c46-b852-2ef6f19612a3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
