Until now, the created builds have had to be triggered manually.
One of the simplest ways to trigger builds is to poll the source repository for changes.
To enable source repository polling:
- Select a job to open the job detail page
- Select
Configure
in the left nav to open the job configuration page - Under
Build Triggers
, selectPoll SCM
to show the poll schedule section - Under
Poll SCM
, enter aSchedule
in cron syntax (e.g.*/5 * * * *
for every 5 minutes)
- TODO: Github Rate Limit?
- Select
Save
to confirm changes and return to the job detail page
The job will now automaticaly trigger within 5 minutes after pushing a new commit to the configured source repository.
SCM Polling is definitely the most reliable and flexible way to trigger builds, but it's also a slow and causes unnecessary traffic, which may count against your GitHub rate limit.
A more responsive alternative is to use webhooks. With webhooks, the source repository needs to be configured to know how to reach Jenkins. It then triggers immediate job execution whenever it relieves a new commit. While this is almost always better, it does require that Jenkins be publicly accessible, which comes with its complications and security risks.
Enabling webhooks requires that Jenkins be accessible by GitHub without having to log into DC/OS.
The normal method to enable this is to use Marathon-LB Virtual Hosts, which exposes a DC/OS service on an externally accessible web domain. Unfortunately, we don't have any domains available for this lab. So we'll have to improvise.
Before making Jenkins publically accessible, it's probably a good idea to improve security first. If that's important to you, skip ahead to DC/OS 105 - Security, set up Jenkins security, and come back.
To make Jenkins accessible on the public agent node:
-
Install Marathon-LB
-
Export the current Jenkins service definition:
dcos marathon app show jenkins > jenkins.json
-
Edit
jenkins.json
:-
Remove status-only fields:
tasks
version
versionInfo
-
Remove conflicting deprecated fields:
fetch
-
Lookup the allocated ports:
$ JENKINS_1_PORT=${cat jenkins.json | jq .portDefinitions[0].port} $ JENKINS_2_PORT=${cat jenkins.json | jq .portDefinitions[1].port}
-
Add labels to configure Marathon-LB's reverse proxy:
"labels": { ... "HAPROXY_GROUP": "external", "HAPROXY_0_PORT": "${JENKINS_1_PORT}", "HAPROXY_1_PORT": "${JENKINS_2_PORT}", }
-
-
Update the Jenkins service:
dcos marathon app update jenkins < jenkins.json
Once the service deployment has completed, Jenkins should be accessible via HTTP on the public agent node IP using the first port from above. The second port is for HTTPS, which we haven't set up yet.
To enable webhooks in GitHub:
- Navigate to the source repository in GitHub (e.g. https://github.com/karlkfi/minitwit)
- Select
Settings
in the top nav to open the settings page - Select
Webhooks
in the left nav to open the webhooks page (may require re-authentication) - Under
Payload URL
, enter the webhook url with the patternhttp://${DCOS_ADDRESS}/service/${JENKINS_SERVICE_NAME}/ghprbhook/
- Select
Let me select individual events.
to show the event section - Select
Pull request
andIssue comment
and deselect all other events - Select
Add Webhook
to confirm the webhook configuration
TODO: ghprbhook or github-webhook? https://thepracticalsysadmin.com/setting-up-a-github-webhook-in-jenkins/ https://www.fourkitchens.com/blog/article/trigger-jenkins-builds-pushing-github
TODO: Uncheck Prevent Cross Site Request Forgery exploits
?
To enable webhooks in Jenkins:
Build Configuration
- Navigate to the Jenkins build configuration page
- Select
Build when a change is pushed to GitHub
System Configuration
- Under
GitHub Pull Request Builder
- Next to
Credentials
, selectAdd
andJenkins
(credential provider) to open the Jenkins Credentials Provider screen - Next to
Kind
, selectsecret text
to show the secret token section - For
Secret
, enter your GitHub personal access token TODO: generate instructions - For
ID
, enter something descriptive to identify the credentials (e.g.karlkfi github token
) - Select
Add
to confirm credentials creation and return to the settings page - From the
Credentials
dropdown, select the newly created credentials (byID
) - Select
Apply
to confirm the settings changes
Validate System Configuration
-
Under
GitHub Pull Request Builder
-
Select
Test basic connection to GitHub
to show the connection test section -
Select
Connect to API
to validate the GitHub credentials -
Verify that the response text is not a red error
-
Navigate to the Jenkins build configuration page
-
Under
Build Triggers
, selectBuild when a change is pushed to GitHub
Public Jenkins Access
In order for Jenkins to be reachable by GitHub, it must be publicly accessible.
To configure the Jenkins DC/OS service to use Marathon-LB:
-
Switch to bridge networking with random container/host ports and fixed service ports:
"container": { ... "docker": { ... "portMappings": [ { "hostPort": 0, "containerPort": 80, "servicePort": 8080, "protocol": "tcp", "name": "http" }, { "hostPort": 0, "containerPort": 443, "servicePort": 8081, "protocol": "tcp", "name": "https" } ], "network": "BRIDGE" } }
-
Enable require ports: TODO: why?
"requirePorts": true
-
Label the service as external:
"labels": { ... "HAPROXY_GROUP": "external" }
TODO: Webhooks (require a domain?)
Checkpoints (CloudBees paid feature): https://go.cloudbees.com/docs/cloudbees-documentation/cje-user-guide/chapter-workflow.html?q=checkpoints
Plugin: GitHub Pull Request Plugin
Integrations & services
:
Jenkins (GitHub plugin
http://ec2-52-37-28-43.us-west-2.compute.amazonaws.com/service/jenkins/github-webhook/