Merge branch 'develop'

.eslintrc.json

@@ -4,6 +4,5 @@
   ],
   "extends": [
     "plugin:@cypress/dev/general"
-  ],
-  "rules": {}
+  ]
 }

CONTRIBUTING.md → .github/CONTRIBUTING.md

@@ -5,8 +5,8 @@ Thanks for taking the time to contribute! :smile:
 **Once you learn how to use Cypress, you can contribute in many ways:**
 
 - Join the [Cypress Gitter chat](https://on.cypress.io/chat) and answer questions. Teaching others how to use Cypress is a great way to learn more about how it works.
-- Blog about Cypress. We display blogs featuring Cypress on our [Examples](https://on.cypress.io/examples) page. If you'd like your blog featured, [open a PR to add it to our docs](https://github.com/cypress-io/cypress-documentation/blob/develop/CONTRIBUTING.md#adding-examples).
-- Write some documentation or improve our existing docs. Know another language? You can help us translate them. See our [guide to contributing to our docs](https://github.com/cypress-io/cypress-documentation/blob/master/CONTRIBUTING.md).
+- Blog about Cypress. We display blogs featuring Cypress on our [Examples](https://on.cypress.io/examples) page. If you'd like your blog featured, [open a PR to add it to our docs](https://github.com/cypress-io/cypress-documentation/blob/develop/.github/CONTRIBUTING.md#adding-examples).
+- Write some documentation or improve our existing docs. Know another language? You can help us translate them. See our [guide to contributing to our docs](https://github.com/cypress-io/cypress-documentation/blob/master/.github/CONTRIBUTING.md).
 - Give a talk about Cypress. [Contact us](mailto:support@cypress.io) ahead of time and we'll send you some swag. :shirt:
 
 **Want to dive deeper into how Cypress works? There are several ways you can help with the development of Cypress:**
@@ -53,7 +53,7 @@ Build status | Description
 
 ## Code of Conduct
 
-All contributors are expecting to abide by our [Code of Conduct](CODE_OF_CONDUCT.md).
+All contributors are expecting to abide by our [Code of Conduct](./CODE_OF_CONDUCT.md).
 
 ## Opening Issues
 
@@ -225,7 +225,7 @@ Some issues are resolved by the community, by giving some guidance or a workarou
 ## Writing Documentation
 
 Cypress documentation lives in a separate repository with its own dependencies and build tools.
-See [Documentation Contributing Guideline](https://github.com/cypress-io/cypress-documentation/blob/master/CONTRIBUTING.md).
+See [Documentation Contributing Guideline](https://github.com/cypress-io/cypress-documentation/blob/master/.github/CONTRIBUTING.md).
 
 ## Writing code
 
@@ -501,7 +501,7 @@ After a PR has been opened for a dependency update, our `cypress-bot` will comme
 
 ## Deployment
 
-We will try to review and merge pull requests quickly. After merging we will try releasing a new version. If you want to know our build process or build your own Cypress binary, read [DEPLOY.md](DEPLOY.md)
+We will try to review and merge pull requests quickly. After merging we will try releasing a new version. If you want to know our build process or build your own Cypress binary, read [DEPLOY.md](./DEPLOY.md)
 
 ## Known problems
 

.github/PULL_REQUEST_REVIEW_COMMENT.md

@@ -0,0 +1,43 @@
+<!--
+  this comment will be posted automatically by Cypress bot whenever someone opens a pull request,
+  and it helps the reviewer from Cypress team to ensure the change is solid.
+-->
+Thanks for the contribution! Below are some guidelines Cypress uses when doing PR reviews.
+
+- Please write \`[WIP]\` in the title of your Pull Request if your PR is not ready for review - someone will review your PR as soon as the \`[WIP]\` is removed.
+- Please familiarize yourself with the PR Review Checklist and feel free to make updates on your PR based on these guidelines.
+
+## PR Review Checklist
+
+If any of the following requirements can't be met, leave a comment in the review selecting 'Request changes', otherwise 'Approve'.
+
+### User Experience
+
+- The feature/bugfix is self-documenting from within the product.
+- The change provides the end user with a way to fix their problem (no dead ends).
+
+### Functionality
+
+- The code works and performs its intended function with the correct logic.
+- Performance has been factored in (for example, the code cleans up after itself to not cause memory leaks).
+- The code guards against edge cases and invalid input and has tests to cover it.
+
+### Maintainability
+
+- The code is readable (too many nested 'if's are a bad sign).
+- Names used for variables, methods, etc, clearly describe their function.
+- The code is easy to understood and there are relevant comments explaining.
+- New algorithms are documented in the code with link(s) to external docs (flowcharts, w3c, chrome, firefox).
+- There are comments containing link(s) to the addressed issue (in tests and code).
+
+### Quality
+
+- The change does not reimplement code.
+- There's not a module from the ecosystem that should be used instead.
+- There is no redundant or duplicate code.
+- There are no irrelevant comments left in the code.
+- Tests are testing the code’s intended functionality in the best way possible.
+
+### Internal
+
+- The original issue has been tagged with a release in ZenHub.

.github/PULL_REQUEST_REVIEW_COMMENT_FOR_DEPENDENCY_UPDATE.md

@@ -0,0 +1,18 @@
+<!--
+  this comment will be posted automatically by Cypress bot whenever a dependency update pull request is opened,
+  and it helps the reviewer from Cypress team to ensure the update won't have unexpected consequences.
+-->
+Below are some guidelines Cypress uses when reviewing dependency updates.
+
+## Dependency Update Instructions
+
+- Read through the entire changelog of the dependency's changes. If a changelog is not available, check every commit made to the dependency. **NOTE** - do not rely on semver to indicate breaking changes - every product does not follow this standard.
+- Add a PR review comment noting any relevant changes in the dependency.
+- If any of the following requirements cannot be met, leave a comment in the review selecting 'Request changes', otherwise 'Approve'.
+
+## Dependency Updates Checklist
+
+- Code using the dependency has been updated to accommodate any breaking changes
+- The dependency still supports the version of Node that the package requires.
+- The PR been tagged with a release in ZenHub.
+- Appropriate labels have been added to the PR (for example: label \`type: breaking change\` if it is a breaking change)

PULL_REQUEST_TEMPLATE.md → .github/PULL_REQUEST_TEMPLATE.md

@@ -1,7 +1,7 @@
 <!-- 
 Thanks for contributing!
 Read our contribution guidelines here: 
-https://github.com/cypress-io/cypress/blob/develop/CONTRIBUTING.md 
+https://github.com/cypress-io/cypress/blob/develop/.github/CONTRIBUTING.md 
 -->
 
 <!-- Example: "Closes #1234" -->
@@ -38,6 +38,7 @@ Delete tasks if they are not applicable.
 -->
 
 - [ ] Have tests been added/updated?
+- [ ] Has the original issue been tagged with a release in ZenHub? <!-- (internal team only)-->
 - [ ] Has a PR for user-facing changes been opened in [`cypress-documentation`](https://github.com/cypress-io/cypress-documentation)? <!-- Link to PR here -->
 - [ ] Have API changes been updated in the [`type definitions`](cli/types/index.d.ts)?
 - [ ] Have new configuration options been added to the [`cypress.schema.json`](cli/schema/cypress.schema.json)?

DEPLOY.md

@@ -1,7 +1,7 @@
 # Deployment
 
 Anyone can build the binary and NPM package, but you can only deploy the Cypress application
-and publish the NPM module `cypress` if you are a member of `cypress` NPM organization.
+and publish the NPM module `cypress` if you are a member of the `cypress` NPM organization.
 
 > :information_source: See the [publishing](#publishing) section for how to build, test and publish a
 new official version of the binary and `cypress` NPM package.
@@ -12,7 +12,11 @@ We build the NPM package and binary on all major platforms (Linux, Mac, Windows)
 providers. In order to set the version while building we have to set the environment variable
 with the new version on each CI provider *before starting the build*.
 
-Use script command `npm run set-next-ci-version` to do this.
+Use the script command below to to do this.
+
+```shell
+npm run set-next-ci-version
+```
 
 ## Building
 
@@ -28,12 +32,12 @@ Building a new NPM package is very quick.
 The steps above:
 
 - Build the `cypress` NPM package
-- Transpiles the code into ES5 version to be compatible with the common Node versions
-- Puts the result into the `cli/build` folder.
+- Transpile the code into ES5 to be compatible with the common Node versions
+- Put the result into the [`cli/build`](./cli/build) folder.
 
 You could publish from there, but first you need to build and upload the binary with the *same version*;
 this guarantees that when users do `npm i cypress@<x.y.z>` they can download the binary
-with the same version `x.y.z` from Cypress CDN service.
+with the same version `x.y.z` from Cypress's CDN service.
 
 ### Building the binary
 
@@ -43,68 +47,64 @@ First, you need to build, zip and upload the application binary to the Cypress s
 
 You can use a single command to do all tasks at once:
 
-```
+```shell
 npm run binary-deploy
 ```
 
-You can also specify each command separately:
+Or you can specify each command separately:
 
-```
+```shell
 npm run binary-build
 npm run binary-zip
 npm run binary-upload
 ```
 
 You can pass options to each command to avoid answering questions, for example
 
-```
+```shell
 npm run binary-deploy -- --platform darwin --version 0.20.0
 npm run binary-upload -- --platform darwin --version 0.20.0 --zip cypress.zip
 ```
 
 If something goes wrong, see the debug messages using the `DEBUG=cypress:binary ...` environment
 variable.
 
-Because we had many problems reliably zipping the built binary, for now we need
-to build both the Mac and Linux binary from Mac (Linux binary is built using
-a Docker container), then zip it **from Mac**, then upload it.
+Because we had many problems reliably zipping the built binary, for now we need to build both the Mac and Linux binary from Mac (Linux binary is built using a Docker container), then zip it **from Mac**, then upload it.
 
 ### Building Linux binary in Docker
 
 If you are using a Mac you can build the linux binary if you have docker installed.
 
-```
+```shell
 npm run binary-build-linux
 ```
 
 ## Publishing
 
 ### Before Publishing a New Version
 
-In order to publish a new `cypress` package to the NPM registry, we must build and test it across
-multiple platforms and test projects. This makes publishing *directly* into the NPM registry
-impossible. Instead, we have CI set up to do the following on every commit to `develop`:
+In order to publish a new `cypress` package to the NPM registry, we must build and test it across multiple platforms and test projects. This makes publishing *directly* into the NPM registry impossible. Instead, we have CI set up to do the following on every commit to `develop`:
 
 1. Build the NPM package with the new target version baked in.
 2. Build the Linux/Mac binaries on CircleCI and build Windows on AppVeyor.
-3. Upload the binaries and the new NPM package to the `cdn.cypress.io` under the "beta" folder.
+3. Upload the binaries and the new NPM package to `cdn.cypress.io` under the "beta" folder.
 4. Launch the test projects like [cypress-test-node-versions](https://github.com/cypress-io/cypress-test-node-versions) and [cypress-test-example-repos](https://github.com/cypress-io/cypress-test-example-repos) using the newly-uploaded package & binary instead of installing from the NPM registry. That installation looks like this:
-    ```
+    ```shell
     export CYPRESS_INSTALL_BINARY=https://cdn.../binary/<new version>/<commit hash>/cypress.zip
     npm i https://cdn.../npm/<new version>/<commit hash>/cypress.tgz
     ```
 
-Multiple test projects are launched for each target operating system, and the results are reported
-back to GitHub using status checks so that it is easy to see if a change has broken real-world usage
+Multiple test projects are launched for each target operating system and the results are reported
+back to GitHub using status checks so that you can see if a change has broken real-world usage
 of Cypress. You can see the progress of the test projects by opening the status checks on GitHub:
 
 ![Screenshot of status checks](https://i.imgur.com/AsQwzgO.png)
 
-Once all test projects are reliably working with new changes, publishing can proceed.
+Once the `develop` branch for all test projects are reliably passing with the new changes, publishing can proceed.
 
 ### Steps to Publish a New Version
 
-0. Make sure that if there is a new [`cypress-example-kitchensink`][https://github.com/cypress-io/cypress-example-kitchensink/releases] version, the corresponding dependency in `packages/example` has been updated to that new version.
+0. Make sure that if there is a new [`cypress-example-kitchensink`][https://github.com/cypress-io/cypress-example-kitchensink/releases] version, the corresponding dependency in [`packages/example`](./packages/example) has been updated to that new version.
 1. Make sure that you have the correct environment variables set up before proceeding.
     - You'll need Cypress AWS access keys in `aws_credentials_json`, which looks like this:
         ```text
@@ -118,42 +118,41 @@ Once all test projects are reliably working with new changes, publishing can pro
     - Tip: Use [as-a](https://github.com/bahmutov/as-a) to manage environment variables for different situations.
 2. Use the `move-binaries` script to move the binaries for `<commit sha>` from `beta` to the `desktop` folder
     for `<new target version>`
-    ```
+    ```shell
     npm run move-binaries -- --sha <commit sha> --version <new target version>
     ```
-3. Publish the new NPM package under the dev tag. The unique link to the package file `cypress.tgz`
-    is the one already tested above. You can publish to the NPM registry straight from the URL:
-    ```
+3. Publish the new NPM package under the `dev` tag. The unique link to the package file `cypress.tgz` is the one already tested above. You can publish to the NPM registry straight from the URL:
+    ```shell
     npm publish https://cdn.../npm/3.4.0/<long sha>/cypress.tgz --tag dev
     ```
 4. Double-check that the new version has been published under the `dev` tag using `npm info cypress` or [available-versions](https://github.com/bahmutov/available-versions):
-    ```
+    ```shell
     dist-tags:
     dev: 3.4.0     latest: 3.3.2
     ```
-5. Test `cypress@3.4.0` again to make sure everything is working. You can trigger test projects
-    from the command line (if you have the appropriate permissions)
+5. Test `cypress@3.4.0` again to make sure everything is working. You can trigger test projects from the command line (if you have the appropriate permissions)
     ```
     node scripts/test-other-projects.js --npm cypress@3.4.0 --binary 3.4.0
     ```
 6. Update and publish the changelog and any release-specific documentation changes in [cypress-documentation](https://github.com/cypress-io/cypress-documentation).
 7. Make the new NPM version the "latest" version by updating the dist-tag `latest` to point to the new version:
-    ```
+    ```shell
     npm dist-tag add cypress@3.4.0
     ```
-8. Run `binary-release` to update the download server's manifest, set the next CI version, and create an empty version commit:
-    ```
+8. Run `binary-release` to update the download the server's manifest, set the next CI version, and create an empty version commit:
+    ```shell
     npm run binary-release -- --version 3.4.0 --commit`
     ```
 9. If needed, push out any updated changes to the links manifest to [`on.cypress.io`](https://github.com/cypress-io/cypress-services/tree/develop/packages/on).
 10. If needed, deploy the updated [`cypress-example-kitchensink`][cypress-example-kitchensink] to `example.cypress.io` by following [these instructions under "Deployment"](./packages/example/README.md).
 11. Close the release in [ZenHub](https://app.zenhub.com/workspaces/test-runner-5c3ea3baeb1e75374f7b0708/reports/release).
-12. Bump `version` in `package.json` and commit it to `develop` using a commit message like `release 3.4.0 [skip ci]`
+12. Bump `version` in [`package.json`](package.json) and commit it to `develop` using a commit message like `release 3.4.0 [skip ci]`
 13. Tag this commit with `v3.4.0` and push that tag up.
 14. Merge `develop` into `master` and push that branch up.
 15. Using [cypress-io/release-automations][release-automations]:
     - Publish GitHub release to [cypress-io/cypress/releases](https://github.com/cypress-io/cypress/releases) using package `set-releases` (see its README for details).
     - Add a comment to each GH issue that has been resolved with the new published version using package `issues-in-release` (see its README for details)
+16. Publish a new docker image in [`cypress-docker-images`](https://github.com/cypress-io/cypress-docker-images) under `included` for the new cypress version.
 
 Take a break, you deserve it! :sunglasses:
 

README.md

@@ -53,7 +53,7 @@ npm install cypress --save-dev
 - [![CircleCI](https://circleci.com/gh/cypress-io/cypress/tree/develop.svg?style=svg)](https://circleci.com/gh/cypress-io/cypress/tree/develop) - `develop` branch
 - [![CircleCI](https://circleci.com/gh/cypress-io/cypress/tree/master.svg?style=svg)](https://circleci.com/gh/cypress-io/cypress/tree/master) - `master` branch
 
-Please see our [Contributing Guideline](/CONTRIBUTING.md) which explains repo organization, linting, testing, and other steps.
+Please see our [Contributing Guideline](.github/CONTRIBUTING.md) which explains repo organization, linting, testing, and other steps.
 
 ## License
 

cli/__snapshots__/errors_spec.js

@@ -29,6 +29,7 @@ Cypress Version: 1.2.3
 exports['errors individual has the following errors 1'] = [
   "CYPRESS_RUN_BINARY",
   "binaryNotExecutable",
+  "childProcessKilled",
   "failedDownload",
   "failedUnzip",
   "invalidCacheDirectory",
@@ -71,3 +72,27 @@ If you are using Docker, we provide containers with all required dependencies in
 Platform: test platform (Foo-OsVersion)
 Cypress Version: 1.2.3
 `
+
+exports['child kill error object'] = {
+  "description": "The Test Runner unexpectedly exited via a exit event with signal SIGKILL",
+  "solution": "Please search Cypress documentation for possible solutions:\n\n  https://on.cypress.io\n\nCheck if there is a GitHub issue describing this crash:\n\n  https://github.com/cypress-io/cypress/issues\n\nConsider opening a new issue."
+}
+
+exports['Error message'] = `
+The Test Runner unexpectedly exited via a exit event with signal SIGKILL
+
+Please search Cypress documentation for possible solutions:
+
+https://on.cypress.io
+
+Check if there is a GitHub issue describing this crash:
+
+https://github.com/cypress-io/cypress/issues
+
+Consider opening a new issue.
+
+----------
+
+Platform: test platform (Foo-OsVersion)
+Cypress Version: 1.2.3
+`

cli/__snapshots__/spawn_spec.js

@@ -0,0 +1,18 @@
+exports['lib/exec/spawn .start detects kill signal exits with error on SIGKILL 1'] = `
+The Test Runner unexpectedly exited via a exit event with signal SIGKILL
+
+Please search Cypress documentation for possible solutions:
+
+https://on.cypress.io
+
+Check if there is a GitHub issue describing this crash:
+
+https://github.com/cypress-io/cypress/issues
+
+Consider opening a new issue.
+
+----------
+
+Platform: darwin (Foo-OsVersion)
+Cypress Version: 0.0.0
+`