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
Just noticed that global dynamic variables are evaluated each time a task is run.
This can indeed become a performance problem. It could at least be documented.
I don't see many workarounds in the meantime.
Commands that take time should not be used in global dynamic variables but rather sub-commands or task dependencies.
Or, you could add conditions in the expression itself. Local variables aren't available, but, for example, the TASK variable is:
This is kind of ugly and cumbersome, but can be used with task namespaces in order to confine the problem to the tasks that actually need that variable.
I suppose long running command results could also be cached, when possible.
version: '3'vars:
MASTER_IP_CMD: | awk '/ master /{print $1}' ./machines.txttasks:
build:
desc: "Build the cluster"cmds:
- ...
- vagrant up # This produces ./machines.txt
- ...certs:gen:
desc: "Generate certificates for components"vars:
MASTER_IP:
sh: | {{.MASTER_IP_CMD}}cmds:
# Your commands heredist:certs:
desc: "Distribute certificates to VMs"vars:
MASTER_IP:
sh: | {{.MASTER_IP_CMD}}cmds:
# Your commands here
Because the MASTER_IP variable is only available after vagrant up, resolving the global variable before running task build will result in error.
This workaround avoids evaluating the global dynamic variable by storing the command as a plain string, deferring its execution until a task runs and actually needs it.
Activity
vctls commentedon Oct 24, 2023
Just noticed that global dynamic variables are evaluated each time a task is run.
This can indeed become a performance problem. It could at least be documented.
I don't see many workarounds in the meantime.
Commands that take time should not be used in global dynamic variables but rather sub-commands or task dependencies.
Or, you could add conditions in the expression itself. Local variables aren't available, but, for example, the
TASKvariable is:This is kind of ugly and cumbersome, but can be used with task namespaces in order to confine the problem to the tasks that actually need that variable.
I suppose long running command results could also be cached, when possible.
user2410 commentedon Jun 2, 2025
I have been using this workaround for the issue.
Because the MASTER_IP variable is only available after
vagrant up, resolving the global variable before runningtask buildwill result in error.This workaround avoids evaluating the global dynamic variable by storing the command as a plain string, deferring its execution until a task runs and actually needs it.
feat(config): add cache to reuse a dynamic var output (#403)