DevOps Project Series 10 - Exploring the Powerful Features of GitHub Actions

In this article, we are going to explain how to run Github Workflows in Self hosted runners and how to schedule Cron Jobs in Github Actions and if any caches or artifacts are created in one job , then how to delete those in a scheduled manner.

Different types of runners in Github Actions :

GitHub Actions uses runners to execute the jobs in a workflow. There are three types of runners in GitHub Actions:

• Self-hosted runners: These runners can be installed and run on a developer’s own infrastructure. They can be used to run jobs on a developer’s own machines or in a private cloud. This allows developers to have full control over the environment in which their jobs run, and to use specialized tools or configurations that may not be available on the GitHub-hosted runners.
• GitHub-hosted runners: These runners are provided and managed by GitHub. They run on GitHub’s infrastructure, and are available for Linux, Windows, and macOS environments. They provide a convenient way for developers to run jobs without the need to manage their own infrastructure.
• Third-party runners: These runners are provided by third-party providers and can be used to run jobs in specialized environments or using specialized tools. They can be used to run jobs on cloud providers, such as AWS or GCP, or to run jobs on specialized hardware, such as GPUs.

Additionally, GitHub Actions also provides the option to run actions in Kubernetes using GitHub Actions for Kubernetes, that allows to run actions inside a Kubernetes cluster, this allows to scale and manage the resources used by the actions.

Each type of runner has its own advantages and use cases, and developers can choose the type of runner that best suits their needs.

Use Case 1 : How to execute workflows in Self-hosted runner ?? 

Go to Settings –> Actions –> Runner –> New self-hosted runner

Then run the below commands to start the service

Add all the values when asking about Runner Registration.

To connect to the Runner we need to start the run.sh file

We can see that the runner is up and running now.

If you want to configure the self-hosted runner application as a service so that the runner is up and running if your Linux machine is up and running

Run these commands :

Installing the service

1. Stop the self-hosted runner application if it is currently running.
2. Install the service with the following command: sudo ./svc.sh install3.
3. Alternatively, the command takes an optional user argument to install the service as a different user../svc.sh install USERNAME 

Starting the service

Start the service with the following command: sudo ./svc.sh start

Checking the status of the service

Check the status of the service with the following command: sudo ./svc.sh status

Assign the runner to the workflow: In your workflow file, you can specify which runner should be used to execute a job by using the runs-on key in the job’s definition. For example:

Use the labels that you have assigned to your runner you used while installing self-hosted runner in your EC2 Instance.

Use Case 2 : How to schedule Cron Jobs in Github Actions Workflow ??

To schedule a Cron Job in a GitHub Actions workflow, you will need to perform the following steps:

• Create a workflow: First, you will need to create a new workflow in your GitHub repository. This can be done by creating a .yml file in the .github/workflows directory of your repository.
• Add a schedule trigger: Next, you will need to add a schedule trigger to the workflow. This can be done by adding the following to the on section of the workflow:

The schedule trigger uses a cron expression to define when the workflow should run. You can use the cron schedule syntax to set the schedule.

• Define the jobs: Next, you will need to define the jobs that should be run as part of the scheduled workflow. This can be done by adding a jobs section to the workflow and specifying the steps that should be run.
• Start the workflow: Once the workflow is defined, it will start running according to the schedule specified. You can check the status of the scheduled workflow in the Actions tab on the repository on GitHub.
• It’s important to note that GitHub Actions allows for multiple schedule trigger, this means that you can set different schedules for different jobs, or for different branches on the repository.

Additionally, there are other triggers available such as webhooks, pull request, and pushes, that allows you to create workflows that run based on different events and conditions.

Use Case 3 : If you want to delete the build artifacts which are formed in SpringBoot workflow (build job) and also clear Caches using cron job — Every 3 days

Here the first job is to Delete Artifacts which are getting created at the SpringBoot workflow in build job and the second job is to delete the Caches which gets created in workflow steps. This workflow will be running every 3rd day in a month.