Integrating CI Workflow in my project

Lab

I had to integrate GitHub Actions into my project this week to automatically run linting and unit test scripts whenever a new PR and/or a new push is added to my project.

Successful GitHub Actions Run

https://github.com/sdthaker/Node-TILify/actions/runs/6857717308

PR on another project's repo

https://github.com/Yousef-Majidi/Learn2Blog/pull/33

Feature Implementation

GitHub Actions can be used for building a piece of software or aid in deploying it. They are set up within a root folder called .github containing a folder called workflows. For example, if we take a look at the project I worked on, it has a lint-test.yml file located within /.github/workflows which defines a workflow of what it's supposed to do.

A workflow is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked into a repository which can be given a name, which in this case is name: Lint and Test and will run when triggered by an event in the repository, which in this case is,

on:
  push:
    branches: [ "master" ]
  pull_request:
    branches: [ "master" ]

A job is a set of steps in a workflow that is executed on the same runner. Each step is either a shell script that will be executed or an action that will be run. Steps are executed in order and are dependent on each other. When a new PR is created or a push is performed, this workflow will run with 2 jobs namely lint & test.

This was the entire workflow I added to the existing build workflow,

Breaking down the lint job:

• lint:: This is the name of the job. It's used to identify the job in the GitHub Actions UI.

• timeout-minutes: 5: This sets a timeout for the job. If the job runs for longer than 5 minutes, it will be automatically cancelled.

• runs-on: ubuntu-latest: This specifies the type of runner that the job will run on. In this case, it's the latest version of Ubuntu.

• steps:: This is a list of steps that the job will execute. Each step is an individual task that contributes to the job.

  • uses: actions/checkout@v2: This step uses the checkout action at version 2 to checkout the repository's code onto the runner.
  • name: Setup node: This step sets up a Node.js environment on the runner. It's given the name "Setup node" for clarity in the GitHub Actions UI.
  • uses: actions/setup-node@v3: This uses the setup-node action at version 3 to set up the Node.js environment.
  • with:: This is used to pass parameters to the setup-node action.
    • node-version: 18: This specifies that the Node.js version to be set up should be version 18.
  • name: Npm Install: This step installs the npm packages required for the project. It's given the name "Npm Install" for clarity in the GitHub Actions UI.
  • run: npm install: This runs the command npm install to install the npm packages.
  • name: Lint: This step checks the format of the code. It's given the name "Lint" for clarity in the GitHub Actions UI.
  • run: npm run lint: This runs the command npm run lint to check the format of the code.

Now that I integrated GitHub Actions in the repository, it was a pretty good exercise for me considering I've only done it once, helping me solidify my learnings from my previous contribution during 0.3 release. Automating tasks like build, test, lint, and format among other tasks using a CI workflow makes sure that key tasks are taken care of before the code gets deployed to the production because when running these tasks manually, developers tend to forget to run them. Besides, this improves DX and more and more developers would like to contribute to a project when you have this automation because mundane tasks like these are already taken care of.

Working in partnership

My partner's repo used an entirely different language/framework, one that I have never worked on before; Dot net. The instructions were quite simple to set up the project and to run tests and he also helped me with setting up dot net on my computer considering I have a Mac. Writing tests however were somewhat challenging considering I've never worked with C# but I used one of the other test file within the project as a reference to write test code and also to fix the errors. Besides, there was a weird bug I received while writing the test. The test I wrote checked whether the correct HTML string was returned by a function. The repo maintainer wrote this code on a Windows machine where the new lines are treated differently than those on Mac. After a bit of digging through my unit test code, I realized that this was the issue so to test the code I removed all the new lines from the code I didn't write and added them back after which it passed the test. I issued a PR and the pipeline automatically triggered, but considering this project was developed on Windows and I have a Mac, it gave the CRLF vs LF error for the string I wrote. I informed the repo owner about this and he said he'll fix this by removing the end lines and re-adding them from his machine. The PR is open at the time of writing this blog. This task gave me great exposure to work on another project which I didn't write along with a language/framework that I've never worked on before.