mirror of
https://github.com/go-task/task.git
synced 2026-07-09 20:09:14 +02:00
feat: guide formatting
This commit is contained in:
@@ -940,7 +940,8 @@ You can use `--force` or `-f` if you want to force a task to run even when
|
||||
up-to-date.
|
||||
|
||||
Also, `task --status [tasks]...` will exit with a non-zero
|
||||
[exit code](/docs/reference/cli#exit-codes) if any of the tasks are not up-to-date.
|
||||
[exit code](/docs/reference/cli#exit-codes) if any of the tasks are not
|
||||
up-to-date.
|
||||
|
||||
`status` can be combined with the
|
||||
[fingerprinting](#by-fingerprinting-locally-generated-files-and-their-sources)
|
||||
@@ -1024,8 +1025,8 @@ tasks:
|
||||
|
||||
The `if` attribute allows you to conditionally skip tasks or commands based on a
|
||||
shell command's exit code. Unlike `preconditions` which fail and stop execution,
|
||||
`if` simply skips the task or command when the condition is not met and continues
|
||||
with the rest of the Taskfile.
|
||||
`if` simply skips the task or command when the condition is not met and
|
||||
continues with the rest of the Taskfile.
|
||||
|
||||
#### Task-level `if`
|
||||
|
||||
@@ -1061,9 +1062,9 @@ tasks:
|
||||
|
||||
#### Using templates in `if` conditions
|
||||
|
||||
You can use Go template expressions in `if` conditions. Template expressions like
|
||||
<span v-pre>`{{eq .VAR "value"}}`</span> evaluate to `true` or `false`, which are valid shell
|
||||
commands (`true` exits with 0, `false` exits with 1):
|
||||
You can use Go template expressions in `if` conditions. Template expressions
|
||||
like <span v-pre>`{{eq .VAR "value"}}`</span> evaluate to `true` or `false`,
|
||||
which are valid shell commands (`true` exits with 0, `false` exits with 1):
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
@@ -1071,7 +1072,7 @@ version: '3'
|
||||
tasks:
|
||||
conditional:
|
||||
vars:
|
||||
ENABLE_FEATURE: "true"
|
||||
ENABLE_FEATURE: 'true'
|
||||
cmds:
|
||||
- cmd: echo "Feature is enabled"
|
||||
if: '{{eq .ENABLE_FEATURE "true"}}'
|
||||
@@ -1081,7 +1082,8 @@ tasks:
|
||||
|
||||
#### Using `if` with `for` loops
|
||||
|
||||
When used inside a `for` loop, the `if` condition is evaluated for each iteration:
|
||||
When used inside a `for` loop, the `if` condition is evaluated for each
|
||||
iteration:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
@@ -1103,11 +1105,11 @@ processing c
|
||||
|
||||
#### `if` vs `preconditions`
|
||||
|
||||
| Aspect | `if` | `preconditions` |
|
||||
|--------|------|-----------------|
|
||||
| On failure | Skips (continues) | Fails (stops) |
|
||||
| Message | Only in verbose mode | Always shown |
|
||||
| Use case | "Run if possible" | "Must be true" |
|
||||
| Aspect | `if` | `preconditions` |
|
||||
| ---------- | -------------------- | --------------- |
|
||||
| On failure | Skips (continues) | Fails (stops) |
|
||||
| Message | Only in verbose mode | Always shown |
|
||||
| Use case | "Run if possible" | "Must be true" |
|
||||
|
||||
Use `if` when you want optional conditional execution that shouldn't stop the
|
||||
workflow. Use `preconditions` when the condition must be met for the task to
|
||||
@@ -1337,8 +1339,8 @@ $ task deploy
|
||||
Deploying 1.0.0 to prod
|
||||
```
|
||||
|
||||
If the variable is already set (via CLI, environment, or Taskfile), no prompt
|
||||
is shown:
|
||||
If the variable is already set (via CLI, environment, or Taskfile), no prompt is
|
||||
shown:
|
||||
|
||||
```shell
|
||||
$ task deploy ENVIRONMENT=prod VERSION=1.0.0
|
||||
@@ -1638,8 +1640,8 @@ in logs, but is **not a substitute** for proper secret management practices.
|
||||
- ❌ Secrets in command output (stdout/stderr)
|
||||
- ❌ Secret values copied into derived (non-secret) variables
|
||||
|
||||
Always use proper secret management tools (HashiCorp Vault, AWS Secrets
|
||||
Manager, etc.) for production environments.
|
||||
Always use proper secret management tools (HashiCorp Vault, AWS Secrets Manager,
|
||||
etc.) for production environments.
|
||||
|
||||
:::
|
||||
|
||||
@@ -1767,7 +1769,7 @@ tasks:
|
||||
If you use dotenv files, add them to `.gitignore`:
|
||||
|
||||
```yaml
|
||||
dotenv: ['.env.local'] # Load from .env.local (in .gitignore)
|
||||
dotenv: ['.env.local'] # Load from .env.local (in .gitignore)
|
||||
```
|
||||
|
||||
:::
|
||||
@@ -1844,8 +1846,7 @@ tasks:
|
||||
matrix:
|
||||
OS: ['windows', 'linux', 'darwin']
|
||||
ARCH: ['amd64', 'arm64']
|
||||
cmd:
|
||||
echo "{{.ITEM.OS}}/{{.ITEM.ARCH}}"
|
||||
cmd: echo "{{.ITEM.OS}}/{{.ITEM.ARCH}}"
|
||||
```
|
||||
|
||||
This will output:
|
||||
@@ -1877,8 +1878,7 @@ tasks:
|
||||
ref: .OS_VAR
|
||||
ARCH:
|
||||
ref: .ARCH_VAR
|
||||
cmd:
|
||||
echo "{{.ITEM.OS}}/{{.ITEM.ARCH}}"
|
||||
cmd: echo "{{.ITEM.OS}}/{{.ITEM.ARCH}}"
|
||||
```
|
||||
|
||||
### Looping over your task's sources or generated files
|
||||
@@ -1923,8 +1923,8 @@ files that match that glob.
|
||||
Paths will always be returned as paths relative to the task directory. If you
|
||||
need to convert this to an absolute path, you can use the built-in `joinPath`
|
||||
function. There are some
|
||||
[special variables](/docs/reference/templating#special-variables) that you may find
|
||||
useful for this.
|
||||
[special variables](/docs/reference/templating#special-variables) that you may
|
||||
find useful for this.
|
||||
|
||||
::: code-group
|
||||
|
||||
@@ -2201,8 +2201,9 @@ $ task start:foo:3
|
||||
Starting foo with 3 replicas
|
||||
```
|
||||
|
||||
Using wildcards with aliases
|
||||
Wildcards also work with aliases. If a task has an alias, you can use the alias name with wildcards to capture arguments. For example:
|
||||
Using wildcards with aliases Wildcards also work with aliases. If a task has an
|
||||
alias, you can use the alias name with wildcards to capture arguments. For
|
||||
example:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
@@ -2211,11 +2212,12 @@ tasks:
|
||||
start:*:
|
||||
aliases: [run:*]
|
||||
vars:
|
||||
SERVICE: "{{index .MATCH 0}}"
|
||||
SERVICE: '{{index .MATCH 0}}'
|
||||
cmds:
|
||||
- echo "Running {{.SERVICE}}"
|
||||
```
|
||||
In this example, you can call the task using the alias run:*:
|
||||
|
||||
In this example, you can call the task using the alias run:\*:
|
||||
|
||||
```shell
|
||||
$ task run:foo
|
||||
@@ -2266,8 +2268,8 @@ commands are executed in the reverse order if you schedule multiple of them.
|
||||
:::
|
||||
|
||||
A special variable `.EXIT_CODE` is exposed when a command exited with a non-zero
|
||||
[exit code](/docs/reference/cli#exit-codes). You can check its presence to know if
|
||||
the task completed successfully or not:
|
||||
[exit code](/docs/reference/cli#exit-codes). You can check its presence to know
|
||||
if the task completed successfully or not:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
@@ -2276,7 +2278,8 @@ tasks:
|
||||
default:
|
||||
cmds:
|
||||
- defer:
|
||||
echo '{{if .EXIT_CODE}}Failed with {{.EXIT_CODE}}!{{else}}Success!{{end}}'
|
||||
echo '{{if .EXIT_CODE}}Failed with
|
||||
{{.EXIT_CODE}}!{{else}}Success!{{end}}'
|
||||
- exit 1
|
||||
```
|
||||
|
||||
@@ -2468,8 +2471,8 @@ tasks:
|
||||
```
|
||||
|
||||
Warning prompts are called before executing a task. If a prompt is denied Task
|
||||
will exit with [exit code](/docs/reference/cli#exit-codes) 205. If approved, Task
|
||||
will continue as normal.
|
||||
will exit with [exit code](/docs/reference/cli#exit-codes) 205. If approved,
|
||||
Task will continue as normal.
|
||||
|
||||
```shell
|
||||
❯ task example
|
||||
@@ -2863,8 +2866,8 @@ if called by another task, either directly or as a dependency.
|
||||
The watcher can misbehave in certain scenarios, in particular for long-running
|
||||
servers. There is a [known bug](https://github.com/go-task/task/issues/160)
|
||||
where child processes of the running might not be killed appropriately. It's
|
||||
advised to avoid running commands as `go run` and prefer `go build [...] &&
|
||||
./binary` instead.
|
||||
advised to avoid running commands as `go run` and prefer
|
||||
`go build [...] && ./binary` instead.
|
||||
|
||||
If you are having issues, you might want to try tools specifically designed for
|
||||
live-reloading, like [Air](https://github.com/air-verse/air/). Also, be sure to
|
||||
|
||||
Reference in New Issue
Block a user