cypress: npm install not working behind corporate firewall

I have troubles installing the npm package behind a corporate firewall due to the download of an executeable included in the post-install of the npm package.

Right now this is how my output looks like:

d:\Workspace\myproj>npm install cypress --save-dev

> cypress@1.0.1 postinstall d:\Workspace\myproj\node_modules\cypress
> node index.js --exec install

Installing Cypress (version: 1.0.1)

 V  Downloaded Cypress
 ×  Unzipping Cypress
   → Cypress Version: 1.0.1
    Finishing Installation
The Cypress App could not be unzipped.

Search for an existing issue or open a GitHub issue at

https://github.com/cypress-io/cypress/issues
----------

Error: end of central directory record signature not found
----------

Probably the downloaded file (zip i guess) gets replaced by a html page of my proxy. therefore the download is successfull, but the unzip fails

I’m hoping for some way to resolve this for all our big banks, goverments and other companies where we don’t blindly trust executables download off the internet.

I don’t know much about the logic behind Cypress, but i noticed the CLI is binary, so if that is the problem, please split the package into 2 different NPM packages. I won’t be needing the CLI anyway.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 26 (12 by maintainers)

Most upvoted comments

Please watch https://github.com/cypress-io/cypress-documentation/issues/121 where I will document CYPRESS_BINARY_VERSION variable

For completeness based on @bahmutov very helpful hint what you need to do (if your network blocks downloads or mess with certificates so that you cannot download from https://) is the following: Download and store somewhere on your network the cypress.zip file. Then expose this file through a URL under https:// Then set either in your environment variables a CYPRESS_BINARY_VERSION=https://someserver/cypress.zip

This is very important as the code that installs cypress has a function that checks if the alternative location for the binary starts with /^https:/

You can also pass at the command prompt the same >set CYPRESS_BINARY_VERSION=https://someserver/cypress.zip&& npm i cypress -D

Ideally this should not be the case as the ceremony is greater than it should. IMHO I think any local path could do such as C:\dev\cypress.zip this way it would be easier to install behind proxies or networks that block zip downloads and point to a local folder. Especially useful for CI servers

why not place the cypress.zip file in the GitHub project? My company does not block zip file downloads from GitHub. CYPRESS_BINARY_VERSION can then point to the zip file on GitHub.

You could do this already via CYPRESS_INSTALL_BINARY environment variable that can be any URL

Sent from my iPhone

On Oct 22, 2017, at 12:11, Byron Thanopoulos notifications@github.com wrote:

Guys this seems the same problem that people are having with chromedriver behind corporate networks. In particular the issue has to do with the usage of https: in the download link The solution for chrome driver is to be able to specify and alternate location for the download through the npm config. So if cypress while installing was checking npm connfig for a “cypress-cdnurl” and that url was local to the network then there woud not be an issue. For completness what I do with Chromedriver is set in my npm config file …chromedriver_cdnurl=http://someServer/chromedriver

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

+1 😦 the link to direct download is blocked behind my organisation’s firewall

Soon. We have been working on the release - had to pause to fix some potential regressions in the release. 🤞

@tgelu is your organization using something like JFrog Artifactory or do they allow direct download from the npm registry ?

When sysadmins blocks downloads from the outside world the solution is to use something like artifactory to act like a proxy with an appropriate network config for that “proxy”. That way they can control what it is goin on on their network instead of letting anybody doing everything.

For example when you run npm install cypress the artifactory will download from the internet and when it will be available your npm client will download it from your local network and not from the internet.

I am pretty sure it is possible to configure artifactory to act the same way with external downloads fired from npm installation scripts.

So npm install cypress will download cypress package from your artifactory and when cypress will try to download from https://download.cypress.io/xxxxx it will download from artifactory also.

I will have to fix this issue also but later. For now the direct download is available to me so i have what i need to convince my hierarchy to heavily use cypress 😃

I don’t think the bug label is appropriate here. At best you (cypress.io) could embark everything in the cypress package (every platform and arch available) but the direct download package is a 500mo stuff which seems too heavy for the npm registry.

In Cypress version 3+ you will need to unset CYPRESS_BINARY_VERSION and use CYPRESS_INSTALL_BINARY instead.

This is the only thing preventing me from using this really nice software. For the time being, I’m stuck with the crappy alternatives 😦

@BasieP - PRs are always welcome! 😄

Guys this seems the same problem that people are having with chromedriver behind corporate networks. In particular the issue has to do with the usage of https: in the download link The solution for chrome driver is to be able to specify and alternate location for the download through the npm config. So if cypress while installing was checking npm connfig for a "cypress-cdnurl" and that url was local to the network then there woud not be an issue. For completness what I do with Chromedriver is set in my npm config filechromedriver_cdnurl=http://someServer/chromedriver ..