go/task
go/task
1
0
Fork 0
mirror of https://github.com/go-task/task.git synced 2025-01-10 04:18:53 +02:00
Code Issues Releases Activity
300376b0b1
task/testdata/vars/Taskfile.yml

56 lines
1.5 KiB
YAML
Raw Normal View History

Write tests for variables
2017-03-25 15:51:30 +02:00
default:
deps: [hello]
hello:
Fix "=" not being reconized in variables/environment variables Fixes #19
2017-03-25 16:01:44 +02:00
deps: [set-equal]
Write tests for variables
2017-03-25 15:51:30 +02:00
cmds:
- echo {{.FOO}} > foo.txt
- echo {{.BAR}} > bar.txt
use YAML for dynamix variable instead of $ prefix $ prefix still works but is now deprecated before: VAR: $echo var after: VAR: sh: echo bar closes #46
2017-07-15 20:28:59 +02:00
- echo {{.BAZ}} > baz.txt
Reintroduce template evaluation in variables 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.
2017-07-20 09:05:37 +02:00
- echo '{{.TMPL_FOO}}' > tmpl_foo.txt
- echo '{{.TMPL_BAR}}' > tmpl_bar.txt
- echo '{{.TMPL_FOO2}}' > tmpl_foo2.txt
- echo '{{.TMPL_BAR2}}' > tmpl_bar2.txt
- echo '{{.SHTMPL_FOO}}' > shtmpl_foo.txt
- echo '{{.SHTMPL_FOO2}}' > shtmpl_foo2.txt
- echo '{{.NESTEDTMPL_FOO}}' > nestedtmpl_foo.txt
- echo '{{.NESTEDTMPL_FOO2}}' > nestedtmpl_foo2.txt
Write tests for variables
2017-03-25 15:51:30 +02:00
- echo {{.FOO2}} > foo2.txt
- echo {{.BAR2}} > bar2.txt
use YAML for dynamix variable instead of $ prefix $ prefix still works but is now deprecated before: VAR: $echo var after: VAR: sh: echo bar closes #46
2017-07-15 20:28:59 +02:00
- echo {{.BAZ2}} > baz2.txt
Reintroduce template evaluation in variables 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.
2017-07-20 09:05:37 +02:00
- echo '{{.TMPL2_FOO}}' > tmpl2_foo.txt
- echo '{{.TMPL2_BAR}}' > tmpl2_bar.txt
- echo '{{.TMPL2_FOO2}}' > tmpl2_foo2.txt
- echo '{{.TMPL2_BAR2}}' > tmpl2_bar2.txt
- echo '{{.SHTMPL2_FOO}}' > shtmpl2_foo.txt
- echo '{{.SHTMPL2_FOO2}}' > shtmpl2_foo2.txt
- echo '{{.NESTEDTMPL2_FOO2}}' > nestedtmpl2_foo2.txt
Fix "=" not being reconized in variables/environment variables Fixes #19
2017-03-25 16:01:44 +02:00
- echo {{.EQUAL}} > equal.txt
Reintroduce template evaluation in variables 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.
2017-07-20 09:05:37 +02:00
- echo {{.OVERRIDE}} > override.txt
Write tests for variables
2017-03-25 15:51:30 +02:00
vars:
FOO: foo
BAR: $echo bar
use YAML for dynamix variable instead of $ prefix $ prefix still works but is now deprecated before: VAR: $echo var after: VAR: sh: echo bar closes #46
2017-07-15 20:28:59 +02:00
BAZ:
sh: echo baz
Reintroduce template evaluation in variables 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.
2017-07-20 09:05:37 +02:00
TMPL_FOO: "{{.FOO}}"
TMPL_BAR: "{{.BAR}}"
TMPL_FOO2: "{{.FOO2}}"
TMPL_BAR2: "{{.BAR2}}"
SHTMPL_FOO:
sh: "echo '{{.FOO}}'"
SHTMPL_FOO2:
sh: "echo '{{.FOO2}}'"
NESTEDTMPL_FOO: "{{.TMPL_FOO}}"
NESTEDTMPL_FOO2: "{{.TMPL2_FOO2}}"
OVERRIDE: "bar"
Fix "=" not being reconized in variables/environment variables Fixes #19
2017-03-25 16:01:44 +02:00
set-equal:
set: EQUAL
cmds:
- echo foo=bar
Reintroduce template evaluation in variables 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.
2017-07-20 09:05:37 +02:00
invalid-var-tmpl:
vars:
CHARS: "abcd"
INVALID: "{{range .CHARS}}no end"
Reference in New Issue Copy Permalink