Continuous Integration

Due Date:

Revisions Due:

As covered in the lesson, continuous integration in our case will take the form of various forms of validation passing in order for a change to be allowed to merge into the main repository. You will be setting this up using GitHub Actions.

You will need to execute three different jobs any time a pull_request event occurs:

  • Run vitest through the already available npm run test
  • Check formatting through the already avialable npm run lint
  • ESLint, which will be described in more detail below

Your fork of the repo should be able to run these workflows on demand. Because the trigger will be a pull_request, they won't happen by default, but if you also include the trigger worflow_dispatch this should be possible for testing before you submit the pull request.

ESLint

As mentioned above, you will be adding ESLint to the project to identify additional problems. If you're struggling to figure out how to incorporate it into the existing project, the command to create a SvelteKit project provides it as an option, you can create a sandbox app and see what files it creates and/or modifies.

When you first run ESLint, it's extremely likely that it will have a laundry list of issues that need to be resolved. Part of your assignnment is to work through each of these and resolve them, either by fixing the issue or disabling the warning. You should include in the pull request description any warnings you chose to ignore with an explanation of why you made that decision.