Difference between revisions of "Gitea/Jenkins: Setting up Webhooks"
Manuele.simi (Talk | contribs) (→Gitea Plugin on Jenkins) |
Manuele.simi (Talk | contribs) (→Build project configuration) |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 24: | Line 24: | ||
* set option to "Git", | * set option to "Git", | ||
* provide URL to your repo (e.g. https://code-repo.d4science.org/gCubeSystem/gxRest.git), | * provide URL to your repo (e.g. https://code-repo.d4science.org/gCubeSystem/gxRest.git), | ||
| − | * set the credentials to ''git.gcube'', | + | * set the credentials to ''git.gcube'' (only if the repository is NOT public), |
* specify ''*/master'' as branch to build, | * specify ''*/master'' as branch to build, | ||
| − | + | ||
| + | and in "Build Triggers" section: | ||
| + | * check "Poll SCM" option with no schedule defined. This setup basically tells Jenkins to poll your Gitea repo only when requested via the webhook. | ||
[[File:JenkinsSourceCodeManagement.png|1000px]] | [[File:JenkinsSourceCodeManagement.png|1000px]] | ||
| Line 40: | Line 42: | ||
In the Webhook form: | In the Webhook form: | ||
| − | * set the URL to <code> | + | * set the URL to <code>https://jenkins.d4science.org/gitea-webhook/post?job=project</code>, where ''project'' is the name of the project in Jenkins to build, |
* set post content type to "application/json", | * set post content type to "application/json", | ||
* check "Push Events" for the ''Trigger On'' option, | * check "Push Events" for the ''Trigger On'' option, | ||
| Line 47: | Line 49: | ||
[[File:GiteaWebhookConfig.png|1000px]] | [[File:GiteaWebhookConfig.png|1000px]] | ||
| − | Do note that the value of the job option is case-sensitive (in the example, ''gxrest'' instead of ''gxRest'' would fail). | + | Do note that |
| + | # the value of the job option is case-sensitive (in the example, ''gxrest'' instead of ''gxRest'' would fail). | ||
| + | # HTTPS is needed to send a POST request | ||
At this point clicking on "Test Delivery" button should produce a successful delivery attempt (green checkmark, as shown in the figure). | At this point clicking on "Test Delivery" button should produce a successful delivery attempt (green checkmark, as shown in the figure). | ||
| Line 76: | Line 80: | ||
''Back to the [[Continuous_Integration_procedure_(2019) | CI guide]].'' | ''Back to the [[Continuous_Integration_procedure_(2019) | CI guide]].'' | ||
| + | |||
| + | [[Category:Continuous_Integration]] | ||
Latest revision as of 17:51, 30 November 2019
Contents
What is a webhook?
A webhook is a mechanism to automatically trigger the build of a Jenkins project upon a commit pushed in a Git repository.
This guide details the steps to have Jenkins automatically create a build if it detects changes to a Gitea repository. This can be a very useful improvement to continuous integration setup with Jenkins because this method is only telling Jenkins to attempt a new build when a change is detected rather than polling on an interval, which can be a very inefficient.
Gitea Plugin on Jenkins (only for Jenkins admins)
This plugin allows to configure Jenkins to talk to Gitea.
Installation
In Jenkins: download and install the Gitea plugin in Jenkins.
Go in the page: Manage Jenkins -> Manage Plugins -> Available -> Gitea plugin
And install the plugin.
Configuration
Go in the page: Manage Jenkins -> Configure System -> Gitea Servers:
Build project configuration
In Jenkins, under the project settings page "Source Code Management":
- set option to "Git",
- provide URL to your repo (e.g. https://code-repo.d4science.org/gCubeSystem/gxRest.git),
- set the credentials to git.gcube (only if the repository is NOT public),
- specify */master as branch to build,
and in "Build Triggers" section:
- check "Poll SCM" option with no schedule defined. This setup basically tells Jenkins to poll your Gitea repo only when requested via the webhook.
Webhook on the Gitea repository
In Gitea, under repo -> Settings -> Webhooks:
- click on "Add Webhook",
- select "Gitea" in the drop down list
In the Webhook form:
- set the URL to
https://jenkins.d4science.org/gitea-webhook/post?job=project, where project is the name of the project in Jenkins to build, - set post content type to "application/json",
- check "Push Events" for the Trigger On option,
- clear the secret (leave it blank).
Do note that
- the value of the job option is case-sensitive (in the example, gxrest instead of gxRest would fail).
- HTTPS is needed to send a POST request
At this point clicking on "Test Delivery" button should produce a successful delivery attempt (green checkmark, as shown in the figure).
If the test deliveries fail, try to see if you can POST to Jenkins webhook URL (http://jenkins.d4science.org/gitea-webhook/post). E.g. using Postman or with curl:
curl -vvv -H "Content-Type: application/json" -H "X-Gitea-Event: push" -X POST http://jenkins.d4science.org/gitea-webhook/post -d "{}"
Correct response should be just plain "Processed" string. If you get something else, post it here.
Testing the Gitea/Jenkins round trip
1) We push a new commit with a message "Update README.md" in the Gitea repository:
2) If the webhook has been properly set up, on the Jenkins interface we should see that the build of the linked project has started:
3) Clicking on the ongoing build, we can appreciate that it has been triggered by the commit:
4) Projects configured downstream will be also built if the build completes successfully.
Back to the CI guide.
