CI using GitHub Actions

Continuous Integration using GitHub Actions

Continuous integration (CI) is a software practice that requires frequently committing code to a shared repository. Committing code more often detects errors sooner and reduces the amount of code a developer needs to debug when finding the source of an error. Frequent code updates also make it easier to merge changes from different members of a software development team. This is great for developers, who can spend more time writing code and less time debugging errors or resolving merge conflicts.

When we commit code to our repository, we can continuously build and test the code to make sure that the commit doesn't introduce errors. Our tests can include code linters (which check style formatting), security checks, code coverage, functional tests, and other custom checks.

Building and testing your code requires a server. You can build and test updates locally before pushing code to a repository, or you can use a CI server that checks for new code commits in a repository.

CI using GitHub Actions offers workflows that can build the code in our repository and run our tests. Workflows can run on GitHub-hosted virtual machines, or on machines that we host ourselves.

We can configure our CI workflow to run when a GitHub event occurs (for example, when new code is pushed to the repository), on a set schedule, or when an external event occurs using the repository dispatch webhook.

GitHub runs CI tests and provides the results of each test in the pull request, so we can see whether the change in our branch introduces an error. When all CI tests in a workflow pass, the changes we pushed are ready to be reviewed by a team member or merged. When a test fails, one of our changes may have caused the failure.

Key advantages of using GitHub Actions for CI/CD pipelines

But first, let’s talk through some of the benefits to using GitHub Actions—because let’s be honest, there are a lot of other tools out there. Let me unpack the four big benefits that I’ve come across:

• CI/CD pipeline set-up is simple: GitHub Actions is made by and for developers, so you don’t need dedicated resources to set up and maintain your pipeline. There’s no need to manually configure and set up CI/CD. You don’t have to set up webhooks, you don’t have to buy hardware, reserve some instances out there, keep them up to date, do security patches, or spool down idle machines. You just drop one file in your repo, and it works.

• Respond to any webhook on GitHub: Since GitHub Actions is fully integrated with GitHub, you can set any webhook as an event trigger for an automation or CI/CD pipeline. This includes things like pull requests, issues, and comments, but it also includes webhooks from any app you have integrated into your GitHub repository. Let’s say you’re going to use any one of the many tools that are out there to run part of your development pipeline. With GitHub Actions, you can trigger CI/CD workflows and pipelines of webhooks from these apps (even something simple, like a chat app message, if you’ve integrated your chat app into your GitHub repository, of course).

• Community-powered, reusable workflows: You can share your workflows publicly with the wider GitHub community or access pre-built CI/CD workflows in the GitHub Marketplace (there are more than 11,000 available actions!). Did I mention every action is reusable just by referencing its name? Yes, that too.

• Support for any platform, any language, and any cloud: GitHub Actions is platform agnostic, language agnostic, and cloud agnostic. That means you can use it with whatever technology you choose.

How to build a CI/CD pipeline with GitHub Actions

Before we dive in, here are a few quick notes:

Be clear about what a CI/CD pipeline is and should do. This is a simple note, but important. A CI pipeline runs when code changes and should make sure all of our changes work with the rest of the code when it’s integrated. It should also compile our code, run tests, and check that it’s functional. A CD pipeline goes one step further and deploys the built code into production.

Step 1: Set Up GitHub Actions Workflow

Create a .github/workflows directory in the root of your Django project. Inside the workflows directory, create a YAML file, for example, ci.yml. This file will define your GitHub Actions workflow.

name: Django CI

on:
  push:
    branches:
      - rent_sanzida

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v2

      - name: Set Up Python
        uses: actions/setup-python@v2
        with:
          python-version: 3.x

      - name: Install Dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      - name: Run Tests
        run: |
          cd BharaHobe
          python manage.py test

Step 2: Generate requirements.txt file

Generate a requirements.txt file (if not present) in the project folder using:

pip freeze > requirements.txt

In the requirements.txt file, keep the library or package names that are needed for the corresponding project.

Step 3: Commit and Push Changes

Add the new workflow file and any changes you made to include the monthly and advance payment tests.

git add .
git commit -m "commit message"
git push origin <branch-name>

Step 4: Monitor GitHub Actions

Go to your GitHub repository and navigate to the "Actions" tab. You should see the GitHub Actions workflow running. If everything is set up correctly, the workflow will run your tests on each push to the corresponding branch.

References:

• GitHub Actions Documentation
• GitHub Blog - Building a CI/CD Pipeline with GitHub Actions
• Medium - CI/CD Pipeline with GitHub Actions