Skip to main content
In this guide, we will configure a simple CI/CD pipeline using GitHub Actions. Before you begin, make sure you have these resources open for reference:
  • GitHub Actions documentation (especially the Quick Start and Reference pages)
  • GitHub Marketplace to explore available actions
  • The example tutorial for setting up a CI/CD pipeline for a Python application, which inspired this workflow
Below, you’ll find an example of a Python package workflow that gives a good starting point:
This example illustrates the basic use of GitHub Actions. In the following sections, we will cover the steps to set up and customize your workflow.

Creating the Workflow Directory

As detailed in the GitHub Actions documentation, you need to create a specific folder structure in your project. This structure includes a .github folder that contains a workflows subfolder, where all your YAML workflow files reside.
The image shows a webpage from GitHub Docs titled "Quickstart for GitHub Actions," providing instructions on creating a workflow with a sample YAML code snippet. The page includes a sidebar with navigation links related to GitHub Actions.
Within your project directory, follow these steps:
  1. Create a folder named .github.
  2. Inside .github, create another folder called workflows.
This directory will house your workflow definitions. Although you can set up multiple pipelines, this guide will use a single workflow for simplicity.

A Quick Overview of Pytest Fixtures

Here is an example of a Pytest fixture used in our testing setup. Duplicate occurrences of this code block have been removed to avoid redundancy:
Console output example:
The Pytest fixture shown above resets the database before running tests, ensuring a clean state for each test session.

Creating a Simple GitHub Actions Workflow

GitHub Actions workflows are defined using YAML. Below are two examples that demonstrate basic workflow configurations.

Basic Workflow Example

Running One-Line and Multi-Line Scripts

To activate your workflow, create a new file named build-deploy.yaml inside your .github/workflows folder and paste your configuration there. While the file name is arbitrary, remember to specify the workflow’s name within the YAML file using the name key.

Configuring Workflow Triggers

Workflow triggers define when your workflow will run. For example, to run on both push events and pull requests across all branches, use:
To restrict the workflow to specific branches, you can adjust the configuration as follows:
This configuration ensures that the workflow runs only for pushes and pull requests on the specified branches. For additional details, refer to the GitHub Actions events documentation.
The image shows a GitHub documentation page about triggering workflows with scheduled events, including details on using cron syntax.

Defining Jobs and Steps

In GitHub Actions, a job represents a series of steps executed on a runner (a virtual machine). The workflow below breaks down a simple job configuration:
  1. Specify the operating system for the runner with the runs-on field (e.g., ubuntu-latest).
  2. Define the steps to execute, each with a descriptive name.
Refer to the GitHub Actions documentation for more details on available runners, such as Windows and macOS. In this guide, we use Ubuntu since our production environment runs on Linux.
The image shows a webpage from GitHub Docs about GitHub Actions, featuring a diagram of components like events, jobs, and runners, along with explanatory text on workflows, events, jobs, steps, and actions.
Below is an example of a job with two straightforward steps:
In this example:
  • The first step checks out the repository using a pre-built action available on the GitHub Marketplace.
  • The second step executes an echo command on the Linux runner.
For more advanced checkout options (e.g., specifying a branch or using SSH), refer to the actions/checkout documentation.
The image shows a GitHub page detailing the usage instructions for the "actions/checkout" action, including configuration options like repository, branch, and personal access token. The browser window displays multiple open tabs and a visible taskbar at the bottom.

Committing and Viewing Your Workflow

After saving your workflow file (for example, build-deploy.yaml) in the .github/workflows directory, commit your changes to your Git repository using these commands:
Once pushed, navigate to the “Actions” tab in your GitHub repository. You will see an entry corresponding to your commit (e.g., “adding first GitHub action”). Click the entry to view the detailed job log, which displays each executed step.
The image shows a GitHub Actions interface with a job log for a workflow titled "adding first github action Build and Deploy Code #10." The log details various steps such as setting up the job, pulling the git repository, and completing the job.
Key highlights from the job log include:
  • Launching a runner (a virtual machine) with the specified operating system.
  • Checking out the repository using the configured action.
  • Executing a custom echo command to validate the step.

Final Thoughts

This simple CI/CD pipeline demonstrates how GitHub Actions can automate tasks such as checking out code, running tests, and executing custom commands on a Linux runner. While GitHub Actions offers free build minutes on their hosted solution, you might consider self-hosted runners if your usage needs increase.
By now, you should have a clear understanding of how to configure your first GitHub Actions workflow and trigger it using pushes or pull requests. Feel free to customize and extend this setup to match your project requirements.
Happy Coding!

Watch Video