Switch to using CircleCI 2.0 Workflows. (#882)
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.
2018-03-16 11:38:39 +02:00
|
|
|
version: 2
|
|
|
|
|
2018-06-14 12:03:24 +03:00
|
|
|
#
|
2018-06-11 17:55:21 +02:00
|
|
|
# Reusable Snippets!
|
|
|
|
#
|
|
|
|
# These are re-used by the various tests below, to avoid repetition.
|
|
|
|
#
|
|
|
|
run_install_desired_npm: &run_install_desired_npm
|
|
|
|
run:
|
2018-06-14 12:03:24 +03:00
|
|
|
# Due to a bug, npm upgrades from the version of npm that ships with
|
|
|
|
# Node.js 6 (npm v3.10.10) go poorly and generally causes other problems
|
|
|
|
# with the environment. Since yarn is already available here we can just
|
|
|
|
# use that to work-around the issue. It's possible that npm cleanup might
|
|
|
|
# prevent this from being necessary, but this installation can be switched
|
|
|
|
# to use `npm` (rather than `yarn`) once Node 6 is no longer tested below.
|
|
|
|
name: Install npm@5, but with yarn.
|
2018-06-13 14:56:09 -07:00
|
|
|
command: sudo yarn global add npm@5
|
2018-06-11 17:55:21 +02:00
|
|
|
|
Switch to using CircleCI 2.0 Workflows. (#882)
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.
2018-03-16 11:38:39 +02:00
|
|
|
# These are the steps used for each version of Node which we're testing
|
|
|
|
# against. Thanks to YAMLs inability to merge arrays (though it is able
|
|
|
|
# to merge objects), every version of Node must use the exact same steps,
|
|
|
|
# or these steps would need to be repeated in a version of Node that needs
|
|
|
|
# something different. Probably best to avoid that, out of principle, though.
|
|
|
|
common_test_steps: &common_test_steps
|
|
|
|
steps:
|
2018-06-11 17:55:21 +02:00
|
|
|
- *run_install_desired_npm
|
Switch to using CircleCI 2.0 Workflows. (#882)
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.
2018-03-16 11:38:39 +02:00
|
|
|
- checkout
|
|
|
|
- run: npm --version
|
|
|
|
- run: npm install
|
|
|
|
- run: npm run travis
|
|
|
|
|
|
|
|
# Important! When adding a new job to `jobs`, make sure to define when it
|
|
|
|
# executes by also adding it to the `workflows` section below!
|
|
|
|
jobs:
|
|
|
|
|
|
|
|
# Platform tests, each with the same tests but different platform or version.
|
|
|
|
# The docker tag represents the Node.js version and the full list is available
|
|
|
|
# at https://hub.docker.com/r/circleci/node/.
|
2018-06-13 14:56:09 -07:00
|
|
|
Node.js 6:
|
|
|
|
docker: [ { image: 'circleci/node:6' } ]
|
|
|
|
<<: *common_test_steps
|
|
|
|
|
Switch to using CircleCI 2.0 Workflows. (#882)
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.
2018-03-16 11:38:39 +02:00
|
|
|
Node.js 8:
|
|
|
|
docker: [ { image: 'circleci/node:8' } ]
|
|
|
|
<<: *common_test_steps
|
|
|
|
|
2018-06-11 13:22:13 +02:00
|
|
|
Node.js 10:
|
|
|
|
docker: [ { image: 'circleci/node:10' } ]
|
Switch to using CircleCI 2.0 Workflows. (#882)
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.
2018-03-16 11:38:39 +02:00
|
|
|
<<: *common_test_steps
|
|
|
|
|
|
|
|
# Other tests, unrelated to typical code tests.
|
|
|
|
Linting:
|
|
|
|
docker: [ { image: 'circleci/node:8' } ]
|
|
|
|
steps:
|
|
|
|
# (speed) Intentionally omitted, unnecessary, run_install_desired_npm.
|
|
|
|
- checkout
|
|
|
|
# (speed) --ignore-scripts to skip unnecessary Lerna build during linting.
|
|
|
|
- run: npm install --ignore-scripts
|
|
|
|
- run: npm run lint
|
|
|
|
Docs:
|
|
|
|
docker: [ { image: 'circleci/node:8' } ]
|
|
|
|
steps:
|
|
|
|
# (speed) Intentionally omitted, unnecessary, run_install_desired_npm.
|
|
|
|
- checkout
|
|
|
|
# (speed) Ignore scripts to skip the Lerna build stuff for linting.
|
|
|
|
- run: npm install-test --prefix ./docs
|
|
|
|
|
2018-04-20 15:41:42 +03:00
|
|
|
ignore_doc_branches: &ignore_doc_branches
|
|
|
|
filters:
|
|
|
|
branches:
|
|
|
|
# If 'docs' is found, with word boundaries on either side, skip.
|
|
|
|
ignore: /.*?\bdocs\b.*/
|
|
|
|
|
Switch to using CircleCI 2.0 Workflows. (#882)
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.
2018-03-16 11:38:39 +02:00
|
|
|
workflows:
|
|
|
|
version: 2
|
|
|
|
Build and Test:
|
|
|
|
jobs:
|
2018-06-13 14:56:09 -07:00
|
|
|
- Node.js 6:
|
|
|
|
<<: *ignore_doc_branches
|
2018-04-20 15:41:42 +03:00
|
|
|
- Node.js 8:
|
|
|
|
<<: *ignore_doc_branches
|
2018-06-11 13:22:13 +02:00
|
|
|
- Node.js 10:
|
2018-04-20 15:41:42 +03:00
|
|
|
<<: *ignore_doc_branches
|
|
|
|
- Linting:
|
|
|
|
<<: *ignore_doc_branches
|
Switch to using CircleCI 2.0 Workflows. (#882)
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.
2018-03-16 11:38:39 +02:00
|
|
|
- Docs
|