How to Setup a CI/CD Pipeline with GitHub Actions

Let’s be real, tech moves fast. New frameworks, tools, and best practices seem to pop up every other week. It’s exciting, but also a bit overwhelming. If you’re trying to build and ship projects while keeping up with everything, it can feel like a lot.

That’s where CI/CD, short for Continuous Integration and Continuous Deployment, can help. It takes care of the repetitive stuff like testing and deploying, so you can focus on writing actual features. I’ve personally found GitHub Actions to be a solid choice for setting up CI/CD workflows right inside a GitHub repo.

In this article, I’ll walk you through how to set up a simple CI/CD pipeline using GitHub Actions. The goal is to reduce manual errors, make our code easier to deploy, and save some time and stress in the process.

Let’s get into it!

Before we start, here are a few things you’ll want to have or know, just so you don’t get stuck halfway through.

Prerequisites

• Have a GitHub account
• Basic understanding of YAML syntax and GitHub

Creating Your First CI/CD Pipeline

You can choose to create your YAML file in VS Code or directly on GitHub. In this guide, we’ll create it directly on GitHub to keep things simple and easy to follow.

Go to your GitHub repository (or open your code editor) and create a new folder named .github Inside that, create another folder called workflows, and then add a new file named pylinter.yml You can name your YAML file whatever you like.

Next, we need to define our YAML file, which is a linter workflow that checks for docstrings in our codebase.

Start your YAML file by giving your pipeline a name and setting up the Git trigger — in other words, defining when you want the pipeline to run. In this guide, we’ll set it up to run whenever there’s a push to the main branch or when a pull request is opened against it.

name: Python Linting

on:
  push:
    branches: main
  pull_request:
    branches: main 

Next, we need to tell the pipeline what to do when a push or pull request happens. In this case, we want it to review our code by setting up Python and installing the pylint package so it can run a linting check on our repository.

jobs:
  lint:
    name: Run PyLint
    runs-on: ubuntu-latest
    
    steps:
    - name: Check out repository
      uses: actions/checkout@v3

    - name: Set up Python
      uses: actions/setup-python@v4
      with:
        python-version: '3.11'

    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install pylint

After setting up Python and installing the pylint package, the next step is to define the configuration that pylint will use during the pipeline run.

We’ll start by disabling all of pylint’s default checks using --disable=all, which gives us a clean slate. Then, we’ll enable just two specific checks: C0116 (which flags missing function docstrings) and W0311 (which highlights bad indentation). We’ll also set --max-line-length=100 to allow for longer lines of code while still keeping things readable.

You can check out the full list of pylint codes and what they do here.

Your pylint config should look like this:

 - name: Run PyLint
      run: |
        pylint --disable=all --enable=C0116,W0311 --max-line-length=100 $(git ls-files '*.py')

And that’s it — you’ve just created your first pipeline workflow! Make sure your project structure matches what we’ve covered in this guide, as any differences might prevent the pipeline from running correctly. Once everything is set up, commit your changes and push them to the main branch.

Once you have committed your workflow, you should see a yellow dot next to your commit message. This signifies that your pipeline is up and running.

Next, let's add a Python file to test the workflow and check if it correctly flags missing docstrings. Click on 'Add file,' then 'Create new file,' and name it main.py. Once you've added your code, commit the file and push it to the main branch.

def some_function():
    """
    Description of what this function does.
    
    Returns:
        Type: Description of what is returned
    """
    pass 

Testing the Pipeline

To test the pipeline we just created, click on GitHub actions. You should see all your workflows. Click on the workflow to see more details.

Now, let's break down how the workflow was triggered and what happened next. Click on Run PyLint to view the detailed results.

The pipeline works by setting up a job that first checks out your repository, then sets up Python 3.11 (as specified in our YAML file). It installs the necessary dependencies and runs the pylint configuration script. Once the script passes, the pipeline sets up Python again and checks the repository one more time to make sure everything is working correctly before completing the job.

In summary, when you create a pipeline, GitHub will automatically run your configured checks (in this case, pylint) on your code whenever you commit to the main branch or make a pull request. This helps catch errors early in the development process.

Wrapping Up

As we wrap up this guide on GitHub Actions, it’s clear that using this practice can seriously supercharge your development process. By automating checks to make sure your code is running smoothly, you’ll save tons of time and avoid bugs when pushing code to production.

That’s the real power of GitHub Actions — its flexibility. It lets you build workflows that are tailored to your project’s needs. Whether you're flying solo as an indie developer or working within a team, CI/CD helps you ship features faster and build a better product.

So, go ahead and convince your team lead to integrate CI/CD into your company’s workflow. Watch your team start shipping better code, faster!