How does "Build whenever a SNAPSHOT dependency is built" work?

Aaron Digulla

unread,

Apr 10, 2019, 7:15:26 AM4/10/19

to Jenkins Users

Hello,

Is there documentation how this feature works?

I'm especially interested how it behaves when jobA builds a branch X for project A and project B has a dependency on A. Both A and B are multi-branch pipeline projects.

Will that trigger a build of branch X of B or "build all branches of B"?

Regards,

Aaron Digulla

Cyrille Le Clerc

unread,

Apr 15, 2019, 6:24:20 PM4/15/19

to Jenkins Users

Hello Aaron,

If all your downstream branches have a dependency on the same upstream snapshot version, then yes, all downstream pipelines will be triggered, we don't differentiate on the branch identifier.

Did you expect a different behaviour? Wouldn't all the branches of the downstream job deserve to be triggered?

Cyrille

Aaron Digulla

unread,

Aug 27, 2019, 4:45:49 PM8/27/19

to Jenkins Users

On Tuesday, April 16, 2019 at 12:24:20 AM UTC+2, Cyrille Le Clerc wrote:

Hello Aaron,

If all your downstream branches have a dependency on the same upstream snapshot version, then yes, all downstream pipelines will be triggered, we don't differentiate on the branch identifier.

Thanks. I completely missed this answer :-)

Did you expect a different behaviour? Wouldn't all the branches of the downstream job deserve to be triggered?

I try to build a system where we can build PRs across projects. In each project, the PR will use the same branch name.

My reasoning is:

There will be code changes which will break other branches (removed or new API).

Most of our products use at least three projects: Utils, Core and Client. A lot of code is built only in Core and Client but sometimes, we need code in Utils for a client feature. During one release cycle, all three projects will use a SNAPSHOT version. That way, a developer can finish the whole feature in a single JIRA issue (and three PRs in git). The single feature can be reviews as one and then merged in quick succession, causing builds of the master branch in three jobs.

Some people here argue that it's easier to just create a release of Utils, then a release of Core and then Client but if it turns out the Utils code has a bug, you have to release everything again. I'm not a fan of 7 releases / day. It puts a lot of stress on the Maven Repo since it can't distinguish between "important" and "oh well" releases.