chore: sync translations (#1440)

This commit is contained in:
task-bot
2024-01-10 22:19:58 -03:00
committed by GitHub
parent 33f90a8c16
commit f108fdd580
127 changed files with 4273 additions and 2313 deletions

View File

@@ -0,0 +1,206 @@
---
slug: /experiments/any-variables/
---
# Any Variables (#1415)
:::caution
All experimental features are subject to breaking changes and/or removal _at any
time_. We strongly recommend that you do not use these features in a production
environment. They are intended for testing and feedback only.
:::
:::warning
This experiment breaks the following functionality:
- Dynamically defined variables (using the `sh` keyword)
:::
:::info
To enable this experiment, set the environment variable:
`TASK_X_ANY_VARIABLES=1`. Check out [our guide to enabling experiments
][enabling-experiments] for more information.
:::
Currently, Task only supports string variables. This experiment allows you to
specify and use the following variable types:
- `string`
- `bool`
- `int`
- `float`
- `array`
- `map`
This allows you to have a lot more flexibility in how you use variables in
Task's templating engine. For example:
Evaluating booleans:
```yaml
version: 3
tasks:
foo:
vars:
BOOL: false
cmds:
- '{{if .BOOL}}echo foo{{end}}'
```
Arithmetic:
```yaml
version: 3
tasks:
foo:
vars:
INT: 10
FLOAT: 3.14159
cmds:
- 'echo {{add .INT .FLOAT}}'
```
Ranging:
```yaml
version: 3
tasks:
foo:
vars:
ARRAY: [1, 2, 3]
cmds:
- 'echo {{range .ARRAY}}{{.}}{{end}}'
```
There are many more templating functions which can be used with the new types of
variables. For a full list, see the [slim-sprig][slim-sprig] documentation.
## Looping over variables
Previously, you would have to use a delimiter separated string to loop over an
arbitrary list of items in a variable and split them by using the `split` subkey
to specify the delimiter:
```yaml
version: 3
tasks:
foo:
vars:
LIST: 'foo,bar,baz'
cmds:
- for:
var: LIST
split: ','
cmd: echo {{.ITEM}}
```
Because this experiment adds support for "collection-type" variables, the `for`
keyword has been updated to support looping over arrays directly:
```yaml
version: 3
tasks:
foo:
vars:
LIST: [foo, bar, baz]
cmds:
- for:
var: LIST
cmd: echo {{.ITEM}}
```
This also works for maps. When looping over a map we also make an additional
`{{.KEY}}` variable availabe that holds the string value of the map key.
Remember that maps are unordered, so the order in which the items are looped
over is random:
```yaml
version: 3
tasks:
foo:
vars:
MAP:
KEY_1:
SUBKEY: sub_value_1
KEY_2:
SUBKEY: sub_value_2
KEY_3:
SUBKEY: sub_value_3
cmds:
- for:
var: MAP
cmd: echo {{.KEY}} {{.ITEM.SUBKEY}}
```
String splitting is still supported and remember that for simple cases, you have
always been able to loop over an array without using variables at all:
```yaml
version: 3
tasks:
foo:
cmds:
- for: [foo, bar, baz]
cmd: echo {{.ITEM}}
```
## Migration
Taskfiles with dynamically defined variables via the `sh` subkey will no longer
work with this experiment enabled. In order to keep using dynamically defined
variables, you will need to migrate your Taskfile to use the new syntax.
Previously, you might have defined a dynamic variable like this:
```yaml
version: 3
task:
foo:
vars:
CALCULATED_VAR:
sh: 'echo hello'
cmds:
- 'echo {{.CALCULATED_VAR}}'
```
With this experiment enabled, you will need to remove the `sh` subkey and define
your command as a string that begins with a `$`. This will instruct Task to
interpret the string as a command instead of a literal value and the variable
will be populated with the output of the command. For example:
```yaml
version: 3
task:
foo:
vars:
CALCULATED_VAR: '$echo hello'
cmds:
- 'echo {{.CALCULATED_VAR}}'
```
If your current Taskfile contains a string variable that begins with a `$`, you
will now need to escape the `$` with a backslash (`\`) to stop Task from
executing it as a command.
<!-- prettier-ignore-start -->
[enabling-experiments]: /experiments/#enabling-experiments
[slim-sprig]: https://go-task.github.io/slim-sprig/
<!-- prettier-ignore-end -->

View File

@@ -15,14 +15,15 @@ In order to allow Task to evolve quickly, we roll out breaking changes to minor
You can view a full list of active experiments in the "Experiments" section of the sidebar.
You can enable an experimental feature by:
## Enabling Experiments
You can enable an experimental feature by doing one of the following:
1. Using the relevant environment variable in front of a task command. For example, `TASK_X_{FEATURE}=1 task {my-task}`. This is intended for one-off invocations of Task to test out experimental features.
1. Using the relevant environment variable in your "dotfiles" (e.g. `.bashrc`, `.zshrc` etc.). This is intended for permanently enabling experimental features in your environment.
1. Creating a `.env` file in the same directory as your root Taskfile that contains the relevant environment variables. e.g.
1. Creating a `.env` file in the same directory as your root Taskfile that contains the relevant environment variables. This allows you to enable an experimental feature at a project level. For example:
```shell
# .env
```shell title=".env"
TASK_X_FEATURE=1
```

View File

@@ -2,12 +2,27 @@
slug: /experiments/gentle-force/
---
# Gentle Force
# Gentle Force (#1200)
- Issue: [#1200][gentle-force-experiment]
- Environment variable: `TASK_X_FORCE=1`
- Breaks:
- `--force` flag
:::caution
All experimental features are subject to breaking changes and/or removal _at any time_. We strongly recommend that you do not use these features in a production environment. They are intended for testing and feedback only.
:::
:::warning
This experiment breaks the following functionality:
- The `--force` flag
:::
:::info
To enable this experiment, set the environment variable: `TASK_X_FORCE=1`. Check out [our guide to enabling experiments ][enabling-experiments] for more information.
:::
The `--force` flag currently forces _all_ tasks to run regardless of the status checks. This can be useful, but we have found that most of the time users only expect the direct task they are calling to be forced and _not_ all of its dependant tasks.
@@ -18,4 +33,4 @@ If you want to migrate, but continue to force all dependant tasks to run, you sh
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[gentle-force-experiment]: https://github.com/go-task/task/issues/1200
[enabling-experiments]: /experiments/#enabling-experiments

View File

@@ -2,10 +2,19 @@
slug: /experiments/remote-taskfiles/
---
# Remote Taskfiles
# Remote Taskfiles (#1317)
- Issue: [#1317][remote-taskfiles-experiment]
- Environment variable: `TASK_X_REMOTE_TASKFILES=1`
:::caution
All experimental features are subject to breaking changes and/or removal _at any time_. We strongly recommend that you do not use these features in a production environment. They are intended for testing and feedback only.
:::
:::info
To enable this experiment, set the environment variable: `TASK_X_REMOTE_TASKFILES=1`. Check out [our guide to enabling experiments ][enabling-experiments] for more information.
:::
This experiment allows you to specify a remote Taskfile URL when including a Taskfile. For example:
@@ -53,5 +62,5 @@ By default, Task will timeout requests to download remote files after 10 seconds
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317
[enabling-experiments]: /experiments/#enabling-experiments
[man-in-the-middle-attacks]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack

View File

@@ -6,15 +6,34 @@ sidebar_position: -1 #Always push to the top
draft: true #Hide in production
---
# {Name of Experiment}
# \{Name of Experiment\} (#\{Issue\})
- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
- Environment variable: `TASK_X_{feature}`
- Breaks:
- {list any existing functionality that will be broken by this experiment}
- Deprecations:
- {link to any deprecation pages related to this experiment}
:::caution
{Short description of the feature}
All experimental features are subject to breaking changes and/or removal _at any time_. We strongly recommend that you do not use these features in a production environment. They are intended for testing and feedback only.
{Short explanation of how users should migrate to the new behavior}
:::
:::warning
This experiment breaks the following functionality:
- \{list any existing functionality that will be broken by this experiment\}
- \{if there are no breaking changes, remove this admonition\}
:::
:::info
To enable this experiment, set the environment variable: `TASK_X_{feature}=1`. Check out [our guide to enabling experiments ][enabling-experiments] for more information.
:::
\{Short description of the feature\}
\{Short explanation of how users should migrate to the new behavior\}
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[enabling-experiments]: /experiments/#enabling-experiments