Difference between revisions of "Gitea/Jenkins: Setting up Webhooks"

From Gcube Wiki
Jump to: navigation, search
(Webhook on the Gitea repository)
(Build project configuration)
 
(One intermediate revision by the same user not shown)
Line 26: Line 26:
 
* set the credentials to ''git.gcube'',
 
* set the credentials to ''git.gcube'',
 
* specify ''*/master'' as branch to build,
 
* specify ''*/master'' as branch to build,
* and in "Poll 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.
+
* 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]]

Latest revision as of 16:59, 10 June 2019

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:

JenkinsGiteaPluginConfig.png

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,
  • 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.

JenkinsSourceCodeManagement.png

Webhook on the Gitea repository

In Gitea, under repo -> Settings -> Webhooks:

  • click on "Add Webhook",
  • select "Gitea" in the drop down list

GiteaAddWebhook2.png

In the Webhook form:

GiteaWebhookConfig.png

Do note that

  1. the value of the job option is case-sensitive (in the example, gxrest instead of gxRest would fail).
  2. 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:

GitCommitBuild.png

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:

JenkinsBuild1.png


3) Clicking on the ongoing build, we can appreciate that it has been triggered by the commit:

JenkinsBuild2.png

4) Projects configured downstream will be also built if the build completes successfully.

Back to the CI guide.