This week in my open-source course (DPS909), we were asked to add Continuous Integration (CI) to our static site generator (SSG).
This continues the work we did in lab 8 when we added testing. CI is a method where you can build and run tests automatically whenever anything is pushed to the repo, or a new pull request is made.
GitHub Actions CI Workflow
To setup CI in my project, I created a GitHub actions workflow. I followed this guide which shows how to build and test a Node.js project using GitHub actions workflows.
The YAML file I created for testing looked very similar to the example template given in the guide. The only thing I had to change was the operating system the workflow jobs run on. I changed it to run on Windows instead of the default Linux/Ubuntu environment. This was because I originally did my tests on my local Windows machine, so the snapshots taken by my tests use CRLF instead of LF for line endings. So just to avoid any testing errors coming from a windows environment, I changed the workflow job environment to match.
Adding Tests to Another Repo
PR to another repo: https://github.com/cychu42/staticSiteCon/pull/21
My partner's repo and testing setup was very similar to my own. The main difference was that they used multiple testing files which kept things more organized. In hindsight, I probably should've done the same thing to keep things cleaner.
They pretty much covered all areas of their program with their existing tests. I just added tests to their MD parser that was similar to tests they added for their text parser. I did this just to make sure testing for both parsers are consistent.
Conclusion
Now that I know how to add CI to my project, I feel like it's a must to add it to any new project I create since it makes testing easier. You don't have to worry about accidently merging anything that will break the code in main.
Top comments (0)