CI/CD – How to Use GitHub Actions to Build Pipelines? – Part 1

Author:
Innokrea Team

Date of publication: 2025-01-22

Caterogies: Administration Programming

Today, as Innokrea, we will talk to you about CI/CD and how to use GitHub’s native CI/CD solution – GitHub Actions. If you’re curious about what pipelines are and how they can be used to automate the deployment of your application, we invite you to read on. In the areas of DevOps and DevSecOps, we also recommend our articles on Terraform, CI/CD, and the previous post about SAST, DAST, and SCA.

GIT and CI/CD

GIT is software used by the vast majority of developers to manage their code. It allows the creation of software branches and the organization of developers’ work. Code is shared on a remote repository, and several companies offer such services, including GitHub, GitLab, and BitBucket. CI/CD tools (continuous integration and continuous deployment) are software solutions that allow for the automation of managing and deploying written code to clients. There are both external tools like Jenkins or CircleCI, as well as those natively integrated with remote repositories, such as GitLab CI or GitHub Actions. The automated processes within CI/CD are often referred to as workflows or pipelines, and they are usually defined in YAML format.

Pipeline code in Jenkins

Figure 1 – Pipeline code in Jenkins, where the Groovy language is used. Source: javacodegeeks.com

GitHub Actions

To understand GitHub Actions properly, we need to start by explaining a few key concepts related to this technology. These include:

Runner: An agent, server, or machine that executes our workflow. Typically, it’s a Linux server, although other systems are also available. GitHub offers hosted machines within their infrastructure or the option to connect your own, called a self-hosted runner.
Workflow: A configuration file in YAML format defining a set of tasks (jobs) to be executed. In GitHub Actions, it is saved in the .github/workflows directory.
Job: A single task executed within the workflow. It consists of several steps and typically runs on a single runner.
Step: A single action within a job, usually containing a ‘run’ block to execute a specific command on the runner.
Artifact: The result of a workflow’s execution, such as a compiled file or test report, which can be downloaded.
Secret: Private data, such as an API key, used in workflows. Secrets are stored in the repository settings and can be accessed from within the workflow.
Event: An event that triggers a workflow, such as a pull_request or push.
Matrix: A mechanism that allows running multiple versions of jobs with different parameters to avoid duplicating code.
Actions: A module that performs a specific task within a step. Examples include actions/checkout, which retrieves code from the repository, or aws-actions/configure-aws-credentials, used for authentication when deploying an app to AWS.

The pipeline definition in GitHub Actions is written using YAML and placed in the .github/workflows folder. This might look like the diagram below.

Example repository with a defined workflow

Figure 2 – Example repository with a defined workflow

Example – Express.js Project and First Workflow

Let’s try to create a simple web application project using express.js. We will use the npm package manager and GitHub Actions to demonstrate the capabilities of GitHub Actions. The application will respond to HTTP requests at the main endpoint and will be able to use environment variables provided via the workflow. All files are available for download from our public repository.

const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.send(process.env.RESPONSE_MESSAGE || 'Hello, World!');
});

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});

The pipeline responsible for installing packages (and later deploying the solution) could look as follows:

name: CI 1 Build

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18

      - name: Install dependencies
        run: npm install

Let’s take a look at the next commands that appear in the above file:

name – This is the name of the workflow, which we will be able to see in GitHub -> repository -> Actions;
on – Here, we define all the events that the workflow should react to. This means that if a specific event occurs, for example, a push to the main branch or a pull request to the main branch, the workflow will be triggered on the runner;
jobs – These are the tasks that the workflow will execute. By default, many jobs run concurrently (at the same time). To make one job wait for the result of the previous job, we use the keyword needs;
runs-on – This defines the runner, in this case, hosted by GitHub and using the Ubuntu Linux system;
steps – These define the individual steps performed within the job. In this case, it includes checking out the repository using checkout, using actions to install Node.js, and installing the packages defined in the package.json file. The steps execute sequentially, meaning one after the other.

Summary

Today, we have introduced you to the topic of GitHub Actions. If you’re curious about what more advanced operations can be performed using Actions, join us next week! See you soon!