Adding CI through GitHub Actions
Published: 2021-11-19 17:36:43

Last week, I added some tests to [cli-ssg](https://github.com/dhillonks/cli-ssg) using `jest`, but right now the only way to run them is to run them manually. While this works, having an automated process in place to run the tests would be much better, as that would mean that any change that breaks the tests, cannot be merged.

Thus, this week I added CI (Continuous Integration) to `cli-ssg`, through which tests are automatically ran whenever anything is pushed to the repo, or a new pull request is made.

## GitHub Actions
GitHub's CI service is called [GitHub Actions](https://github.com/features/actions) and these allow us to create workflows to automate processes in a GitHub repo.

Since `cli-ssg` is `Node.js` based, it already had a suggested workflow for me when I went to add one. After going through it and making sure that the tests would be triggered on any pushes to `main` or any pull requests to `main`, this is how the `yaml` file looked like:
```yaml
name: Node.js CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [12.x, 14.x, 16.x]
        # See supported Node.js release schedule at https://nodejs.org/en/about/releases/

    steps:
    - uses: actions/checkout@v2
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v2
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm test
```

## Testing the CI
Since the workflow was now setup, it was now time to test it! I started by adding a few more tests to `configOptions`. I added tests to cover the default methods as well as `validateOutput()`. 

https://github.com/dhillonks/cli-ssg/pull/26

Once these were ready, I pushed my changes and created a pull request to test the CI. And as expected, the CI ran all the tests (including the new ones) for my pull request's initial commit `baf9f92`:
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hbepphfo4gapnzm0hxbp.png)
 
The green check mark was nice to see, but I wanted to see if it would also fail when an assertion was not met. So, I intentionally modified an assertion to fail a test and when I pushed it:
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kd9ve9ddgg6y7zr1zmtk.png)

Seeing a red cross is not a good sign usually, but in this case it was! I checked the logs through GitHub Actions and it indeed was the assertion that I had modified. It was great seeing that everything was working as expected. 

At this point, I reverted the assertion and pushed again:
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7i25rq347wvdl8ni9y2e.png)

With another green check mark, I had verified that the CI was working and I merged the new tests into main.


## Adding tests to another project
I also ended up contributing some tests to [GMOTGIT/GMOT-SSG](https://github.com/GMOTGIT/GMOT-SSG). It was an interesting experience writing tests on someone else's code. I chose to expand the following test suite: 
- `htmlAssembler.test.js`
The challenging part about writing tests was that the `htmlAssembler.js` exported a single giant function which made it complicated to tests simple scenarios. This was contrary to my repo `cli-ssg` where I had broken up code into small modules.

The tests in `htmlAssembler.test.js` were quite basic and were only testing the parameters being empty or missing. Since there were no tests to test the actual HTML generation, I added a few test scenarios to test the following:
- `lang` attribute should be correctly generated
- `stylesheet` should be correctly generated
- `<title>` should be correctly generated
- `<h1>` should be correctly generated
- `<p>` should be correctly generated

After verifying that they ran as expected, I created a pr to `GMOT-SSG`:
https://github.com/GMOTGIT/GMOT-SSG/pull/21