30 lines
1.6 KiB
Markdown
Executable File
30 lines
1.6 KiB
Markdown
Executable File
# CI Configuration
|
|
|
|
Your project might have different build requirements - however, this project's `.github/workflows/ci.yml` configuration is supposed to represent a good starting point.
|
|
|
|
## Node JS Version
|
|
|
|
The minimum `Node` and `npm` versions that edX supports is `8.9.3` and `5.5.1`, respectively.
|
|
|
|
## Notifications
|
|
|
|
This project uses a [`Composite Action`](https://docs.github.com/en/actions/creating-actions/about-custom-actions) for sending notifications for failure on the PRs.
|
|
|
|
## Scripts
|
|
|
|
Most of the `script`s are self-explanatory - you probably want to fail a build if there are linting violations, or if any tests don't pass, or if it cannot compile your files.
|
|
|
|
However, there are a couple additional `script`s that might seem less self-explanatory.
|
|
|
|
### What the heck is `make validate-no-uncommitted-package-lock-changes`?
|
|
|
|
There are only two requirements for a good `make target` name
|
|
|
|
1. Definitely make it really verbose so people can't remember what it's called
|
|
2. Definitely don't not use a double-negative
|
|
|
|
What `make validate-no-uncommitted-package-lock-changes` does is `git diff`s for any `package-lock.json` file changes in your project.
|
|
|
|
This is important because `npm` uses the pinned dependencies in your `package-lock.json` file to build the `node_modules` directory. However, the dependencies defined within the `package.json` file can be modified manually, for example, to become misaligned with the dependencies defined within the `package-lock.json`. So when `npm install` executes, the `package-lock.json` file will be updated to mirror the modified `package.json` changes.
|
|
|