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](mailto:adw4236@rit.edu)>

# Source Control Setup
The project currently uses GitHub as a source control platform which provides
[GitHub Actions](https://docs.github.com/en/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](https://www.cypress.io/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](https://superuser.com/questions/1189901/can-i-integrate-a-discord-channel-with-github-pull-requests#:~:text=2%20Answers&text=Integrating%20GitHub%20updates%20into%20a,be%20done%20with%20webhook%20updates.&text=Click%20the%20%22Add%20webhook%22%20button,the%20end%20of%20your%20URL.),
but other common communication platforms like Slack also have ways to
[accomplish the same thing](https://slack.com/help/articles/232289568-GitHub-for-Slack).
