GitHub Org/Repo/Branch job cannot poll multiple repos? Missing PollSCM at Org / cannot edit PollSCM at branch

[justi...@gmail.com]

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

[Stephen Connolly]

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.

--
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-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/8b67b1b4-0a4b-486f-a0e6-4f5e27d3f4b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Sent from my phone

[Justin Vallon]

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.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/8b67b1b4-0a4b-486f-a0e6-4f5e27d3f4b7%40googlegroups.com.
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 jenkinsci-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMwd9rmHPhXwH7%2BRAVUx7R67hxJfTcuQFo1Mps2pp6ZMrA%40mail.gmail.com.

[Justin Vallon]

Stephen,

This link https://github.com/jenkinsci/workflow-scm-step-plugin/blob/master/README.md#polling shows how the workflow-scm-step-plugin is supposed to interact with the "Poll SCM Plugin".  It appears the GitHub Org/branch builder is performing some of the functionality of the PollSCM Plugin, but not capturing (or responding to) all the activity on all the repos that the job actually performed.

It appears that what is missing is:

a) Being able to specify settings for BuildTrigger / Poll SCM in the Org job, or

b) Having the GitHub Org/branch be sensitive to the actual repo/branch that was used in prior builds when routing a commit hook event to appropriate rebuild jobs or

c) Being able to enable "PollSCM" in the branch job (not ideal, since those jobs are created dynamically)

What is the forum to report this?  Specifically: github-org-folder makes a branch job that does not work as expected with workflow-scm-step-plugin (when checkout poll:true); poll-scm-plugin cannot be enabled

-Justin

On Tue, Feb 28, 2017 at 6:10 PM, Justin Vallon <justi...@gmail.com> wrote:

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.

--

-Justin