I hope you got the solution, If you could suggest me the best practice it
will be helpful for me.
On Friday, 11 November 2016 09:18:12 UTC+5:30, Cory Grubbs wrote:
>
> Okstill doesn't solve the problem of having to have two separate
> Jenkins projects for every build which is not efficient
The purpose of Github project field In the Jenkins Job configuration is
just to make Github available in the Jenkins left-nav.
On 11/10/16, 7:48 PM, "jenkinsci-users@googlegroups.com on behalf of Cory
Grubbs" wrote:
Okstill doesn't solve the problem of having to have two separate Jenkins
projects for every build which is not efficient nor scalable to the level I
need it to be.
I find it hard to believe you can't configure a webhook on a github repo to
kick off a specific Jenkins job that isn't
The 1st job does not need poll. If you have Github plugin and have
configured and installed github-webhook on the source git repository on
GitHub, you enable it to trigger with Github build trigger ³Build when a
change is pushed to GitHub².
You can only associate the pipeline with the source
The whole objective is to get away from poll based CI as it places unnecessary
and unsustainable load on both the source control system and Jenkins when you
have thousands of projects continuously polling. In addition this is not a
scalable/efficient solution in that you would have to create 2
You can create a job that polls for the commit/push to the application
source repository. This job will then simply trigger the pipeline job.
On 11/10/16, 9:55 AM, "jenkinsci-users@googlegroups.com on behalf of Cory
Grubbs"
As a managed service which utilizes Jenkins for CI builds, I have created a
generic pipeline script which is used by all projects to build. The script
reads in application specific property files which drives what gets executed
within the pipeline.
The generic pipeline script and the