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. CI/CD 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 Prerequisites Have a GitHub account
Basic understanding of YAML syntax and GitHub 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. .github pylinter.yml 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. main name: Python Linting

on:
  push:
    branches: main
  pull_request:
    branches: main 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. pylint 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 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. pylint 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. pylint --disable=all C0116 W0311 --max-line-length=100 You can check out the full list of pylint codes and what they do here. pylint Your pylint config should look like this: pylint - name: Run PyLint
      run: |
        pylint --disable=all --enable=C0116,W0311 --max-line-length=100 $(git ls-files '*.py') - 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. main 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. If the pipeline fails, you’ll see a red dot next to the workflow. If it passes, it turns green. If the pipeline fails, you’ll see a red dot next to the workflow. If it passes, it turns green. 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. main.py main def some_function():
    """
    Description of what this function does.
    
    Returns:
        Type: Description of what is returned
    """
    pass 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. pylint 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!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

How to Setup a CI/CD Pipeline with GitHub Actions

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

104 Stories To Learn About Continuous Integration

139 Stories To Learn About Cicd

15 of the Best Continuous Delivery Tools

5 Best Microservices CI/CD Tools You Need to Check Out

53 Stories To Learn About Continuous Deployment

104 Stories To Learn About Continuous Integration

139 Stories To Learn About Cicd

15 of the Best Continuous Delivery Tools

5 Best Microservices CI/CD Tools You Need to Check Out

53 Stories To Learn About Continuous Deployment

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps