dotnev variable value calculation
Hello !
I canot find anything in the docs so I decided to ask here:
Is there some sort of prioirity in the dotenv declaraion?
Like if I declare it to be
['.env', '$HOME/.env']
and have DEPLOY="true"
in .env
but DEPLOY="false"
in $HOME/.env
what will be the value of DEPLOY
in the end?
- true
because .env
is first so its values take precedence?
- false
because $HOME/.env
is last so its value override the rest?Solution:Jump to solution
Hello !
It'll be true. Dotenv files are processed in the order they are defined. If an environment variable already exists, it won't be overridden....
2 Replies
Solution
Hello !
It'll be true. Dotenv files are processed in the order they are defined. If an environment variable already exists, it won't be overridden.
this is kinda weird though because i am seeing the opposite.
I am trying to use it in github CI/CD automation (as part of a custom github action).
My idea is for the user to provide a .env file with configuration (i.e.
DEPLOY=true
) but if the user don't do that I still get to set it up from my own .env file.
So I tested it and if what you are saying was true it should have been true
but was actually still false
...
This is the specific example:
Here is the code:
In the client's side's uci.env
the setting is TERRAFORM_CHECKS=false
In the action's side is still TERRAFORM_CHECKS=true
The step gets executed... 😦
Hmmm!
You are correct that the final value is false
.
And the precondition should also be false unless I am declaring it wrong.
i think I am trying to achieve conditional logic where preconditions is not the proper use case. i will mark the answer above as solved as this is the dotenv question after all.