.circleci/config.yml

@@ -6,7 +6,7 @@ orbs:
   # `oss` is a local reference to the package.  The source for Apollo Orbs can
   # be found at http://github.com/apollographql/CircleCI-Orbs/.
   # We could use Renovate to bump this version via PR, but that's not setup now.
-  oss: apollo/oss-ci-cd-tooling@0.0.16
+  oss: apollo/oss-ci-cd-tooling@0.0.17
 
 commands:
   # These are the steps used for each version of Node which we're testing
@@ -72,6 +72,24 @@ jobs:
     steps:
       - common_test_steps
 
+  # We make CI fail if any file contains FIX and ME right next to each other.
+  # This means that when working on a big PR, you can throw in notes that you
+  # are forced to come back to before merging the PR.  Note that we don't block
+  # the tarball or publish steps on this, since you may want to try out builds
+  # on branches that still contain unresolved problems. In order for this file
+  # to not cause this job to fail, we obfuscate the target string by encoding
+  # the last letter in in hex (\x45 = E).
+  "Check for FIXM\x45":
+    docker:
+    - image: cimg/base:stable
+    steps:
+    - add_ssh_keys
+    - checkout
+    - run:
+        name: "Check for FIXM\x45"
+        # ! means this fails if git grep succeeds, ie if there are any matches
+        command: "! git grep FIXM\x45"
+
 # XXX We used to use this filter to only run a "Docs" job on docs branches.
 #     Now we use it to disable all jobs. It's unclear if there's a simpler way
 #     to do this!
@@ -98,8 +116,6 @@ workflows:
   version: 2
   Build:
     jobs:
-      # - NodeJS 6:
-      #     <<: *common_non_publish_filters
       - NodeJS 8:
           <<: *common_non_publish_filters
       - NodeJS 10:
@@ -108,6 +124,7 @@ workflows:
           <<: *common_non_publish_filters
       - NodeJS 14:
           <<: *common_non_publish_filters
+      - "Check for FIXM\x45"
       - oss/lerna_tarballs:
           name: Package tarballs
           <<: *common_non_publish_filters

CHANGELOG.md

@@ -11,6 +11,10 @@ The version headers in this history reflect the versions of Apollo Server itself
 
 > The changes noted within this `vNEXT` section have not been released yet.  New PRs and commits which introduce changes should include an entry in this `vNEXT` section as part of their development.  With few exceptions, the format of the entry should follow convention (i.e., prefix with package name, use markdown `backtick formatting` for package names and code, suffix with a link to the change-set à la `[PR #YYY](https://link/pull/YYY)`, etc.).  When a release is being prepared, a new header will be (manually) created below and the appropriate changes within that release will be moved into the new section.
 
+## v2.24.0
+
+- `apollo-server-core`: Apollo Studio usage reporting uses a more efficient format which sends fewer detailed traces to Apollo's server. This change should not have a major effect on the experience of using Apollo Studio. [PR #4142](https://github.com/apollographql/apollo-server/pull/4142)
+
 ## v2.23.0
 
 - `apollo-server-core`: Add optional argument to `ApolloServer.executeOperation` allowing the caller to manually specify an argument to the `config` function analogous to that provided by integration packages. [PR #4166](https://github.com/apollographql/apollo-server/pull/4166) [Issue #2886](https://github.com/apollographql/apollo-server/issues/2886)

CONTRIBUTING.md

@@ -74,7 +74,7 @@ For significant changes to a repository, it’s important to settle on a design
 
 It’s important that every piece of code in Apollo packages is reviewed by at least one core contributor familiar with that codebase. Here are some things we look for:
 
-1.  **Required CI checks pass.** This is a prerequisite for the review, and it is the PR author's responsibility. As long as the tests don’t pass, the PR won't get reviewed.
+1.  **Required CI checks pass.** This is a prerequisite for the review, and it is the PR author's responsibility. As long as the tests don’t pass, the PR won't get merged. If you're having a challenge getting tests to pass, feel free to ask for help. In addition to running tests, CI will fail if you add the words FIX and ME without a space within them in any file; this lets you add comments during the development process that you can't forget to address before merging.
 2.  **Simplicity.** Is this the simplest way to achieve the intended goal? If there are too many files, redundant functions, or complex lines of code, suggest a simpler way to do the same thing. In particular, avoid implementing an overly general solution when a simple, small, and pragmatic fix will do.
 3.  **Testing.** Do the tests ensure this code won’t break when other stuff changes around it? When it does break, will the tests added help us identify which part of the library has the problem? Did we cover an appropriate set of edge cases? Look at the test coverage report if there is one. Are all significant code paths in the new code exercised at least once?
 4.  **No unnecessary or unrelated changes.** PRs shouldn’t come with random formatting changes, especially in unrelated parts of the code. If there is some refactoring that needs to be done, it should be in a separate PR from a bug fix or feature, if possible.

DEVELOPMENT.md

@@ -57,7 +57,7 @@ Immediately after bumping the version, use the `release:start-ci-publish` npm sc
 > __Note: By default, publishing will be done to the `latest` tag on npm.__  To publish on a different `dist-tag` set the `APOLLO_DIST_TAG` environment variable.  E.g. To publish to the `alpha` tag instead of `latest`, the following command would be `APOLLO_DIST_TAG=alpha npm run release:start-ci-publish`.
 
 ```
-npm run release:start-ci-publish
+APOLLO_DIST_TAG=latest npm run release:start-ci-publish
 ```
 
 #### Step 3b: Manually publishing