Adding Continuous Integration with GitHub Actions 🛠

Introduction

With static analysis tooling and unit tests added to the project, it is time to increase the complexity of my project. At the moment, I have written several tests to check on the different functionalities of my program. However, they had to be manually run by executing "npm run test" in the terminal, which will be very tedious if there are a lot of files to test. Additionally, we also need to consider human errors, as there is no way to guarantee that all contributors remember to run the test before committing their code.

Choosing a CI

With this in mind, it is to introduce continuous integration (or CI, for short). It allows us to set up a workflow that listens to every time someone introduces new changes, builds the code, and automatically runs tests against it.

While we have many CI services, such as Azure DevOps, Evergreen, or Jenkins, I'll choose GitHub Actions for this task.

Setting up the CI

There are different options to set up GitHub Actions. You can either choose to do it manually or choose from numerous templates. My project, MINI, works just fine with the Node.js template:

# Title of the workflow
name: Node.js CI

# Trigger this workflow on push and new PR
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

# jobs to run inside this workflows
jobs:
  build:
    # choose a platform to run on
    runs-on: ubuntu-latest

    # options
    strategy:
      matrix:
        node-version: [14.x, 16.x]

    steps:
      # use a preset step to checkout the code 
      - uses: actions/checkout@v2
      # use a preset step to setup Node environment
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v2
        # preset options
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'
      # command to run
      - run: npm ci
      - run: npm test

After setting up GitHub Actions, I made two pull requests to check if it worked as intended: One containing an intentional error and the other with the same error fixed.

Writing test for others

After ensuring that the CI was working, I decided to file an issue to Tue's repo and asked if I could help him test his text to HTML conversion. We worked with each other through Slack and GitHub, with myself taking notes of what he wanted to check and what the expected results should be. After struggling with managing and rebase commits when changing the code based on Tue's review, I was able to merge my pull request.

Conclusion

I intend to use continuous integration in additional projects in the future, and it was helpful to understand how it works and how to set it up. It makes collaboration considerably easier because it prevents unintended problems and code-breaking changes.

Happy coding! 💻