apollo-server/.circleci/config.yml

100 lines
3.4 KiB
YAML
Raw Normal View History

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-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:
# 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
Import graphql-extensions+apollo-engine-reporting/no global apollo-server-env (#1259) * Export polyfills and types separately * More imports from apollo-server-env * Initial commit * Add .npmignore to avoid ignoring lib when publishing * 0.0.2 * Reorganize code and clean up GraphQLExtension interface * 0.0.3 * Add support for timing callbacks and add GraphQLExtensionStack * 0.0.4 * Downgrade target in tsconfig.json from es2015 to es5 * 0.0.5 * Bump `graphql` peerDependency. (#3) * 0.0.6 * Update dependencies * 0.0.7 * whenResultIsFinished fix for array results (#4) * 0.0.8 * [apollo-bot] Update the Issue/PR Templates with auto label (#6) * Bump `graphql` peerDependency. (#7) * Update `graphql` peer dependency range to allow 0.13.x. (#8) * Update `devDependencies` to latest versions. (#9) * dev: Update TypeScript to latest version, v2.7.2. * dev: Update `graphql` to latest version, v0.13.2. * dev: Update jest & dependencies to latest versions. * dev: Update type definitions for `graphql`, `node` and `jest`. * Allow `undefined` return values to `GraphQLExtension`'s `format()`. (#10) In some cases, it's conceivable that the `format()` method may need to abort its decision to provide extension information at runtime, in the event that it doesn't have the proper information to return a full-result. The `format` method already removed false-y results, so this simply changes the types to allow the same. * 0.0.9 * Fix lifecycle method invocations on extensions * 0.0.10 * Add changelog * Upgrade to TypeScript 2.8 Makes my editor integration happier (a bugfix in tsserver I think) * Add tslint and prettier Same configuration as apollo-engine-js * Remove magic from GraphQLExtensionStack constructor It's not hard to consistently pass in an actual extension object to this low-level API. * New extension API: didStart handlers return didEnd handlers This is a backwards-incompatible change: GraphQLExtension implementations and users of GraphQLExtensionStack (ie apollo-server-core) must change their implementations, if they implement any of the xDidStart/xDidEnd APIs. This allows "didEnd" handlers to refer to closure variables from the "didStart" handler rather than needing to store state on the extension. The new "didEnd" handlers run in the opposite order of the "didStart" handlers, so that they properly nest. * 0.1.0-beta.0 * Changelog * Add magic back into GraphQLExtensionStack constructor But now it actually gets more context (the execution arguments) and doesn't have to be a constructor. * 0.1.0-beta.1 * Export more types * 0.1.0-beta.2 * Fix lifecycle handlers to pass proper "this" * 0.1.0-beta.3 * Pass options directly to start handlers; eliminate factory again * 0.1.0-beta.4 * error handling in didEnd * 0.1.0-beta.5 * pass multiple errors to EndHandler * 0.1.0-beta.6 * add willSendResponse * 0.1.0-beta.7 * prettier * setFieldResolver for custom fieldResolver * reverse * get more initial options into requestDidStart * 0.1.0-beta.8 * 0.1.0-beta.9 * Actually, we already get the fieldResolver! * 0.1.0-beta.10 * work without extensionStack * 0.1.0-beta.11 * 0.1.0-beta.12 * Send errors to willResolveField callback * 0.1.0-beta.13 * willSendResponse can return a result * 0.1.0-beta.14 * Revert 1063be8..56912fc This reverts commit 1063be8..56912fc. * add PQ options to requestDidStart * 0.1.0-beta.14 * 0.1.0-beta.15 * Initialize an empty TypeScript/Jest package Template based on apollo-engine-js * Basic trace node structure building * basic timing * Checkpoint towards signature implementation The new signature implementation does not try to compress whitespace. * Basic signature implementation * progress towards actual reporting * basic checkpoint for reporting * 0.0.0-beta.1 * pull in @types/long, since it is in the external api * 0.0.0-beta.2 * get rid of Long * 0.0.0-beta.3 * debug log request what happened * 0.0.0-beta.4 * 0.0.0-beta.5 * correct url * 0.0.0-beta.6 * request headers * 0.0.0-beta.7 * leave out a few headers * 0.0.0-beta.8 * prettier * move stuff into multiple files, and stop exporting the extension * lots of doc comments * address agent.ts XXX comments * implement privateVariables simplify API by removing flush() and allowing flush-ers to just call sendReport directly * privateHeaders and error tracking * gzip, signals * fix test * 0.0.0-beta.9 * Error handling for reports * 0.0.0-beta.10 * no need to include boring stacktrace * 0.0.0-beta.11 * tweak error reporting * 0.0.0-beta.12 * package-lock update (npm@6?) * Reduce target report size to 512KB from 4MB. Load testing revealed that protobuf encoding for large FullTraceReports could tie up CPU and reduce p99 request latency (eg, to 200ms from 10ms). Reducing the default target report size spreads out the encoding time and mitigates the impact on latency. If this is not acceptable for all users, we may have to investigate reintroducing agent-side stats aggregation to keep report sizes small. * 0.0.0-beta.13 * Encode Traces as they come in This improves p99 times with little effect on p50 times. It also lets us get rid of the heuristic average trace size estimation. * 0.0.0-beta.14 * support PQ fields * npm audit fix * 0.0.0-beta.15 * ignore coverage * Make the default signature more aggressive We'd rather tell people confused by literal removal to tweak the signature than tell people causing outages to do so. * 0.0.0-beta.16 * Remove obsolete files from graphql-extensions and apollo-engine-reporting * Fix dependencies and configs * Fix apollo-server-cloudflare to import from apollo-server-env * Fix compilation and test configs * Get all tests passing again * Switch to Lerna independent versioning * Polyfill promisify for Node < 8 and load polyfills in tests * ES2016 exponentiation operator is only supported in Node > 6 * add dependency cache for circle * add missing env dependencies in REST datasource
2018-06-28 01:29:00 +02:00
- run: cat ./packages/*/package.json > package-checksum
- restore_cache:
key: dependency-cache-{{ checksum "package.json" }}-{{ checksum "package-checksum" }}
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
- run: npm --version
- run: npm install
Import graphql-extensions+apollo-engine-reporting/no global apollo-server-env (#1259) * Export polyfills and types separately * More imports from apollo-server-env * Initial commit * Add .npmignore to avoid ignoring lib when publishing * 0.0.2 * Reorganize code and clean up GraphQLExtension interface * 0.0.3 * Add support for timing callbacks and add GraphQLExtensionStack * 0.0.4 * Downgrade target in tsconfig.json from es2015 to es5 * 0.0.5 * Bump `graphql` peerDependency. (#3) * 0.0.6 * Update dependencies * 0.0.7 * whenResultIsFinished fix for array results (#4) * 0.0.8 * [apollo-bot] Update the Issue/PR Templates with auto label (#6) * Bump `graphql` peerDependency. (#7) * Update `graphql` peer dependency range to allow 0.13.x. (#8) * Update `devDependencies` to latest versions. (#9) * dev: Update TypeScript to latest version, v2.7.2. * dev: Update `graphql` to latest version, v0.13.2. * dev: Update jest & dependencies to latest versions. * dev: Update type definitions for `graphql`, `node` and `jest`. * Allow `undefined` return values to `GraphQLExtension`'s `format()`. (#10) In some cases, it's conceivable that the `format()` method may need to abort its decision to provide extension information at runtime, in the event that it doesn't have the proper information to return a full-result. The `format` method already removed false-y results, so this simply changes the types to allow the same. * 0.0.9 * Fix lifecycle method invocations on extensions * 0.0.10 * Add changelog * Upgrade to TypeScript 2.8 Makes my editor integration happier (a bugfix in tsserver I think) * Add tslint and prettier Same configuration as apollo-engine-js * Remove magic from GraphQLExtensionStack constructor It's not hard to consistently pass in an actual extension object to this low-level API. * New extension API: didStart handlers return didEnd handlers This is a backwards-incompatible change: GraphQLExtension implementations and users of GraphQLExtensionStack (ie apollo-server-core) must change their implementations, if they implement any of the xDidStart/xDidEnd APIs. This allows "didEnd" handlers to refer to closure variables from the "didStart" handler rather than needing to store state on the extension. The new "didEnd" handlers run in the opposite order of the "didStart" handlers, so that they properly nest. * 0.1.0-beta.0 * Changelog * Add magic back into GraphQLExtensionStack constructor But now it actually gets more context (the execution arguments) and doesn't have to be a constructor. * 0.1.0-beta.1 * Export more types * 0.1.0-beta.2 * Fix lifecycle handlers to pass proper "this" * 0.1.0-beta.3 * Pass options directly to start handlers; eliminate factory again * 0.1.0-beta.4 * error handling in didEnd * 0.1.0-beta.5 * pass multiple errors to EndHandler * 0.1.0-beta.6 * add willSendResponse * 0.1.0-beta.7 * prettier * setFieldResolver for custom fieldResolver * reverse * get more initial options into requestDidStart * 0.1.0-beta.8 * 0.1.0-beta.9 * Actually, we already get the fieldResolver! * 0.1.0-beta.10 * work without extensionStack * 0.1.0-beta.11 * 0.1.0-beta.12 * Send errors to willResolveField callback * 0.1.0-beta.13 * willSendResponse can return a result * 0.1.0-beta.14 * Revert 1063be8..56912fc This reverts commit 1063be8..56912fc. * add PQ options to requestDidStart * 0.1.0-beta.14 * 0.1.0-beta.15 * Initialize an empty TypeScript/Jest package Template based on apollo-engine-js * Basic trace node structure building * basic timing * Checkpoint towards signature implementation The new signature implementation does not try to compress whitespace. * Basic signature implementation * progress towards actual reporting * basic checkpoint for reporting * 0.0.0-beta.1 * pull in @types/long, since it is in the external api * 0.0.0-beta.2 * get rid of Long * 0.0.0-beta.3 * debug log request what happened * 0.0.0-beta.4 * 0.0.0-beta.5 * correct url * 0.0.0-beta.6 * request headers * 0.0.0-beta.7 * leave out a few headers * 0.0.0-beta.8 * prettier * move stuff into multiple files, and stop exporting the extension * lots of doc comments * address agent.ts XXX comments * implement privateVariables simplify API by removing flush() and allowing flush-ers to just call sendReport directly * privateHeaders and error tracking * gzip, signals * fix test * 0.0.0-beta.9 * Error handling for reports * 0.0.0-beta.10 * no need to include boring stacktrace * 0.0.0-beta.11 * tweak error reporting * 0.0.0-beta.12 * package-lock update (npm@6?) * Reduce target report size to 512KB from 4MB. Load testing revealed that protobuf encoding for large FullTraceReports could tie up CPU and reduce p99 request latency (eg, to 200ms from 10ms). Reducing the default target report size spreads out the encoding time and mitigates the impact on latency. If this is not acceptable for all users, we may have to investigate reintroducing agent-side stats aggregation to keep report sizes small. * 0.0.0-beta.13 * Encode Traces as they come in This improves p99 times with little effect on p50 times. It also lets us get rid of the heuristic average trace size estimation. * 0.0.0-beta.14 * support PQ fields * npm audit fix * 0.0.0-beta.15 * ignore coverage * Make the default signature more aggressive We'd rather tell people confused by literal removal to tweak the signature than tell people causing outages to do so. * 0.0.0-beta.16 * Remove obsolete files from graphql-extensions and apollo-engine-reporting * Fix dependencies and configs * Fix apollo-server-cloudflare to import from apollo-server-env * Fix compilation and test configs * Get all tests passing again * Switch to Lerna independent versioning * Polyfill promisify for Node < 8 and load polyfills in tests * ES2016 exponentiation operator is only supported in Node > 6 * add dependency cache for circle * add missing env dependencies in REST datasource
2018-06-28 01:29:00 +02:00
- save_cache:
key: dependency-cache-{{ checksum "package.json" }}-{{ checksum "package-checksum" }}
paths:
- ./node_modules
Mocha to Jest Test Conversion (#1453) * import jest * remove mocha, chai, sinon * fix JSON parsing for package.json * replace import mocha, chai, sinon with jest * add jest as test npm script * remove dependency on mocha types * errors: remove unused jest tests * move tests to __tests__ folders * add jest types to root tsconfig * fix tsconfig include excludes * .to.equal -> toEqual * .true -> .toBe(true) * .to.deep.equal -> .toEqual * .to.exist -> .toBeDefined() * .to.contain -> .toMatch * .to.match -> .toMatch * to.be.undefined -> .toBeUndefined() * not.toBeDefined -> .toBeUndefined * bring integration test up to date with past changes * remove message from expect * .null -> .toBe(null) * expect.fail -> done.fail * callsFake -> jest.fn * mocha mock calls -> jest * .not.to.exist -> .toBeUndefined() * callCount -> mocks.calls.length * returns -> jest.fn() * .equals -> .toEqual * fix relative imports * remove string in expects and place as comment * remove Fibers from runQuery * restore -> mockRestore * before -> beforeAll * after -> afterAll * fix async_hooks test and Promise await * remove jest from testsuite package json * remove unnecessary apollo-server-env setup * add start of cloudflare tests * this.timeout -> timeout argument * express: fix relative require * import gql tag properly * .to.throw -> .toThrow * .to.be.instanceof -> .toBeInstanceOf * remove console log check test * done(Error) -> done.fail(Error) * done -> done.fail * change port numbers, since jest runs in parallel * fix toBeUndefined for null checks * make engine port unique in testsuite * make data source rest endpoint port unique * add coverage scripts * travis npm script -> cricle script * make engine port random * change ports to not conflict across integrations * increase node version for apollo-server-hapi * add node versioning to prevent hapi tests from running * move jest dependencies to the root package.json * make hapi port unique * fix port reference in hapi tests
2018-07-31 15:40:03 -07:00
- run: npm run circle
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
# 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
Import graphql-extensions+apollo-engine-reporting/no global apollo-server-env (#1259) * Export polyfills and types separately * More imports from apollo-server-env * Initial commit * Add .npmignore to avoid ignoring lib when publishing * 0.0.2 * Reorganize code and clean up GraphQLExtension interface * 0.0.3 * Add support for timing callbacks and add GraphQLExtensionStack * 0.0.4 * Downgrade target in tsconfig.json from es2015 to es5 * 0.0.5 * Bump `graphql` peerDependency. (#3) * 0.0.6 * Update dependencies * 0.0.7 * whenResultIsFinished fix for array results (#4) * 0.0.8 * [apollo-bot] Update the Issue/PR Templates with auto label (#6) * Bump `graphql` peerDependency. (#7) * Update `graphql` peer dependency range to allow 0.13.x. (#8) * Update `devDependencies` to latest versions. (#9) * dev: Update TypeScript to latest version, v2.7.2. * dev: Update `graphql` to latest version, v0.13.2. * dev: Update jest & dependencies to latest versions. * dev: Update type definitions for `graphql`, `node` and `jest`. * Allow `undefined` return values to `GraphQLExtension`'s `format()`. (#10) In some cases, it's conceivable that the `format()` method may need to abort its decision to provide extension information at runtime, in the event that it doesn't have the proper information to return a full-result. The `format` method already removed false-y results, so this simply changes the types to allow the same. * 0.0.9 * Fix lifecycle method invocations on extensions * 0.0.10 * Add changelog * Upgrade to TypeScript 2.8 Makes my editor integration happier (a bugfix in tsserver I think) * Add tslint and prettier Same configuration as apollo-engine-js * Remove magic from GraphQLExtensionStack constructor It's not hard to consistently pass in an actual extension object to this low-level API. * New extension API: didStart handlers return didEnd handlers This is a backwards-incompatible change: GraphQLExtension implementations and users of GraphQLExtensionStack (ie apollo-server-core) must change their implementations, if they implement any of the xDidStart/xDidEnd APIs. This allows "didEnd" handlers to refer to closure variables from the "didStart" handler rather than needing to store state on the extension. The new "didEnd" handlers run in the opposite order of the "didStart" handlers, so that they properly nest. * 0.1.0-beta.0 * Changelog * Add magic back into GraphQLExtensionStack constructor But now it actually gets more context (the execution arguments) and doesn't have to be a constructor. * 0.1.0-beta.1 * Export more types * 0.1.0-beta.2 * Fix lifecycle handlers to pass proper "this" * 0.1.0-beta.3 * Pass options directly to start handlers; eliminate factory again * 0.1.0-beta.4 * error handling in didEnd * 0.1.0-beta.5 * pass multiple errors to EndHandler * 0.1.0-beta.6 * add willSendResponse * 0.1.0-beta.7 * prettier * setFieldResolver for custom fieldResolver * reverse * get more initial options into requestDidStart * 0.1.0-beta.8 * 0.1.0-beta.9 * Actually, we already get the fieldResolver! * 0.1.0-beta.10 * work without extensionStack * 0.1.0-beta.11 * 0.1.0-beta.12 * Send errors to willResolveField callback * 0.1.0-beta.13 * willSendResponse can return a result * 0.1.0-beta.14 * Revert 1063be8..56912fc This reverts commit 1063be8..56912fc. * add PQ options to requestDidStart * 0.1.0-beta.14 * 0.1.0-beta.15 * Initialize an empty TypeScript/Jest package Template based on apollo-engine-js * Basic trace node structure building * basic timing * Checkpoint towards signature implementation The new signature implementation does not try to compress whitespace. * Basic signature implementation * progress towards actual reporting * basic checkpoint for reporting * 0.0.0-beta.1 * pull in @types/long, since it is in the external api * 0.0.0-beta.2 * get rid of Long * 0.0.0-beta.3 * debug log request what happened * 0.0.0-beta.4 * 0.0.0-beta.5 * correct url * 0.0.0-beta.6 * request headers * 0.0.0-beta.7 * leave out a few headers * 0.0.0-beta.8 * prettier * move stuff into multiple files, and stop exporting the extension * lots of doc comments * address agent.ts XXX comments * implement privateVariables simplify API by removing flush() and allowing flush-ers to just call sendReport directly * privateHeaders and error tracking * gzip, signals * fix test * 0.0.0-beta.9 * Error handling for reports * 0.0.0-beta.10 * no need to include boring stacktrace * 0.0.0-beta.11 * tweak error reporting * 0.0.0-beta.12 * package-lock update (npm@6?) * Reduce target report size to 512KB from 4MB. Load testing revealed that protobuf encoding for large FullTraceReports could tie up CPU and reduce p99 request latency (eg, to 200ms from 10ms). Reducing the default target report size spreads out the encoding time and mitigates the impact on latency. If this is not acceptable for all users, we may have to investigate reintroducing agent-side stats aggregation to keep report sizes small. * 0.0.0-beta.13 * Encode Traces as they come in This improves p99 times with little effect on p50 times. It also lets us get rid of the heuristic average trace size estimation. * 0.0.0-beta.14 * support PQ fields * npm audit fix * 0.0.0-beta.15 * ignore coverage * Make the default signature more aggressive We'd rather tell people confused by literal removal to tweak the signature than tell people causing outages to do so. * 0.0.0-beta.16 * Remove obsolete files from graphql-extensions and apollo-engine-reporting * Fix dependencies and configs * Fix apollo-server-cloudflare to import from apollo-server-env * Fix compilation and test configs * Get all tests passing again * Switch to Lerna independent versioning * Polyfill promisify for Node < 8 and load polyfills in tests * ES2016 exponentiation operator is only supported in Node > 6 * add dependency cache for circle * add missing env dependencies in REST datasource
2018-06-28 01:29:00 +02:00
- restore_cache:
key: dependency-cache-{{ checksum "./docs/package.json" }}
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
# (speed) Ignore scripts to skip the Lerna build stuff for linting.
- run: npm install-test --prefix ./docs
Import graphql-extensions+apollo-engine-reporting/no global apollo-server-env (#1259) * Export polyfills and types separately * More imports from apollo-server-env * Initial commit * Add .npmignore to avoid ignoring lib when publishing * 0.0.2 * Reorganize code and clean up GraphQLExtension interface * 0.0.3 * Add support for timing callbacks and add GraphQLExtensionStack * 0.0.4 * Downgrade target in tsconfig.json from es2015 to es5 * 0.0.5 * Bump `graphql` peerDependency. (#3) * 0.0.6 * Update dependencies * 0.0.7 * whenResultIsFinished fix for array results (#4) * 0.0.8 * [apollo-bot] Update the Issue/PR Templates with auto label (#6) * Bump `graphql` peerDependency. (#7) * Update `graphql` peer dependency range to allow 0.13.x. (#8) * Update `devDependencies` to latest versions. (#9) * dev: Update TypeScript to latest version, v2.7.2. * dev: Update `graphql` to latest version, v0.13.2. * dev: Update jest & dependencies to latest versions. * dev: Update type definitions for `graphql`, `node` and `jest`. * Allow `undefined` return values to `GraphQLExtension`'s `format()`. (#10) In some cases, it's conceivable that the `format()` method may need to abort its decision to provide extension information at runtime, in the event that it doesn't have the proper information to return a full-result. The `format` method already removed false-y results, so this simply changes the types to allow the same. * 0.0.9 * Fix lifecycle method invocations on extensions * 0.0.10 * Add changelog * Upgrade to TypeScript 2.8 Makes my editor integration happier (a bugfix in tsserver I think) * Add tslint and prettier Same configuration as apollo-engine-js * Remove magic from GraphQLExtensionStack constructor It's not hard to consistently pass in an actual extension object to this low-level API. * New extension API: didStart handlers return didEnd handlers This is a backwards-incompatible change: GraphQLExtension implementations and users of GraphQLExtensionStack (ie apollo-server-core) must change their implementations, if they implement any of the xDidStart/xDidEnd APIs. This allows "didEnd" handlers to refer to closure variables from the "didStart" handler rather than needing to store state on the extension. The new "didEnd" handlers run in the opposite order of the "didStart" handlers, so that they properly nest. * 0.1.0-beta.0 * Changelog * Add magic back into GraphQLExtensionStack constructor But now it actually gets more context (the execution arguments) and doesn't have to be a constructor. * 0.1.0-beta.1 * Export more types * 0.1.0-beta.2 * Fix lifecycle handlers to pass proper "this" * 0.1.0-beta.3 * Pass options directly to start handlers; eliminate factory again * 0.1.0-beta.4 * error handling in didEnd * 0.1.0-beta.5 * pass multiple errors to EndHandler * 0.1.0-beta.6 * add willSendResponse * 0.1.0-beta.7 * prettier * setFieldResolver for custom fieldResolver * reverse * get more initial options into requestDidStart * 0.1.0-beta.8 * 0.1.0-beta.9 * Actually, we already get the fieldResolver! * 0.1.0-beta.10 * work without extensionStack * 0.1.0-beta.11 * 0.1.0-beta.12 * Send errors to willResolveField callback * 0.1.0-beta.13 * willSendResponse can return a result * 0.1.0-beta.14 * Revert 1063be8..56912fc This reverts commit 1063be8..56912fc. * add PQ options to requestDidStart * 0.1.0-beta.14 * 0.1.0-beta.15 * Initialize an empty TypeScript/Jest package Template based on apollo-engine-js * Basic trace node structure building * basic timing * Checkpoint towards signature implementation The new signature implementation does not try to compress whitespace. * Basic signature implementation * progress towards actual reporting * basic checkpoint for reporting * 0.0.0-beta.1 * pull in @types/long, since it is in the external api * 0.0.0-beta.2 * get rid of Long * 0.0.0-beta.3 * debug log request what happened * 0.0.0-beta.4 * 0.0.0-beta.5 * correct url * 0.0.0-beta.6 * request headers * 0.0.0-beta.7 * leave out a few headers * 0.0.0-beta.8 * prettier * move stuff into multiple files, and stop exporting the extension * lots of doc comments * address agent.ts XXX comments * implement privateVariables simplify API by removing flush() and allowing flush-ers to just call sendReport directly * privateHeaders and error tracking * gzip, signals * fix test * 0.0.0-beta.9 * Error handling for reports * 0.0.0-beta.10 * no need to include boring stacktrace * 0.0.0-beta.11 * tweak error reporting * 0.0.0-beta.12 * package-lock update (npm@6?) * Reduce target report size to 512KB from 4MB. Load testing revealed that protobuf encoding for large FullTraceReports could tie up CPU and reduce p99 request latency (eg, to 200ms from 10ms). Reducing the default target report size spreads out the encoding time and mitigates the impact on latency. If this is not acceptable for all users, we may have to investigate reintroducing agent-side stats aggregation to keep report sizes small. * 0.0.0-beta.13 * Encode Traces as they come in This improves p99 times with little effect on p50 times. It also lets us get rid of the heuristic average trace size estimation. * 0.0.0-beta.14 * support PQ fields * npm audit fix * 0.0.0-beta.15 * ignore coverage * Make the default signature more aggressive We'd rather tell people confused by literal removal to tweak the signature than tell people causing outages to do so. * 0.0.0-beta.16 * Remove obsolete files from graphql-extensions and apollo-engine-reporting * Fix dependencies and configs * Fix apollo-server-cloudflare to import from apollo-server-env * Fix compilation and test configs * Get all tests passing again * Switch to Lerna independent versioning * Polyfill promisify for Node < 8 and load polyfills in tests * ES2016 exponentiation operator is only supported in Node > 6 * add dependency cache for circle * add missing env dependencies in REST datasource
2018-06-28 01:29:00 +02:00
- save_cache:
key: dependency-cache-{{ checksum "./docs/package.json" }}
paths:
- ./docs/node_modules
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
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
- Node.js 8:
<<: *ignore_doc_branches
2018-06-11 13:22:13 +02:00
- Node.js 10:
<<: *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