Repository navigation
Requires does not check if a variable is set #2243
Description
Description
Requires does not check if a variable is set, it only checks is a variable is "present". As a result, variables which are set to "null/nil" will pass the required check.
Version
3.43.2
Operating system
Linux (WSL)
Experiments Enabled
No response
Example Taskfile
version: '3'
tasks:
default:
vars:
A: null
B: '{{.B}}'
env:
A: '{{.A}}'
B: '{{.B}}'
C: '{{.C}}'
cmds:
- echo "$A"
- echo "$B"
- echo "$C"
requires:
#vars: [A, B, C]
vars: [A, B]Example output:
$ task
task: [default] echo "$A"
task: [default] echo "$B"
task: [default] echo "$C"Obviously, none of the variables are set. Swap the comment line on the requires constraint to observe the behavior change.
The related code is here:
Line 17 in a459eea
... where it is observed that the content of variables is not checked. I have read though the PR for this feature and did not notice any conversation about this scenario. I think the documentation explains the expectation correctly:
List of variable or environment variable names that must be set if this task is to execute and run[period missing]
I appreciate that setting a variable to nil can be considered as being set ... but with how templating works in Task, I think set means set to something other than . For example here there is no difference when A is not set, or set to nil ... the default condition will be taken:
A: '{{.A | default "A"}}'
Activity
timrulebosch commentedon Jun 4, 2025
The fundamental problem behind this is that a variable has no
nilrepresentation. This is apparently because the tempting system will raise errors in such cases ... and therefore anynil(nullin yaml) value will be set to an empty string. Ok.I've developed a fix for that, i.e. the requires feature checks for a "nil" value. That works ... however it introduces a conflict to #1962 and #1962 and #2033 ... which moves the requires check before the task is compiled. Which means tasks like this fail with the fix I developed:
@vmaerten Do you have any thoughts? As far as I can see, compiling a task is ... doing much more than tempting variables. And so that causes cases like:
require-before-compile: requires: vars: [ MY_VAR ] cmd: | {{range .MY_VAR | splitList " " }} echo {{.}} {{end}}to fail (if task compile is moved before requires checks).
Ideally I would "detect" the
shportion, or compile variables only before doing the requires check.timrulebosch commentedon Jun 5, 2025
I've figured out what was happening and updated the related PR.
CJKay commentedon Jan 23, 2026
Both "requires defined" and "requires non-empty" are valid preconditions. Updating the default behaviour would be a breaking change, but could
requiresinstead be expanded to support a constrained set of conditions? e.g.:A more radical (but significantly more flexible) alternative might be to allow it to evaluate shell or boolean template expressions in the context before
varshas been evaluated:Conceptually, this overlaps near-totally with
preconditions, except thatrequiresruns before all variables have been evaluated, whilstpreconditionsruns after.