frontend-app-ora-grading/documentation/.travis.yml.md

Travis Configuration

Your project might have different build requirements - however, this project's .travis.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.

Caching node_modules

While the Travis blog recommends

cache:
  directories:
    - node_modules

this causes issues when testing different versions of Node because node_modules will store the compiled native modules.

Caching the ~/.npm directory avoids storing these native modules.

Notifications

This project uses a service called TravisBuddy, which provides Travis build context within a PR via webhooks (configured only to add feedback for build failures).

Installing greenkeeper-lockfile

As explained in the Greenkeeper documentation, Greenkeeper is a service that keeps track of your project's dependencies, and will, for example, automatically open PRs with an updated package.json file when the latest version of a dependency is a major version ahead of the existing dependency version in your package.json file.

This automated updating is great, but Greenkeeper does not update your package-lock.json file, just your package.json file. This makes sense, as the only way to update the package-lock.json file would be to run npm install when building your project, using the latest package.json, and then committing the updated package-lock.json file.

This is essentially what you have to do manually when Greenkeeper opens a PR - git checkout the branch, npm install locally, git commit the package-lock.json changes, and then git push those changes to the Greenkeeper branch on origin. It's fun probably only the first time, and even then it gets old, fast.

What greenkeeper-lockfile does is that it automates the previous steps as part of the build process.

It will

• Check that the branch is a Greenkeeper branch
• Update the lockfile
• Push a commit with the updated lockfile back to the Greenkeeper branch

This is why it's important to install greenkeeper-lockfile in the before_install step, and since it's used exclusively only in the Travis Build, why it's not part of the package's dependencies.

Scripts

Most of the scripts 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 scripts 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 diffs for any package-lock.json file changes in your project. It's important to remember that all build scripts are executed in Travis after the install step (aka post-npm install).

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.

However, when these changes surface within a Travis build, this indicates differing dependency expectations between the committed package.json file and the package-lock.json file, which is a good reason to fail a build.

What is this npm run is-es5 check?

This project outputs production files to the dist folder. The npm script, npm run is-es5, checks the JavaScript files in the dist folder to make sure that they are ES5-compliant.

This check is important because ES5 JavaScript has greater browser compatibility than ES2015+ - particularly for IE11.

deploy step

How your project deploys will probably differ between the cookie cutter and your own application.

For demonstrational purposes, the cookie cutter deploys to GitHub pages using Travis's GitHub pages configuration.

Your application might deploy to an S3 bucket or to npm.