|
I don't know if this is a Build Pipeline Plugin bug or a Fingerprint bug, or a Maven Plugin bug, but it is more in the way when using the BP Plugin. Or a feature.
I have a multi-module Maven3 project:
foo-parent
/foo (war module)
/foo-integration with a dep on "foo" (will contain Selenium tests in the future)
I have 3 Jenkins jobs:
- Foo (mvn clean install, restricted to /foo)
- Foo-Checks (mvn some:checks foo-parent, restricted to /foo)
- Foo-Integration (mvn some:things foo-parent, restricted to /foo-integration)
Everything is run against foo-parent. "restricted to /foo" means "-pl foo -am" mvn option.
Foo is triggered by SCM
Foo has a post build action: it triggers Foo-Checks
Foo has a post build action: Build Pipeline downstream job (allow to trigger Foo-Integration)
At this point, everything is perfect:
- Foo-Checks is a downstream job of Foo
- Foo-Integration is a downstream job of Foo-Checks
- The build pipeline view shows:
If Foo is triggered, still OK.
But, if I manually trigger Foo-Integration in the Build Pipeline view:
- Foo-Integration becomes a downstream project of Foo
- The build pipeline view shows:
I tried to delete some fingerprints, but I have the feeling there is some "magical" in the job tree algorithm using Maven dependencies.
Is this really a bug?
If not a bug, would it be possible to have an option to set the "upstream/downstream" tree ignore maven dependencies/modules? Or just in the Build Pipeline tree?
|
