I'm talking about PollSCM that enables incoming commit-hooks to trigger the
launching of jobs, not "poll scm every 5 minutes".
If the Jenkinsfile does an explicit checkout, can't the job record the
dependent URLs, and rescan those? I am not asking for a general
configuration solution at the job level, but if, like a
Pipeline+Jenkinsfile job, the script does checkout additional URLs, then
let that job be dependent on those checkouts.
My sample would be:
libA {
checkout self
build
}
appB {
checkout self
checkout libA on master branch
}
Pull requests on libA would build the new libA. Merge to master would
trigger appB to rebuild since it (previously) pulled from libA/master.
The problem with triggering downstream builds is that libA might be used in
appB, appC, libD, appE. The dependency of appB on libA is present in appB;
inverting that dependency by moving it to libA creates a maintenance
problem.
MultiSCM rebuilding (appB) works with Pipeline + Jenkinsfile. Commit in
appB (branch or master) or libA (master) triggers rebuild of appB.
On Tue, Feb 28, 2017 at 4:07 PM, Stephen Connolly <
[email protected]> wrote:
> Multibranch is designed to remove the need for individual jobs to poll.
>
> When a scan is performed, we get - in one set of requests - all the head
> revisions and then trigger builds for all branches with changes. This
> reduces the impact of many jobs polling. Additionally events are
> consolidated on a single path meaning that jobs get triggered without
> needing a scan at all and with only verification of the event details.
>
> The down-side (currently) is that we do not have a good solution for where
> you want to check out multiple sources. This in part reflects some of the
> difficulties involved. For one, there is the question of how to align
> branches:
>
> * do you always check out the "master" branch of the second repository?
>
> * do you always check out the same named branch?
>
> * do you check out the same named branch and fall back to the master
> branch if there is no matching one?
>
> * what about more complex flows like with git flow?
>
> * it is highly unlikely that PRs against different repos will get the same
> number, how do you determine the branch to use for PRs
>
> And that is just the start of the problem.
>
> Right now my recommendation is to use a Jenkinsfile in the second repo
> that just triggers the build in the first repo. That way the commit against
> the second repo will trigger a build of your main job that checks out the
> primary and secondary repos.
>
> On Tue 28 Feb 2017 at 16:45, <[email protected]> wrote:
>
>> I am able to create a Pipeline job, and have the job do a git clone of
>> two repos. When there are commits in either repo, the job is triggered.
>>
>> However, I cannot get this to work with GitHub Org Folder / Repo /
>> Branch. The job is only triggered when the repo/branch is modified,
>> despite it checking out other repos.
>>
>> I also noticed that in the GitHub Org job, there is no "PollSCM" in the
>> top-level GitHub Org job. However, in the repo/branch job, there is a
>> "PollSCM", but the configuration of the job is read-only. In order for the
>> Pipeline build to work with multiple repos, then "PollSCM" option must be
>> enabled.
>>
>> I would like to be able to do this:
>>
>> https://github.com/user/mylib - builds a library
>> https;//github.com/user/myapp - builds an app
>>
>> myapp/Jenkinsfile:
>> dir("mylib") { git "https://github.com/user/mylib"; }
>> dir("myapp") { git "https://github.com/user/myapp"; }
>> sh 'do-build'
>>
>> Then, have the myapp job get triggered when there is a commit in either
>> mylib or myapp.
>>
>> I have tried with a fresh download of Jenkins and up-to-date plugins.
>> Details available upon request...
>>
>> -Justin
>>
>> --
>> 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 [email protected].
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/jenkinsci-users/8b67b1b4-0a4b-486f-a0e6-
>> 4f5e27d3f4b7%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-users/8b67b1b4-0a4b-486f-a0e6-4f5e27d3f4b7%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> Sent from my phone
>
> --
> 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 [email protected].
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-users/CA%2BnPnMwd9rmHPhXwH7%2BRAVUx7R67hxJfTcuQFo1Mps2pp6Z
> MrA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMwd9rmHPhXwH7%2BRAVUx7R67hxJfTcuQFo1Mps2pp6ZMrA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/CAGvUWmEqJsohjwHOqv21CevD_jSyi_CuydunU9MXkAfpDb4REA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
