You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently when the content of an .env file parsed with this action looks like this
KEY=value
DIFFERENT_KEY="value"
OTHER_KEY='value'
the exported env variables contain their delimiting quotes. So the content of KEY, DIFFERENT_KEY and OTHER_KEY are not equal.
Expected Behaviour
This is against the convention of .env (or at least some implementations like the ruby dotenv gem).
I often use the above variants, for example I use single quotes to avoid detecting $ as the start of another ENV variable for example in API_KEY='$ecret'. This now gets parsed differently by dotenv (which yields the string $ecret) and this action (which yields the string with content '$ecret').
Another example happened recently, when we wanted to define a string with trailing spaces like this
SOME_SEPARATOR=" – "
which is parsed as " – " by this action while dotenv parses what we meant: –.
Note: This case does not only have problems with the quote parsing but would also fail otherwise because the action trims whitespace from the parsed values. But that's a different issue.
For us, this resulted in unexpected failing of the CI pipeline, where we used the global-variables action to populate the ENV globally with the content of our .env.test before running any rails command (which prevents the dotenv gem to read the respective variables again). This made the CI behave differntly than running the tests locally.
The text was updated successfully, but these errors were encountered:
Current Behaviour
Currently when the content of an
.env
file parsed with this action looks like thisthe exported env variables contain their delimiting quotes. So the content of
KEY
,DIFFERENT_KEY
andOTHER_KEY
are not equal.Expected Behaviour
This is against the convention of
.env
(or at least some implementations like the ruby dotenv gem).I often use the above variants, for example I use single quotes to avoid detecting
$
as the start of another ENV variable for example inAPI_KEY='$ecret'
. This now gets parsed differently by dotenv (which yields the string$ecret
) and this action (which yields the string with content'$ecret'
).Another example happened recently, when we wanted to define a string with trailing spaces like this
which is parsed as
" – "
by this action while dotenv parses what we meant:–
.Note: This case does not only have problems with the quote parsing but would also fail otherwise because the action trims whitespace from the parsed values. But that's a different issue.
For us, this resulted in unexpected failing of the CI pipeline, where we used the
global-variables
action to populate the ENV globally with the content of our.env.test
before running any rails command (which prevents the dotenv gem to read the respective variables again). This made the CI behave differntly than running the tests locally.The text was updated successfully, but these errors were encountered: