A blog site on our Real life experiences with various phases of DevOps starting from VCS, Build & Release, CI/CD, Cloud, Monitoring, Containerization.
Welcome to the first part of our blog on GitHub Actions!
This blog will delve into fundamental concepts essential for understanding GitHub Actions. Get ready to embark on a journey through the basics, paving the way for the upcoming implementation part of our blog. Stay tuned for hands-on demonstrations and practical applications in the next blog. Let’s dive in!
GitHub Actions is a powerful tool for automating software workflows, and it can be used to build, test, and deploy code right from GitHub. It provides a way to automate repetitive tasks and can be integrated with many popular tools and platforms.
GitHub Actions can use two types of runners: hosted and self-hosted.
In this tutorial, we will show you how to set up GitHub’s self-hosted runner on Kubernetes.
Prerequisites
Before you begin, make sure you have the following:
In an organization, there are multiple projects, and every project has multiple users every user has a different role to perform, based on the role whether he is owner, maintainer, developer, reporter, or guest we assign the role to that user, but the main problem is that when we have to use those users to the different project then we have to do all the same task again. There is a better way to manage users in GitLab by creating groups and assigning those groups to the project.
In GitLab, we use groups to manage one or more related projects at the same time. We can use groups to manage permissions for your projects. If someone has access to the group, they get access to all the projects in the group. We can also view all of the issues and merge requests for the projects in the group, and view analytics that shows the group’s activity. We can also create subgroups in a group.
Continue reading “Group-Based Authorization in GitLab”Triggering Jenkins builds automatically after every code commit is a core requirement in any continuous integration setup. Jenkins supports automated triggers through repository polling or event based notifications. While polling works, it consumes resources and introduces delays. Push based triggering through webhooks is far more efficient.
The difficulty appears when Jenkins is hosted inside a private network and the version control system is hosted on a cloud platform such as GitLab. In this scenario, GitLab cannot directly reach the Jenkins endpoint, making webhook based triggering difficult without exposing Jenkins publicly.
Webhook Relay solves this problem by acting as a secure bridge between GitLab and a privately hosted Jenkins server. This article explains how GitLab webhooks can trigger Jenkins jobs using Webhook Relay, based on real implementation experience.
The Webhook Relay agent needs to run on the same machine where Jenkins is hosted or where Jenkins is reachable internally.
Below is the installation process shown as step based instructions.
Webhook Relay service runs on a public endpoint, while this agent runs locally and listens for forwarded webhook events.
Create an account on the official Webhook Relay platform using the registration page shown below.
After signing up, access to the Webhook Relay dashboard is provided, where authentication tokens can be generated.
From the dashboard, create an access token. This generates a key and secret pair.
Use those credentials to authenticate the relay agent.
A successful login message confirms that the agent is connected and ready.
Create a GitLab repository for testing webhook integration. To keep the setup simple, a public repository can be used.
For reference, assume the repository name is WebhookProject.
Install the required Jenkins plugins from the plugin manager.
Navigate through the Jenkins dashboard to install
GitLab Plugin
GitLab Hook Plugin
Once installed, Jenkins becomes capable of receiving GitLab webhook events.
Create a new Jenkins job and configure it to pull source code from the GitLab repository.
Enable the option that allows Jenkins to be triggered by GitLab webhooks.
After enabling this option, Jenkins generates a webhook endpoint associated with the job. It usually follows this pattern.
Example shown for reference only.
Copy this endpoint, as it will be used in the forwarding configuration.
Start webhook forwarding by creating a relay bucket. This bucket acts as a routing channel between GitLab and Jenkins.
Important note
Do not stop this process. Keep it running in the background.
Open a new terminal tab for further steps.
Once this command starts, the relay agent generates a public forwarding URL.
Open the GitLab repository settings and navigate to the integrations or webhook section.
Paste the forwarding URL generated by Webhook Relay into the webhook URL field.
For initial testing, SSL verification can be disabled to avoid certificate related issues.
Save the webhook configuration.
Clone the GitLab repository locally and push a new commit.
As soon as the push is completed, GitLab sends a webhook event. Webhook Relay receives it and forwards it to the local agent, which triggers the Jenkins job internally.
You can verify this by checking the Jenkins job build history.
GitLab webhook logs can be viewed from
Repository settings
Integrations
Webhook edit section
Webhook Relay logs are available in the Relay Logs section of the Webhook Relay dashboard.
Jenkins build logs confirm successful job execution.
Webhook Relay makes it possible to trigger Jenkins builds through GitLab webhooks even when Jenkins is hosted inside a private network. This approach avoids exposing Jenkins publicly while still enabling real time CI automation.
The same pattern works for GitHub and other webhook enabled platforms. With proper configuration, secure and efficient CI workflows can be achieved in restricted network environments.
What we intend to do
What all we will be doing to achieve it
