I did attach two simple test-scenarios, both with project "A" and "B".

In the "working" scenario, jenkins did see the relationship correctly between B and A, so that when B was build A will be build later. (makes sense, direct dependency did change)

In the "failing" scenario, the "B" project did create a release (0.0.1), move the development version to 0.0.2-SNAPSHOT. However the A project decides that they want only the latest stable version, so they switch their dependency to the 0.0.1 release.

Now, however, when Jenkins (1.487) builds B with 0.0.2-SNAPSHOT it does trigger the A job too! (which makes no sense, because A is using the "stable" build 0.0.1, which should not change, so no re-building ins needed.)
This did lead to a massive increase of number of projects building (and me having to switch off the option on 100+ jenkins jobs ..)

I think the behavior was correct at least in 1.474, where only depdencencies with exactly the same dependency version got build.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to