Current behavior:
CYPRESS_ENV is a reserved key used to internally point to the API database to be used for communication from the Test Runner.
We previously included erroring when invalid keys were sent to CYPRESS_ENV because a very unexpected crash would happen in these cases: #1621
But, we do not warn users when setting the CYPRESS_ENV to a valid value that this is a reserved key. This is likely a very small use case (although we had two customers do this), but the consequences are very, very confusing - there is no indication that setting the CYPRESS_ENV would have been a mistake on their part.
Desired behavior:
Why is someone doing this?
They simply want to access an environment variable with the name env. This is a legitimate use case and this is not the first person to set CYPRESS_ENV environment variable. For example, if you do CYPRESS_HOST=foo, you can then access this later using CYPRESS.env('HOST') which will be 'foo'.
Unfortunately, this will not work as intended since CYPRESS_ENV is reserved for internal uses.
We need to warn when using CYPRESS_ENV to set a value other than production, that this is a reserved key and will not do what they intend. We cannot throw because our internal team needs to continue connecting to these API databases for testing and development.
Test code to reproduce
Mostly this problem is exhibited the worst during record since we hit our databases to record then. One example below:
CYPRESS_ENV=test cypress run --record --key abc123
Versions
4.0.1
Current behavior:
CYPRESS_ENVis a reserved key used to internally point to the API database to be used for communication from the Test Runner.We previously included erroring when invalid keys were sent to
CYPRESS_ENVbecause a very unexpected crash would happen in these cases: #1621But, we do not warn users when setting the
CYPRESS_ENVto a valid value that this is a reserved key. This is likely a very small use case (although we had two customers do this), but the consequences are very, very confusing - there is no indication that setting theCYPRESS_ENVwould have been a mistake on their part.Desired behavior:
Why is someone doing this?
They simply want to access an environment variable with the name
env. This is a legitimate use case and this is not the first person to setCYPRESS_ENVenvironment variable. For example, if you doCYPRESS_HOST=foo, you can then access this later usingCYPRESS.env('HOST')which will be 'foo'.Unfortunately, this will not work as intended since
CYPRESS_ENVis reserved for internal uses.We need to warn when using
CYPRESS_ENVto set a value other thanproduction, that this is a reserved key and will not do what they intend. We cannot throw because our internal team needs to continue connecting to these API databases for testing and development.Test code to reproduce
Mostly this problem is exhibited the worst during
recordsince we hit our databases to record then. One example below:Versions
4.0.1