Source Control Setup

This page provides information on how to set up source control to manage our CI and how you might be able to use it for additional CI or CD in future iterations.

• Author: Alex Wilkes <adw4236@rit.edu>

Source Control Setup

The project currently uses GitHub as a source control platform which provides GitHub Actions as a CI/CD pipeline. This project makes use of this for CI although we use Azure for CD. If another cloud platform is used, it is likely the next team could use GitHub Actions for CD as well. If another source control repository is used, they likely have something similar to GitHub actions.

GitHub Actions

All the configuration for GitHub actions is present in the top-level /.github directory. The /workflows folder contains yml configurations that give GitHub information on how and when to run the CI.

Our team set up two different workflows.

• deploydocs.yml Exists to automatically push the generated API docs to our project website. This is almost certainly unnecessary, but we left it in for future teams reference.
• integrate.yml Defines how and when our unit tests should run.

Our sprint naming scheme is critical to ensuring the CI works properly, if the naming scheme is changed, the matching scheme needs to be changed in the configuration as well.

Each job in the CI runs asynchronously which allows us to run both the frontend and backend CI at the same time.

Client CI

The steps the Client CI takes to run are as follows:

1. run npm ci which runs npm install for both the client and server
2. run cypress using a github actions plugin. We attempted to do this using just CLI options, but we could not get it to work for some reason. This only runs the frontend tests, not the end-to-end.
   • Cypress runs the with.start command and waits on the server to be running before starting the tests.
   • Environment variables are specified at the top of the job and for Cypress specifically.
3. Start an in memory MongoDB that can be used for End-to-End testing.
4. Add an admin user to the database (we require a user for the server to run)
5. Run cypress End-To-End tests waiting for both the frontend and the backend to be running.
   • Note: We do not use the production environment for running these tests, but that may be deireable to add in the future.

To help parse this file, look for the dashes (-) which each indicate a step in the CI process.

Server CI

Unlike the client CI, the server CI is very straightforward. It simply runs npm ci which essentially runs npm install followed by npm test which runs jest and returns the results. It also runs a build in case it exists, but since there is not a build cycle for the server side, this is not needed.

Cypress CI Bot

As part of our continuous integration, involves running cypress tests. Cypress has a dashboard that can be used to view results of CI runs in much more detail. There is a limit to the free usage of this dashboard.

Web hook Notifications

The last thing our team configured that we thought was very useful was direct notifications at GitHub activity. We used discord and webhooks, but other common communication platforms like Slack also have ways to accomplish the same thing.