-
-
Notifications
You must be signed in to change notification settings - Fork 60
Architecture decision log
Nat Noordanus edited this page Feb 28, 2024
·
4 revisions
- Simple things should be easy, complex things should be possible.
- Configuration errors should be easy to debug with clear error messages and documentation. The user shouldn't have to deal with stack traces.
- Configuration closest to where an object is defined should have the highest precedence when influencing that object
The include
global config allows additional options and tasks to be loaded from other files. This includes the env
and envfile
global options, which then have to be prioritised in some way relative to other sources of environment variables.
-
env
andenvfile
options are merged across all files, and then applied to all tasks the same- This means tasks defined in the same file as a global
env
object will still use environment variables from the root tasks file with higher precedence - This avoids a surprising situation where overriding a task in the main task file would cause that task to reference different different env vars
- It also avoids potentially making it impossible to directly override env vars of tasks from included files
- It is still possible to use env files to define environment variables differently for different tasks, but it requires naming those variables differently in the env file, then mapping them to the required variable at the task level (considering design tenet 1)
- This means tasks defined in the same file as a global
-
The
env
option has higher precedence thanenvfile
from the same context- This is controversial considering the discussion here on #129, but necessary for consistency, both for historical reasons and to respect design tenet 3.