It was always running in the main Taskfile dir, even when the variable was
declared in an included taskfile in another directory or when task had a
custom dir.
Closes#384
Label is an alternative name for task that replace it when printed in following context eg.:
- log: when given task is up to date and is skipped from execution
- log: when given task is NOT up to date (`--status` command)
- in `--summary` and `--list` commands output
This shouldn't have any behavior changes for now. This is a code
refactor that should allow us to do further improvements on how
variables are handled, specially regarding respecting the declaration
order in Taskfiles, which should make it easier for the users.
Initial work on #218
So a path like this works: $GOPATH/src/github.com/go-task/task
Allowing of "~" was also implemented. See #74 and baac067a1a0aa0d387b60a19977c901a3863fe97
Fixes#116
Instead of giving an error on multiline results from sh, the results are
now stored as is, except that the last newline is stripped away to make
the output of most commands easy to use in shell commands.
Two helper functions have been added to help deal with multi-line
results. In addition, previous PascalCase template function names have
been renamed to camelCase for consistency with the sprig lib.
With a recent commit, template evaluation for variables in tasks got
broken. This reindroudces temmplate evaluation in taks, and resolves
a series of issues that where previouisly present on master, such as:
- Taskvars did not get evaluated as templates.
- Taskvars would, in contrast to the documentation, _override_ task
variables for the taks called directly via `Executor.Run(args
...string)`. This caused different behaviour in the "default" task
v.s. other tasks.
This commit ensures:
- Priority order for variables is now according to the documentation,
also for the "default" task.
- Variables gets resolved in a particular order to ensure logical
access to varaibles on template compile time, and that template
compilation finds place _before_ resolution of dynamic variables.
This change also allows the following to work:
task:
vars:
A: "52"
B: "{{.A}}"
However, the following will always replace C with the uncompiled
`{{.A}}`:
task:
vars:
A: "52"
C: "{{.B}}"
B: "{{.A}}"
Several tests have also been added to prevent this feature from breaking
again. This should hopefully finally resolve issue #40.
this is the first big step of #45
now t.ReplaceVariable will return a copy of the task, but with variables
replaced
now we don't need to replace variables everywhere in the code, and will
make other refactorings easier
