npm 6 deprecates support for Node.js 4, which is still LTS until the end of
the week.
It's probably best to take a moment and ensure that npm@6 is actually
working as we desire too, so this is just to make sure that we don't end up
with a bunch of PRs that need to be re-based/re-tested, which seems to
already be happening.
This should avoid needing to include `[skip ci]` on every commit on branches
which are committed to docs, though will still provide us one "master"
branch run of tests when the PR lands.
We may want to remove this (maybe? longer-term), but this seems like a
short-term "win" on this branch for the time being.
cc: @jbaxleyiii @evans
By using CircleCI 2.0's new Workflow feature, we can more delicately
orchestrate how the test suite runs.
Specifically, we can have individual groups of tests report their status
independently to pull-requests, and react accordingly. For example, rather
than the linting tests being lumped into the individual tests ran on each
Node.js platform version, we can now run them on their own (and also avoid
unnecessarily running them over and over again for each Node.js version!).
Each jobs test results will be reported to the pull-request directly and, if
desired, the repository's branch merge rules can be modified to allow specific
types of test failures (like linting) to be allowed.
This need for greater test granularity became quite relevant recently when many
of the outstanding PRs on this repository were failing because of "prettier"
failures which were not directly related to the files changed by the PR but
by other changes on the `master` branch. In order to confidently review and
merge those PRs, it was necessary to look through each PRs four platform
test runs and ensure _each_ was a prettier failure and not something more
substantial. This manual step left way too much room for error and was not
a confidence builder, at all!
I've also added a new test for the documentation generation to ensure that
no changes in the PR have caused the documentation to not generate, which
would result in stale documentation since the existing documentation would
simply remain in place until the problem was eventually noticed.
As a last benefit, in my observations so far, CircleCI is running more
tests, more quickly and with greater parallelisation than our previous test
provider. Recently I've seen tests finishing in about two minutes rather than
what was sometimes 5 minutes.
