mirror of
https://github.com/go-task/task.git
synced 2025-01-12 04:34:11 +02:00
chore: sync translations (#1206)
This commit is contained in:
parent
5af361ab1c
commit
127b685104
@ -43,6 +43,7 @@ If `--` is given, all remaning arguments will be assigned to a special `CLI_ARGS
|
||||
| | `--output-group-error-only` | `bool` | `false` | Swallow command output on zero exit code. |
|
||||
| `-p` | `--parallel` | `bool` | `false` | Executes tasks provided on command line in parallel. |
|
||||
| `-s` | `--silent` | `bool` | `false` | Disables echoing. |
|
||||
| `-y` | `--yes` | `bool` | `false` | Assume "yes" as answer to all prompts. |
|
||||
| | `--status` | `bool` | `false` | Exits with non-zero exit code if any of the given tasks is not up-to-date. |
|
||||
| | `--summary` | `bool` | `false` | Show summary about a task. |
|
||||
| `-t` | `--taskfile` | `string` | `Taskfile.yml` or `Taskfile.yaml` | |
|
||||
@ -72,18 +73,21 @@ A full list of the exit codes and their descriptions can be found below:
|
||||
| 202 | The user tried to invoke a task that is internal |
|
||||
| 203 | There a multiple tasks with the same name or alias |
|
||||
| 204 | A task was called too many times |
|
||||
| 205 | A task was cancelled by the user |
|
||||
|
||||
These codes can also be found in the repository in [`errors/errors.go`](https://github.com/go-task/task/blob/main/errors/errors.go).
|
||||
|
||||
:::info
|
||||
|
||||
When Task is run with the `-x`/`--exit-code` flag, the exit code of any failed commands will be passed through to the user instead.
|
||||
|
||||
:::
|
||||
|
||||
## JSON Output
|
||||
|
||||
When using the `--json` flag in combination with either the `--list` or `--list-all` flags, the output will be a JSON object with the following structure:
|
||||
|
||||
```jsonc
|
||||
```json
|
||||
{
|
||||
"tasks": [
|
||||
{
|
||||
@ -202,6 +206,7 @@ vars:
|
||||
| `deps` | [`[]Dependency`](#dependency) | | A list of dependencies of this task. Tasks defined here will run in parallel before this task. |
|
||||
| `label` | `string` | | Overrides the name of the task in the output when a task is run. Supports variables. |
|
||||
| `desc` | `string` | | A short description of the task. This is displayed when calling `task --list`. |
|
||||
| `prompt` | `string` | | A prompt that will be presented before a task is run. Declining will cancel running the current and any subsequent tasks. |
|
||||
| `summary` | `string` | | A longer description of the task. This is displayed when calling `task --summary [task]`. |
|
||||
| `aliases` | `[]string` | | A list of alternative names by which the task can be called. |
|
||||
| `sources` | `[]string` | | A list of sources to check before running this task. Relevant for `checksum` and `timestamp` methods. Can be file paths or star globs. |
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /changelog/
|
||||
sidebar_position: 8
|
||||
sidebar_position: 9
|
||||
---
|
||||
|
||||
# Changelog
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /community/
|
||||
sidebar_position: 9
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
# Community
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /contributing/
|
||||
sidebar_position: 10
|
||||
sidebar_position: 11
|
||||
---
|
||||
|
||||
# Contributing
|
||||
@ -17,6 +17,7 @@ This document applies to the core [Task][task] repository _and_ [Task for Visual
|
||||
|
||||
- **Check existing work** - Is there an existing PR? Are there issues discussing the feature/change you want to make? Please make sure you consider/address these discussions in your work.
|
||||
- **Backwards compatibility** - Will your change break existing Taskfiles? It is much more likely that your change will merged if it backwards compatible. Is there an approach you can take that maintains this compatibility? If not, consider opening an issue first so that API changes can be discussed before you invest your time into a PR.
|
||||
- **Experiments** - If there is no way to make your change backward compatible then there is a procedure to introduce breaking changes into minor versions. We call these "\[experiments\]\[experiments\]". If you're intending to work on an experiment, then please read the \[experiments workflow\]\[experiments-workflow\] document carefully and submit a proposal first.
|
||||
|
||||
## 1. Setup
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /donate/
|
||||
sidebar_position: 13
|
||||
sidebar_position: 15
|
||||
---
|
||||
|
||||
# Donate
|
||||
|
@ -0,0 +1,54 @@
|
||||
---
|
||||
slug: /experiments/
|
||||
sidebar_position: 5
|
||||
---
|
||||
|
||||
# Experiments
|
||||
|
||||
:::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.
|
||||
|
||||
:::
|
||||
|
||||
In order to allow Task to evolve quickly, we roll out breaking changes to minor versions behind experimental flags. This allows us to gather feedback on breaking changes before committing to a major release. This document describes the current set of experimental features and the deprecated feature that they are intended to replace.
|
||||
|
||||
You can enable an experimental feature by:
|
||||
|
||||
1. Using the `--x-{feature}` flag. This is intended for one-off invocations of Task to test out experimental features. You can also disable a feature by specifying a falsy value such as `--x-{feature}=false`.
|
||||
1. Using the `TASK_X_{FEATURE}=1` environment variable. This is intended for permanently enabling experimental features in your environment.
|
||||
|
||||
Flags will always override environment variables.
|
||||
|
||||
## Current Experimental Features and Deprecations
|
||||
|
||||
Each section below details an experiment or deprecation and explains what the flags/environment variables to enable the experiment are and how the feature's behavior will change. It will also explain what you need to do to migrate any existing Taskfiles to the new behavior.
|
||||
|
||||
<!-- EXPERIMENT TEMPLATE - Include sections as necessary...
|
||||
|
||||
### ![experiment] <Feature> ([#{issue}](https://github.com/go-task/task/issues/{issue})), ...)
|
||||
|
||||
- Flag to enable: `--x-{feature}`
|
||||
- Env to enable: `TASK_X_{feature}`
|
||||
- Deprecates: {list any existing functionality that will be deprecated by this experiment}
|
||||
|
||||
{Short description of the feature}
|
||||
|
||||
{Short explanation of how users should migrate to the new behavior}
|
||||
|
||||
-->
|
||||
|
||||
### ![deprecated][] Version 2 Schema ([#1197][deprecate-version-2-schema])
|
||||
|
||||
The Taskfile v2 schema was introduced in March 2018 and replaced by version 3 in August the following year. Users have had a long time to update and so we feel that it is time to tidy up the codebase and focus on new functionality instead.
|
||||
|
||||
This notice does not mean that we are immediately removing support for version 2 schemas. However, support will not be extended to future major releases and we _strongly recommend_ that anybody still using a version 2 schema upgrades to version 3 as soon as possible.
|
||||
|
||||
A list of changes between version 2 and version 3 are available in the [Task v3 Release Notes][version-3-release-notes].
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
|
||||
[version-3-release-notes]: https://github.com/go-task/task/releases/tag/v3.0.0
|
||||
[deprecated]: https://img.shields.io/badge/deprecated-red
|
@ -0,0 +1,50 @@
|
||||
---
|
||||
slug: /experiments/workflow/
|
||||
---
|
||||
|
||||
# Workflow
|
||||
|
||||
Experiments are a way for us to test out new features in Task before committing to them in a major release. Because this concept is built around the idea of feedback from our community, we have built a workflow for the process of introducing these changes. This ensures that experiments are given the attention and time that they need and that we are getting the best possible results out of them.
|
||||
|
||||
The sections below describe the various stages that an experiment must go through from its proposal all the way to being released in a major version of Task.
|
||||
|
||||
## 1. Proposal
|
||||
|
||||
All experimental features start with a proposal in the form of a GitHub issue. If the maintainers decide that an issue has enough support and is a breaking change or is complex/controversial enough to require user feedback, then the issue will be marked with the ![proposal][] label. At this point, the issue becomes a proposal and a period of consultation begins. During this period, we request that users provide feedback on the proposal and how it might effect their use of Task. It is up to the discretion of the maintainers to decide how long this period lasts.
|
||||
|
||||
## 2. Draft
|
||||
|
||||
Once a proposal's consultation ends, a contributor may pick up the work and begin the initial implementation. Once a PR is opened, the maintainers will ensure that it meets the requirements for an experimental feature (i.e. flags are in the right format etc) and merge the feature. Once this code is released, the status will be updated via the ![draft][] label. This indicates that an implementation is now available for use in a release and the experiment is open for feedback.
|
||||
|
||||
:::note
|
||||
|
||||
During the draft period, major changes to the implementation may be made based on the feedback received from users. There are _no stability guarantees_ and experimental features may be abandoned _at any time_.
|
||||
|
||||
:::
|
||||
|
||||
## 3. Candidate
|
||||
|
||||
Once an acceptable level of consensus has been reached by the community and feedback/changes are less frequent/significant, the status may be updated via the ![candidate][] label. This indicates that a proposal is _likely_ to accepted and will enter a period for final comments and minor changes.
|
||||
|
||||
## 4. Stable
|
||||
|
||||
Once a suitable amount of time has passed with no changes or feedback, an experiment will be given the ![stable][] label. At this point, the functionality will be treated like any other feature in Task and any changes _must_ be backward compatible. This allows users to migrate to the new functionality without having to worry about anything breaking in future releases. This provides the best experience for users migrating to a new major version.
|
||||
|
||||
## 5. Released
|
||||
|
||||
When making a new major release of Task, all experiments marked as ![stable][] will move to ![released][] and their behaviors will become the new default in Task. Experiments in an earlier stage (i.e. not stable) cannot be released and so will continue to be experiments in the new version.
|
||||
|
||||
## Abandoned / Superseded
|
||||
|
||||
If an experiment is unsuccessful at any point then it will be given the ![abandoned][] or ![superseded][] labels depending on which is more suitable. These experiments will be removed from Task.
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
[proposal]: https://img.shields.io/badge/experiment:%20proposal-purple
|
||||
[draft]: https://img.shields.io/badge/experiment:%20draft-purple
|
||||
[candidate]: https://img.shields.io/badge/experiment:%20candidate-purple
|
||||
[stable]: https://img.shields.io/badge/experiment:%20stable-purple
|
||||
[released]: https://img.shields.io/badge/experiment:%20released-purple
|
||||
[abandoned]: https://img.shields.io/badge/experiment:%20abandoned-purple
|
||||
[superseded]: https://img.shields.io/badge/experiment:%20superseded-purple
|
@ -1,15 +1,12 @@
|
||||
---
|
||||
slug: /faq/
|
||||
sidebar_position: 6
|
||||
sidebar_position: 7
|
||||
---
|
||||
|
||||
# FAQ
|
||||
|
||||
This page contains a list of frequently asked questions about Task.
|
||||
|
||||
- [Why won't my task update my shell environment?](#why-wont-my-task-update-my-shell-environment)
|
||||
- ['x' builtin command doesn't work on Windows](#x-builtin-command-doesnt-work-on-windows)
|
||||
|
||||
## Why won't my task update my shell environment?
|
||||
|
||||
This is a limitation of how shells work. Task runs as a subprocess of your current shell, so it can't change the environment of the shell that started it. This limitation is shared by other task runners and build tools too.
|
||||
@ -25,6 +22,52 @@ my-shell-env:
|
||||
|
||||
Now run `eval $(task my-shell-env)` and the variables `$FOO` and `$BAR` will be available in your shell.
|
||||
|
||||
## I can't reuse my shell in a task's commands
|
||||
|
||||
Task runs each command as a separate shell process, so something you do in one command won't effect any future commands. For example, this won't work:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
foo:
|
||||
cmds:
|
||||
- a=foo
|
||||
- echo $a
|
||||
# outputs ""
|
||||
```
|
||||
|
||||
To work around this you can either use a multiline command:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
foo:
|
||||
cmds:
|
||||
- |
|
||||
a=foo
|
||||
echo $a
|
||||
# outputs "foo"
|
||||
```
|
||||
|
||||
Or for more complex multi-line commands it is recommended to move your code into a separate file and call that instead:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
foo:
|
||||
cmds:
|
||||
- ./foo-printer.bash
|
||||
```
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
a=foo
|
||||
echo $a
|
||||
```
|
||||
|
||||
## 'x' builtin command doesn't work on Windows
|
||||
|
||||
The default shell on Windows (`cmd` and `powershell`) do not have commands like `rm` and `cp` available as builtins. This means that these commands won't work. If you want to make your Taskfile fully cross-platform, you'll need to work around this limitation using one of the following methods:
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /integrations/
|
||||
sidebar_position: 5
|
||||
sidebar_position: 6
|
||||
---
|
||||
|
||||
# Integrations
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /releasing/
|
||||
sidebar_position: 11
|
||||
sidebar_position: 13
|
||||
---
|
||||
|
||||
# Releasing
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /styleguide/
|
||||
sidebar_position: 7
|
||||
sidebar_position: 8
|
||||
---
|
||||
|
||||
# Styleguide
|
||||
@ -207,3 +207,27 @@ tasks:
|
||||
```
|
||||
|
||||
This is also done automatically when using included Taskfiles.
|
||||
|
||||
## Prefer external scripts over complex multi-line commands
|
||||
|
||||
```yaml
|
||||
# bad
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
build:
|
||||
cmds:
|
||||
- |
|
||||
for i in $(seq 1 10); do
|
||||
echo $i
|
||||
echo "some other complex logic"
|
||||
done'
|
||||
|
||||
# good
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
build:
|
||||
cmds:
|
||||
- ./scripts/my_complex_script.sh
|
||||
```
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /taskfile-versions/
|
||||
sidebar_position: 12
|
||||
sidebar_position: 14
|
||||
---
|
||||
|
||||
# Taskfile Versions
|
||||
@ -13,27 +13,148 @@ The Taskfile version follows the Task version. E.g. the change to Taskfile versi
|
||||
|
||||
The `version:` key on Taskfile accepts a semver string, so either `2`, `2.0` or `2.0.0` is accepted. If you choose to use `2.0` Task will not enable future `2.1` features, but if you choose to use `2`, then any `2.x.x` features will be available, but not `3.0.0+`.
|
||||
|
||||
## Version 1
|
||||
## Version 3 ![latest](https://img.shields.io/badge/latest-brightgreen)
|
||||
|
||||
> NOTE: Taskfiles in version 1 are not supported on Task >= v3.0.0 anymore.
|
||||
These are some major changes done on `v3`:
|
||||
|
||||
In the first version of the `Taskfile`, the `version:` key was not available, because the tasks was in the root of the YAML document. Like this:
|
||||
- Task's output will now be colored
|
||||
- Added support for `.env` like files
|
||||
- Added `label:` setting to task so one can override how the task name appear in the logs
|
||||
- A global `method:` was added to allow setting the default method, and Task's default changed to `checksum`
|
||||
- Two magic variables were added when using `status:`: `CHECKSUM` and `TIMESTAMP` which contains, respectively, the md5 checksum and greatest modification timestamp of the files listed on `sources:`
|
||||
- Also, the `TASK` variable is always available with the current task name
|
||||
- CLI variables are always treated as global variables
|
||||
- Added `dir:` option to `includes` to allow choosing on which directory an included Taskfile will run:
|
||||
|
||||
```yaml
|
||||
echo:
|
||||
cmds:
|
||||
includes:
|
||||
docs:
|
||||
taskfile: ./docs
|
||||
dir: ./docs
|
||||
```
|
||||
|
||||
- Implemented short task syntax. All below syntaxes are equivalent:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
print:
|
||||
cmds:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
print:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
The variable priority order was also different:
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
1. Call variables
|
||||
2. Environment
|
||||
3. Task variables
|
||||
4. `Taskvars.yml` variables
|
||||
tasks:
|
||||
print: echo "Hello, World!"
|
||||
```
|
||||
|
||||
- There was a major refactor on how variables are handled. They're now easier to understand. The `expansions:` setting was removed as it became unnecessary. This is the order in which Task will process variables, each level can see the variables set by the previous one and override those.
|
||||
- Environment variables
|
||||
- Global + CLI variables
|
||||
- Call variables
|
||||
- Task variables
|
||||
|
||||
## Version 2.6
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
Version 2.6 comes with `preconditions` stanza in tasks.
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
upload_environment:
|
||||
preconditions:
|
||||
- test -f .env
|
||||
cmds:
|
||||
- aws s3 cp .env s3://myenvironment
|
||||
```
|
||||
|
||||
Please check the [documentation][includes]
|
||||
|
||||
## Version 2.2
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
Version 2.2 comes with a global `includes` options to include other Taskfiles:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
includes:
|
||||
docs: ./documentation # will look for ./documentation/Taskfile.yml
|
||||
docker: ./DockerTasks.yml
|
||||
```
|
||||
|
||||
## Version 2.1
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
Version 2.1 includes a global `output` option, to allow having more control over how commands output are printed to the console (see [documentation][output] for more info):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
output: prefixed
|
||||
|
||||
tasks:
|
||||
server:
|
||||
cmds:
|
||||
- go run main.go
|
||||
prefix: server
|
||||
```
|
||||
|
||||
From this version it's also possible to ignore errors of a command or task (check documentation [here][ignore_errors]):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
example-1:
|
||||
cmds:
|
||||
- cmd: exit 1
|
||||
ignore_error: true
|
||||
- echo "This will be print"
|
||||
|
||||
example-2:
|
||||
cmds:
|
||||
- exit 1
|
||||
- echo "This will be print"
|
||||
ignore_error: true
|
||||
```
|
||||
|
||||
## Version 2.0
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
At version 2, we introduced the `version:` key, to allow us to evolve Task with new features without breaking existing Taskfiles. The new syntax is as follows:
|
||||
|
||||
```yaml
|
||||
@ -87,122 +208,33 @@ tasks:
|
||||
- echo "{{.FOOBARBAZ}}"
|
||||
```
|
||||
|
||||
## Version 2.1
|
||||
## Version 1
|
||||
|
||||
Version 2.1 includes a global `output` option, to allow having more control over how commands output are printed to the console (see [documentation][output] for more info):
|
||||
:::caution
|
||||
|
||||
v1 schema support was removed in Task >= v3.0.0.
|
||||
|
||||
:::
|
||||
|
||||
In the first version of the `Taskfile`, the `version:` key was not available, because the tasks was in the root of the YAML document. Like this:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
output: prefixed
|
||||
|
||||
tasks:
|
||||
server:
|
||||
cmds:
|
||||
- go run main.go
|
||||
prefix: server
|
||||
```
|
||||
|
||||
From this version it's also possible to ignore errors of a command or task (check documentation [here][ignore_errors]):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
example-1:
|
||||
cmds:
|
||||
- cmd: exit 1
|
||||
ignore_error: true
|
||||
- echo "This will be print"
|
||||
|
||||
example-2:
|
||||
cmds:
|
||||
- exit 1
|
||||
- echo "This will be print"
|
||||
ignore_error: true
|
||||
```
|
||||
|
||||
## Version 2.2
|
||||
|
||||
Version 2.2 comes with a global `includes` options to include other Taskfiles:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
includes:
|
||||
docs: ./documentation # will look for ./documentation/Taskfile.yml
|
||||
docker: ./DockerTasks.yml
|
||||
```
|
||||
|
||||
## Version 2.6
|
||||
|
||||
Version 2.6 comes with `preconditions` stanza in tasks.
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
upload_environment:
|
||||
preconditions:
|
||||
- test -f .env
|
||||
cmds:
|
||||
- aws s3 cp .env s3://myenvironment
|
||||
```
|
||||
|
||||
Please check the [documentation][includes]
|
||||
|
||||
## Version 3
|
||||
|
||||
These are some major changes done on `v3`:
|
||||
|
||||
- Task's output will now be colored
|
||||
- Added support for `.env` like files
|
||||
- Added `label:` setting to task so one can override how the task name appear in the logs
|
||||
- A global `method:` was added to allow setting the default method, and Task's default changed to `checksum`
|
||||
- Two magic variables were added when using `status:`: `CHECKSUM` and `TIMESTAMP` which contains, respectively, the md5 checksum and greatest modification timestamp of the files listed on `sources:`
|
||||
- Also, the `TASK` variable is always available with the current task name
|
||||
- CLI variables are always treated as global variables
|
||||
- Added `dir:` option to `includes` to allow choosing on which directory an included Taskfile will run:
|
||||
|
||||
```yaml
|
||||
includes:
|
||||
docs:
|
||||
taskfile: ./docs
|
||||
dir: ./docs
|
||||
```
|
||||
|
||||
- Implemented short task syntax. All below syntaxes are equivalent:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
print:
|
||||
cmds:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
print:
|
||||
echo:
|
||||
cmds:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
The variable priority order was also different:
|
||||
|
||||
tasks:
|
||||
print: echo "Hello, World!"
|
||||
```
|
||||
1. Call variables
|
||||
2. Environment
|
||||
3. Task variables
|
||||
4. `Taskvars.yml` variables
|
||||
|
||||
- There was a major refactor on how variables are handled. They're now easier to understand. The `expansions:` setting was removed as it became unnecessary. This is the order in which Task will process variables, each level can see the variables set by the previous one and override those.
|
||||
- Environment variables
|
||||
- Global + CLI variables
|
||||
- Call variables
|
||||
- Task variables
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
[output]: usage.md#output-syntax
|
||||
[ignore_errors]: usage.md#ignore-errors
|
||||
[includes]: usage.md#including-other-taskfiles
|
||||
[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /translate/
|
||||
sidebar_position: 14
|
||||
sidebar_position: 12
|
||||
---
|
||||
|
||||
# Translate
|
||||
|
@ -1053,6 +1053,60 @@ tasks:
|
||||
- echo "{{.MESSAGE}}"
|
||||
```
|
||||
|
||||
## Warning Prompts
|
||||
|
||||
Warning Prompts to prompt a user for confirmation before a task is executed.
|
||||
|
||||
Below is an example using `prompt` with a dangerous command, that is called between two safe commands:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
example:
|
||||
cmds:
|
||||
- task: not-dangerous
|
||||
- task: dangerous
|
||||
- task: another-not-dangerous
|
||||
|
||||
not-dangerous:
|
||||
cmds:
|
||||
- echo 'not dangerous command'
|
||||
|
||||
another-not-dangerous:
|
||||
cmds:
|
||||
- echo 'another not dangerous command'
|
||||
|
||||
dangerous:
|
||||
prompt: This is a dangerous command... Do you want to continue?
|
||||
cmds:
|
||||
- echo 'dangerous command'
|
||||
```
|
||||
|
||||
```bash
|
||||
❯ task dangerous
|
||||
task: "This is a dangerous command... Do you want to continue?" [y/N]
|
||||
```
|
||||
|
||||
Warning prompts are called before executing a task. If a prompt is denied Task will exit with [exit code](api_reference.md#exit-codes) 205. If approved, Task will continue as normal.
|
||||
|
||||
```bash
|
||||
❯ task example
|
||||
not dangerous command
|
||||
task: "This is a dangerous command. Do you want to continue?" [y/N]
|
||||
y
|
||||
dangerous command
|
||||
another not dangerous command
|
||||
```
|
||||
|
||||
To skip warning prompts automatically, you can use the `--yes` (alias `-y`) option when calling the task. By including this option, all warnings, will be automatically confirmed, and no prompts will be shown.
|
||||
|
||||
:::caution
|
||||
|
||||
Tasks with prompts always fail by default on non-terminal environments, like a CI, where an `stdin` won't be available for the user to answer. In cases like, use `--yes` (`-y`) to force all tasks with a prompt to run.
|
||||
|
||||
:::
|
||||
|
||||
## Silent mode
|
||||
|
||||
Silent mode disables the echoing of commands before Task runs it. For the following Taskfile:
|
||||
|
@ -9,7 +9,7 @@ toc_max_heading_level: 5
|
||||
|
||||
## CLI
|
||||
|
||||
Task command line tool has the following syntax:
|
||||
La commande Task a la syntaxe suivante :
|
||||
|
||||
```bash
|
||||
task [--flags] [tasks...] [-- CLI_ARGS...]
|
||||
@ -17,7 +17,7 @@ task [--flags] [tasks...] [-- CLI_ARGS...]
|
||||
|
||||
:::tip
|
||||
|
||||
If `--` is given, all remaning arguments will be assigned to a special `CLI_ARGS` variable
|
||||
Si `--` est renseigné, tous les arguments suivants seront assigné à la variable spéciale `CLI_ARGS`
|
||||
|
||||
:::
|
||||
|
||||
@ -43,6 +43,7 @@ If `--` is given, all remaning arguments will be assigned to a special `CLI_ARGS
|
||||
| | `--output-group-error-only` | `bool` | `false` | Swallow command output on zero exit code. |
|
||||
| `-p` | `--parallel` | `bool` | `false` | Executes tasks provided on command line in parallel. |
|
||||
| `-s` | `--silent` | `bool` | `false` | Disables echoing. |
|
||||
| `-y` | `--yes` | `bool` | `false` | Assume "yes" as answer to all prompts. |
|
||||
| | `--status` | `bool` | `false` | Exits with non-zero exit code if any of the given tasks is not up-to-date. |
|
||||
| | `--summary` | `bool` | `false` | Show summary about a task. |
|
||||
| `-t` | `--taskfile` | `string` | `Taskfile.yml` or `Taskfile.yaml` | |
|
||||
@ -50,7 +51,7 @@ If `--` is given, all remaning arguments will be assigned to a special `CLI_ARGS
|
||||
| | `--version` | `bool` | `false` | Show Task version. |
|
||||
| `-w` | `--watch` | `bool` | `false` | Enables watch of the given task. |
|
||||
|
||||
## Exit Codes
|
||||
## Codes de sortie
|
||||
|
||||
Task will sometimes exit with specific exit codes. These codes are split into three groups with the following ranges:
|
||||
|
||||
@ -72,18 +73,21 @@ A full list of the exit codes and their descriptions can be found below:
|
||||
| 202 | The user tried to invoke a task that is internal |
|
||||
| 203 | There a multiple tasks with the same name or alias |
|
||||
| 204 | A task was called too many times |
|
||||
| 205 | A task was cancelled by the user |
|
||||
|
||||
These codes can also be found in the repository in [`errors/errors.go`](https://github.com/go-task/task/blob/main/errors/errors.go).
|
||||
|
||||
:::info
|
||||
|
||||
When Task is run with the `-x`/`--exit-code` flag, the exit code of any failed commands will be passed through to the user instead.
|
||||
|
||||
:::
|
||||
|
||||
## JSON Output
|
||||
|
||||
When using the `--json` flag in combination with either the `--list` or `--list-all` flags, the output will be a JSON object with the following structure:
|
||||
|
||||
```jsonc
|
||||
```json
|
||||
{
|
||||
"tasks": [
|
||||
{
|
||||
@ -202,6 +206,7 @@ vars:
|
||||
| `deps` | [`[]Dependency`](#dependency) | | A list of dependencies of this task. Tasks defined here will run in parallel before this task. |
|
||||
| `label` | `string` | | Overrides the name of the task in the output when a task is run. Supports variables. |
|
||||
| `desc` | `string` | | A short description of the task. This is displayed when calling `task --list`. |
|
||||
| `prompt` | `string` | | A prompt that will be presented before a task is run. Declining will cancel running the current and any subsequent tasks. |
|
||||
| `summary` | `string` | | A longer description of the task. This is displayed when calling `task --summary [task]`. |
|
||||
| `aliases` | `[]string` | | A list of alternative names by which the task can be called. |
|
||||
| `sources` | `[]string` | | A list of sources to check before running this task. Relevant for `checksum` and `timestamp` methods. Can be file paths or star globs. |
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /changelog/
|
||||
sidebar_position: 8
|
||||
sidebar_position: 9
|
||||
---
|
||||
|
||||
# Changelog
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /community/
|
||||
sidebar_position: 9
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
# Communauté
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /contributing/
|
||||
sidebar_position: 10
|
||||
sidebar_position: 11
|
||||
---
|
||||
|
||||
# Contributing
|
||||
@ -17,6 +17,7 @@ This document applies to the core [Task][task] repository _and_ [Task for Visual
|
||||
|
||||
- **Check existing work** - Is there an existing PR? Are there issues discussing the feature/change you want to make? Please make sure you consider/address these discussions in your work.
|
||||
- **Backwards compatibility** - Will your change break existing Taskfiles? It is much more likely that your change will merged if it backwards compatible. Is there an approach you can take that maintains this compatibility? If not, consider opening an issue first so that API changes can be discussed before you invest your time into a PR.
|
||||
- **Experiments** - If there is no way to make your change backward compatible then there is a procedure to introduce breaking changes into minor versions. We call these "\[experiments\]\[experiments\]". If you're intending to work on an experiment, then please read the \[experiments workflow\]\[experiments-workflow\] document carefully and submit a proposal first.
|
||||
|
||||
## 1. Setup
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /donate/
|
||||
sidebar_position: 13
|
||||
sidebar_position: 15
|
||||
---
|
||||
|
||||
# Faire un don
|
||||
|
@ -0,0 +1,54 @@
|
||||
---
|
||||
slug: /experiments/
|
||||
sidebar_position: 5
|
||||
---
|
||||
|
||||
# Experiments
|
||||
|
||||
:::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.
|
||||
|
||||
:::
|
||||
|
||||
In order to allow Task to evolve quickly, we roll out breaking changes to minor versions behind experimental flags. This allows us to gather feedback on breaking changes before committing to a major release. This document describes the current set of experimental features and the deprecated feature that they are intended to replace.
|
||||
|
||||
You can enable an experimental feature by:
|
||||
|
||||
1. Using the `--x-{feature}` flag. This is intended for one-off invocations of Task to test out experimental features. You can also disable a feature by specifying a falsy value such as `--x-{feature}=false`.
|
||||
1. Using the `TASK_X_{FEATURE}=1` environment variable. This is intended for permanently enabling experimental features in your environment.
|
||||
|
||||
Flags will always override environment variables.
|
||||
|
||||
## Current Experimental Features and Deprecations
|
||||
|
||||
Each section below details an experiment or deprecation and explains what the flags/environment variables to enable the experiment are and how the feature's behavior will change. It will also explain what you need to do to migrate any existing Taskfiles to the new behavior.
|
||||
|
||||
<!-- EXPERIMENT TEMPLATE - Include sections as necessary...
|
||||
|
||||
### ![experiment] <Feature> ([#{issue}](https://github.com/go-task/task/issues/{issue})), ...)
|
||||
|
||||
- Flag to enable: `--x-{feature}`
|
||||
- Env to enable: `TASK_X_{feature}`
|
||||
- Deprecates: {list any existing functionality that will be deprecated by this experiment}
|
||||
|
||||
{Short description of the feature}
|
||||
|
||||
{Short explanation of how users should migrate to the new behavior}
|
||||
|
||||
-->
|
||||
|
||||
### ![deprecated][] Version 2 Schema ([#1197][deprecate-version-2-schema])
|
||||
|
||||
The Taskfile v2 schema was introduced in March 2018 and replaced by version 3 in August the following year. Users have had a long time to update and so we feel that it is time to tidy up the codebase and focus on new functionality instead.
|
||||
|
||||
This notice does not mean that we are immediately removing support for version 2 schemas. However, support will not be extended to future major releases and we _strongly recommend_ that anybody still using a version 2 schema upgrades to version 3 as soon as possible.
|
||||
|
||||
A list of changes between version 2 and version 3 are available in the [Task v3 Release Notes][version-3-release-notes].
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
|
||||
[version-3-release-notes]: https://github.com/go-task/task/releases/tag/v3.0.0
|
||||
[deprecated]: https://img.shields.io/badge/deprecated-red
|
@ -0,0 +1,50 @@
|
||||
---
|
||||
slug: /experiments/workflow/
|
||||
---
|
||||
|
||||
# Workflow
|
||||
|
||||
Experiments are a way for us to test out new features in Task before committing to them in a major release. Because this concept is built around the idea of feedback from our community, we have built a workflow for the process of introducing these changes. This ensures that experiments are given the attention and time that they need and that we are getting the best possible results out of them.
|
||||
|
||||
The sections below describe the various stages that an experiment must go through from its proposal all the way to being released in a major version of Task.
|
||||
|
||||
## 1. Proposal
|
||||
|
||||
All experimental features start with a proposal in the form of a GitHub issue. If the maintainers decide that an issue has enough support and is a breaking change or is complex/controversial enough to require user feedback, then the issue will be marked with the ![proposal][] label. At this point, the issue becomes a proposal and a period of consultation begins. During this period, we request that users provide feedback on the proposal and how it might effect their use of Task. It is up to the discretion of the maintainers to decide how long this period lasts.
|
||||
|
||||
## 2. Draft
|
||||
|
||||
Once a proposal's consultation ends, a contributor may pick up the work and begin the initial implementation. Once a PR is opened, the maintainers will ensure that it meets the requirements for an experimental feature (i.e. flags are in the right format etc) and merge the feature. Once this code is released, the status will be updated via the ![draft][] label. This indicates that an implementation is now available for use in a release and the experiment is open for feedback.
|
||||
|
||||
:::note
|
||||
|
||||
During the draft period, major changes to the implementation may be made based on the feedback received from users. There are _no stability guarantees_ and experimental features may be abandoned _at any time_.
|
||||
|
||||
:::
|
||||
|
||||
## 3. Candidate
|
||||
|
||||
Once an acceptable level of consensus has been reached by the community and feedback/changes are less frequent/significant, the status may be updated via the ![candidate][] label. This indicates that a proposal is _likely_ to accepted and will enter a period for final comments and minor changes.
|
||||
|
||||
## 4. Stable
|
||||
|
||||
Once a suitable amount of time has passed with no changes or feedback, an experiment will be given the ![stable][] label. At this point, the functionality will be treated like any other feature in Task and any changes _must_ be backward compatible. This allows users to migrate to the new functionality without having to worry about anything breaking in future releases. This provides the best experience for users migrating to a new major version.
|
||||
|
||||
## 5. Released
|
||||
|
||||
When making a new major release of Task, all experiments marked as ![stable][] will move to ![released][] and their behaviors will become the new default in Task. Experiments in an earlier stage (i.e. not stable) cannot be released and so will continue to be experiments in the new version.
|
||||
|
||||
## Abandoned / Superseded
|
||||
|
||||
If an experiment is unsuccessful at any point then it will be given the ![abandoned][] or ![superseded][] labels depending on which is more suitable. These experiments will be removed from Task.
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
[proposal]: https://img.shields.io/badge/experiment:%20proposal-purple
|
||||
[draft]: https://img.shields.io/badge/experiment:%20draft-purple
|
||||
[candidate]: https://img.shields.io/badge/experiment:%20candidate-purple
|
||||
[stable]: https://img.shields.io/badge/experiment:%20stable-purple
|
||||
[released]: https://img.shields.io/badge/experiment:%20released-purple
|
||||
[abandoned]: https://img.shields.io/badge/experiment:%20abandoned-purple
|
||||
[superseded]: https://img.shields.io/badge/experiment:%20superseded-purple
|
@ -1,15 +1,12 @@
|
||||
---
|
||||
slug: /faq/
|
||||
sidebar_position: 6
|
||||
sidebar_position: 7
|
||||
---
|
||||
|
||||
# FAQ
|
||||
|
||||
Cette page contient une liste de question fréquemment posée à propos de Task.
|
||||
|
||||
- [Why won't my task update my shell environment?](#why-wont-my-task-update-my-shell-environment)
|
||||
- ['x' builtin command doesn't work on Windows](#x-builtin-command-doesnt-work-on-windows)
|
||||
|
||||
## Why won't my task update my shell environment?
|
||||
|
||||
This is a limitation of how shells work. Task runs as a subprocess of your current shell, so it can't change the environment of the shell that started it. This limitation is shared by other task runners and build tools too.
|
||||
@ -25,6 +22,52 @@ my-shell-env:
|
||||
|
||||
Now run `eval $(task my-shell-env)` and the variables `$FOO` and `$BAR` will be available in your shell.
|
||||
|
||||
## I can't reuse my shell in a task's commands
|
||||
|
||||
Task runs each command as a separate shell process, so something you do in one command won't effect any future commands. For example, this won't work:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
foo:
|
||||
cmds:
|
||||
- a=foo
|
||||
- echo $a
|
||||
# outputs ""
|
||||
```
|
||||
|
||||
To work around this you can either use a multiline command:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
foo:
|
||||
cmds:
|
||||
- |
|
||||
a=foo
|
||||
echo $a
|
||||
# outputs "foo"
|
||||
```
|
||||
|
||||
Or for more complex multi-line commands it is recommended to move your code into a separate file and call that instead:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
foo:
|
||||
cmds:
|
||||
- ./foo-printer.bash
|
||||
```
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
a=foo
|
||||
echo $a
|
||||
```
|
||||
|
||||
## 'x' builtin command doesn't work on Windows
|
||||
|
||||
The default shell on Windows (`cmd` and `powershell`) do not have commands like `rm` and `cp` available as builtins. This means that these commands won't work. If you want to make your Taskfile fully cross-platform, you'll need to work around this limitation using one of the following methods:
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /integrations/
|
||||
sidebar_position: 5
|
||||
sidebar_position: 6
|
||||
---
|
||||
|
||||
# Integrations
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /releasing/
|
||||
sidebar_position: 11
|
||||
sidebar_position: 13
|
||||
---
|
||||
|
||||
# Releasing
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /styleguide/
|
||||
sidebar_position: 7
|
||||
sidebar_position: 8
|
||||
---
|
||||
|
||||
# Guide de style
|
||||
@ -207,3 +207,27 @@ tasks:
|
||||
```
|
||||
|
||||
C'est aussi fait automatiquement quand vous incluez des Taskfiles.
|
||||
|
||||
## Prefer external scripts over complex multi-line commands
|
||||
|
||||
```yaml
|
||||
# bad
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
build:
|
||||
cmds:
|
||||
- |
|
||||
for i in $(seq 1 10); do
|
||||
echo $i
|
||||
echo "some other complex logic"
|
||||
done'
|
||||
|
||||
# good
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
build:
|
||||
cmds:
|
||||
- ./scripts/my_complex_script.sh
|
||||
```
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /taskfile-versions/
|
||||
sidebar_position: 12
|
||||
sidebar_position: 14
|
||||
---
|
||||
|
||||
# Taskfile Versions
|
||||
@ -13,27 +13,148 @@ The Taskfile version follows the Task version. E.g. the change to Taskfile versi
|
||||
|
||||
The `version:` key on Taskfile accepts a semver string, so either `2`, `2.0` or `2.0.0` is accepted. If you choose to use `2.0` Task will not enable future `2.1` features, but if you choose to use `2`, then any `2.x.x` features will be available, but not `3.0.0+`.
|
||||
|
||||
## Version 1
|
||||
## Version 3 ![latest](https://img.shields.io/badge/latest-brightgreen)
|
||||
|
||||
> NOTE: Taskfiles in version 1 are not supported on Task >= v3.0.0 anymore.
|
||||
These are some major changes done on `v3`:
|
||||
|
||||
In the first version of the `Taskfile`, the `version:` key was not available, because the tasks was in the root of the YAML document. Like this:
|
||||
- Task's output will now be colored
|
||||
- Added support for `.env` like files
|
||||
- Added `label:` setting to task so one can override how the task name appear in the logs
|
||||
- A global `method:` was added to allow setting the default method, and Task's default changed to `checksum`
|
||||
- Two magic variables were added when using `status:`: `CHECKSUM` and `TIMESTAMP` which contains, respectively, the md5 checksum and greatest modification timestamp of the files listed on `sources:`
|
||||
- Also, the `TASK` variable is always available with the current task name
|
||||
- CLI variables are always treated as global variables
|
||||
- Added `dir:` option to `includes` to allow choosing on which directory an included Taskfile will run:
|
||||
|
||||
```yaml
|
||||
echo:
|
||||
cmds:
|
||||
includes:
|
||||
docs:
|
||||
taskfile: ./docs
|
||||
dir: ./docs
|
||||
```
|
||||
|
||||
- Implemented short task syntax. All below syntaxes are equivalent:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
print:
|
||||
cmds:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
print:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
The variable priority order was also different:
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
1. Call variables
|
||||
2. Environment
|
||||
3. Task variables
|
||||
4. `Taskvars.yml` variables
|
||||
tasks:
|
||||
print: echo "Hello, World!"
|
||||
```
|
||||
|
||||
- There was a major refactor on how variables are handled. They're now easier to understand. The `expansions:` setting was removed as it became unnecessary. This is the order in which Task will process variables, each level can see the variables set by the previous one and override those.
|
||||
- Environment variables
|
||||
- Global + CLI variables
|
||||
- Call variables
|
||||
- Task variables
|
||||
|
||||
## Version 2.6
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
Version 2.6 comes with `preconditions` stanza in tasks.
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
upload_environment:
|
||||
preconditions:
|
||||
- test -f .env
|
||||
cmds:
|
||||
- aws s3 cp .env s3://myenvironment
|
||||
```
|
||||
|
||||
Please check the [documentation][includes]
|
||||
|
||||
## Version 2.2
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
Version 2.2 comes with a global `includes` options to include other Taskfiles:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
includes:
|
||||
docs: ./documentation # will look for ./documentation/Taskfile.yml
|
||||
docker: ./DockerTasks.yml
|
||||
```
|
||||
|
||||
## Version 2.1
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
Version 2.1 includes a global `output` option, to allow having more control over how commands output are printed to the console (see [documentation][output] for more info):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
output: prefixed
|
||||
|
||||
tasks:
|
||||
server:
|
||||
cmds:
|
||||
- go run main.go
|
||||
prefix: server
|
||||
```
|
||||
|
||||
From this version it's also possible to ignore errors of a command or task (check documentation [here][ignore_errors]):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
example-1:
|
||||
cmds:
|
||||
- cmd: exit 1
|
||||
ignore_error: true
|
||||
- echo "This will be print"
|
||||
|
||||
example-2:
|
||||
cmds:
|
||||
- exit 1
|
||||
- echo "This will be print"
|
||||
ignore_error: true
|
||||
```
|
||||
|
||||
## Version 2.0
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
At version 2, we introduced the `version:` key, to allow us to evolve Task with new features without breaking existing Taskfiles. The new syntax is as follows:
|
||||
|
||||
```yaml
|
||||
@ -87,122 +208,33 @@ tasks:
|
||||
- echo "{{.FOOBARBAZ}}"
|
||||
```
|
||||
|
||||
## Version 2.1
|
||||
## Version 1
|
||||
|
||||
Version 2.1 includes a global `output` option, to allow having more control over how commands output are printed to the console (see [documentation][output] for more info):
|
||||
:::caution
|
||||
|
||||
v1 schema support was removed in Task >= v3.0.0.
|
||||
|
||||
:::
|
||||
|
||||
In the first version of the `Taskfile`, the `version:` key was not available, because the tasks was in the root of the YAML document. Like this:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
output: prefixed
|
||||
|
||||
tasks:
|
||||
server:
|
||||
cmds:
|
||||
- go run main.go
|
||||
prefix: server
|
||||
```
|
||||
|
||||
From this version it's also possible to ignore errors of a command or task (check documentation [here][ignore_errors]):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
example-1:
|
||||
cmds:
|
||||
- cmd: exit 1
|
||||
ignore_error: true
|
||||
- echo "This will be print"
|
||||
|
||||
example-2:
|
||||
cmds:
|
||||
- exit 1
|
||||
- echo "This will be print"
|
||||
ignore_error: true
|
||||
```
|
||||
|
||||
## Version 2.2
|
||||
|
||||
Version 2.2 comes with a global `includes` options to include other Taskfiles:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
includes:
|
||||
docs: ./documentation # will look for ./documentation/Taskfile.yml
|
||||
docker: ./DockerTasks.yml
|
||||
```
|
||||
|
||||
## Version 2.6
|
||||
|
||||
Version 2.6 comes with `preconditions` stanza in tasks.
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
upload_environment:
|
||||
preconditions:
|
||||
- test -f .env
|
||||
cmds:
|
||||
- aws s3 cp .env s3://myenvironment
|
||||
```
|
||||
|
||||
Please check the [documentation][includes]
|
||||
|
||||
## Version 3
|
||||
|
||||
These are some major changes done on `v3`:
|
||||
|
||||
- Task's output will now be colored
|
||||
- Added support for `.env` like files
|
||||
- Added `label:` setting to task so one can override how the task name appear in the logs
|
||||
- A global `method:` was added to allow setting the default method, and Task's default changed to `checksum`
|
||||
- Two magic variables were added when using `status:`: `CHECKSUM` and `TIMESTAMP` which contains, respectively, the md5 checksum and greatest modification timestamp of the files listed on `sources:`
|
||||
- Also, the `TASK` variable is always available with the current task name
|
||||
- CLI variables are always treated as global variables
|
||||
- Added `dir:` option to `includes` to allow choosing on which directory an included Taskfile will run:
|
||||
|
||||
```yaml
|
||||
includes:
|
||||
docs:
|
||||
taskfile: ./docs
|
||||
dir: ./docs
|
||||
```
|
||||
|
||||
- Implemented short task syntax. All below syntaxes are equivalent:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
print:
|
||||
cmds:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
print:
|
||||
echo:
|
||||
cmds:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
The variable priority order was also different:
|
||||
|
||||
tasks:
|
||||
print: echo "Hello, World!"
|
||||
```
|
||||
1. Call variables
|
||||
2. Environment
|
||||
3. Task variables
|
||||
4. `Taskvars.yml` variables
|
||||
|
||||
- There was a major refactor on how variables are handled. They're now easier to understand. The `expansions:` setting was removed as it became unnecessary. This is the order in which Task will process variables, each level can see the variables set by the previous one and override those.
|
||||
- Environment variables
|
||||
- Global + CLI variables
|
||||
- Call variables
|
||||
- Task variables
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
[output]: usage.md#output-syntax
|
||||
[ignore_errors]: usage.md#ignore-errors
|
||||
[includes]: usage.md#including-other-taskfiles
|
||||
[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /translate/
|
||||
sidebar_position: 14
|
||||
sidebar_position: 12
|
||||
---
|
||||
|
||||
# Traduction
|
||||
|
@ -1053,6 +1053,60 @@ tasks:
|
||||
- echo "{{.MESSAGE}}"
|
||||
```
|
||||
|
||||
## Warning Prompts
|
||||
|
||||
Warning Prompts to prompt a user for confirmation before a task is executed.
|
||||
|
||||
Below is an example using `prompt` with a dangerous command, that is called between two safe commands:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
example:
|
||||
cmds:
|
||||
- task: not-dangerous
|
||||
- task: dangerous
|
||||
- task: another-not-dangerous
|
||||
|
||||
not-dangerous:
|
||||
cmds:
|
||||
- echo 'not dangerous command'
|
||||
|
||||
another-not-dangerous:
|
||||
cmds:
|
||||
- echo 'another not dangerous command'
|
||||
|
||||
dangerous:
|
||||
prompt: This is a dangerous command... Do you want to continue?
|
||||
cmds:
|
||||
- echo 'dangerous command'
|
||||
```
|
||||
|
||||
```bash
|
||||
❯ task dangerous
|
||||
task: "This is a dangerous command... Do you want to continue?" [y/N]
|
||||
```
|
||||
|
||||
Warning prompts are called before executing a task. If a prompt is denied Task will exit with [exit code](api_reference.md#exit-codes) 205. If approved, Task will continue as normal.
|
||||
|
||||
```bash
|
||||
❯ task example
|
||||
not dangerous command
|
||||
task: "This is a dangerous command. Do you want to continue?" [y/N]
|
||||
y
|
||||
dangerous command
|
||||
another not dangerous command
|
||||
```
|
||||
|
||||
To skip warning prompts automatically, you can use the `--yes` (alias `-y`) option when calling the task. By including this option, all warnings, will be automatically confirmed, and no prompts will be shown.
|
||||
|
||||
:::caution
|
||||
|
||||
Tasks with prompts always fail by default on non-terminal environments, like a CI, where an `stdin` won't be available for the user to answer. In cases like, use `--yes` (`-y`) to force all tasks with a prompt to run.
|
||||
|
||||
:::
|
||||
|
||||
## Silent mode
|
||||
|
||||
Silent mode disables the echoing of commands before Task runs it. For the following Taskfile:
|
||||
|
@ -43,6 +43,7 @@ Se `--` é informado, todos os argumentos remanescentes serão atribuídos a uma
|
||||
| | `--output-group-error-only` | `bool` | `false` | Oculta saída dos comandos que terminarem sem erro. |
|
||||
| `-p` | `--parallel` | `bool` | `false` | Executa as tarefas fornecidas na linha de comando em paralelo. |
|
||||
| `-s` | `--silent` | `bool` | `false` | Desabilita impressão. |
|
||||
| `-y` | `--yes` | `bool` | `false` | Assume "yes" as answer to all prompts. |
|
||||
| | `--status` | `bool` | `false` | Sai com código de saída diferente de zero se alguma das tarefas especificadas não estiver atualizada. |
|
||||
| | `--summary` | `bool` | `false` | Mostrar resumo sobre uma tarefa. |
|
||||
| `-t` | `--taskfile` | `string` | `Taskfile.yml` ou `Taskfile.yaml` | |
|
||||
@ -52,7 +53,7 @@ Se `--` é informado, todos os argumentos remanescentes serão atribuídos a uma
|
||||
|
||||
## Códigos de saída
|
||||
|
||||
O Task às vezes fecha com códigos de saída específicos. Estes códigos são divididos em três grupos com os seguintes intervalos:
|
||||
O Task às vezes fecha com códigos de saída específicos. These codes are split into three groups with the following ranges:
|
||||
|
||||
- Erros gerais (0-99)
|
||||
- Erros de Taskfile (100-199)
|
||||
@ -72,18 +73,21 @@ Uma lista completa dos códigos de saída e suas descrições podem ser encontra
|
||||
| 202 | O usuário tentou invocar uma tarefa que é interna |
|
||||
| 203 | Há várias tarefas com o mesmo nome ou apelido |
|
||||
| 204 | Uma tarefa foi chamada muitas vezes |
|
||||
| 205 | A task was cancelled by the user |
|
||||
|
||||
Esses códigos também podem ser encontrados no repositório em [`errors/errors.go`](https://github.com/go-task/task/blob/main/errors/errors.go).
|
||||
These codes can also be found in the repository in [`errors/errors.go`](https://github.com/go-task/task/blob/main/errors/errors.go).
|
||||
|
||||
:::info
|
||||
|
||||
When Task is run with the `-x`/`--exit-code` flag, the exit code of any failed commands will be passed through to the user instead.
|
||||
|
||||
:::
|
||||
|
||||
## Saída em JSON
|
||||
|
||||
Quando estiver usando o modificador `--json` em combinação com o modificador `--list` ou `--list-all`, a saída será um objeto JSON com a seguinte estrutura:
|
||||
|
||||
```jsonc
|
||||
```json
|
||||
{
|
||||
"tasks": [
|
||||
{
|
||||
@ -202,6 +206,7 @@ vars:
|
||||
| `deps` | [`[]Dependency`](#dependency) | | A list of dependencies of this task. Tasks defined here will run in parallel before this task. |
|
||||
| `label` | `string` | | Overrides the name of the task in the output when a task is run. Supports variables. |
|
||||
| `desc` | `string` | | A short description of the task. This is displayed when calling `task --list`. |
|
||||
| `prompt` | `string` | | A prompt that will be presented before a task is run. Declining will cancel running the current and any subsequent tasks. |
|
||||
| `summary` | `string` | | A longer description of the task. This is displayed when calling `task --summary [task]`. |
|
||||
| `aliases` | `[]string` | | A list of alternative names by which the task can be called. |
|
||||
| `sources` | `[]string` | | A list of sources to check before running this task. Relevant for `checksum` and `timestamp` methods. Can be file paths or star globs. |
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /changelog/
|
||||
sidebar_position: 8
|
||||
sidebar_position: 9
|
||||
---
|
||||
|
||||
# Changelog
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /community/
|
||||
sidebar_position: 9
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
# Comunidade
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /contributing/
|
||||
sidebar_position: 10
|
||||
sidebar_position: 11
|
||||
---
|
||||
|
||||
# Contributing
|
||||
@ -17,6 +17,7 @@ This document applies to the core [Task][task] repository _and_ [Task for Visual
|
||||
|
||||
- **Check existing work** - Is there an existing PR? Are there issues discussing the feature/change you want to make? Please make sure you consider/address these discussions in your work.
|
||||
- **Backwards compatibility** - Will your change break existing Taskfiles? It is much more likely that your change will merged if it backwards compatible. Is there an approach you can take that maintains this compatibility? If not, consider opening an issue first so that API changes can be discussed before you invest your time into a PR.
|
||||
- **Experiments** - If there is no way to make your change backward compatible then there is a procedure to introduce breaking changes into minor versions. We call these "\[experiments\]\[experiments\]". If you're intending to work on an experiment, then please read the \[experiments workflow\]\[experiments-workflow\] document carefully and submit a proposal first.
|
||||
|
||||
## 1. Setup
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /donate/
|
||||
sidebar_position: 13
|
||||
sidebar_position: 15
|
||||
---
|
||||
|
||||
# Doe
|
||||
|
@ -0,0 +1,54 @@
|
||||
---
|
||||
slug: /experiments/
|
||||
sidebar_position: 5
|
||||
---
|
||||
|
||||
# Experiments
|
||||
|
||||
:::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.
|
||||
|
||||
:::
|
||||
|
||||
In order to allow Task to evolve quickly, we roll out breaking changes to minor versions behind experimental flags. This allows us to gather feedback on breaking changes before committing to a major release. This document describes the current set of experimental features and the deprecated feature that they are intended to replace.
|
||||
|
||||
You can enable an experimental feature by:
|
||||
|
||||
1. Using the `--x-{feature}` flag. This is intended for one-off invocations of Task to test out experimental features. You can also disable a feature by specifying a falsy value such as `--x-{feature}=false`.
|
||||
1. Using the `TASK_X_{FEATURE}=1` environment variable. This is intended for permanently enabling experimental features in your environment.
|
||||
|
||||
Flags will always override environment variables.
|
||||
|
||||
## Current Experimental Features and Deprecations
|
||||
|
||||
Each section below details an experiment or deprecation and explains what the flags/environment variables to enable the experiment are and how the feature's behavior will change. It will also explain what you need to do to migrate any existing Taskfiles to the new behavior.
|
||||
|
||||
<!-- EXPERIMENT TEMPLATE - Include sections as necessary...
|
||||
|
||||
### ![experiment] <Feature> ([#{issue}](https://github.com/go-task/task/issues/{issue})), ...)
|
||||
|
||||
- Flag to enable: `--x-{feature}`
|
||||
- Env to enable: `TASK_X_{feature}`
|
||||
- Deprecates: {list any existing functionality that will be deprecated by this experiment}
|
||||
|
||||
{Short description of the feature}
|
||||
|
||||
{Short explanation of how users should migrate to the new behavior}
|
||||
|
||||
-->
|
||||
|
||||
### ![deprecated][] Version 2 Schema ([#1197][deprecate-version-2-schema])
|
||||
|
||||
The Taskfile v2 schema was introduced in March 2018 and replaced by version 3 in August the following year. Users have had a long time to update and so we feel that it is time to tidy up the codebase and focus on new functionality instead.
|
||||
|
||||
This notice does not mean that we are immediately removing support for version 2 schemas. However, support will not be extended to future major releases and we _strongly recommend_ that anybody still using a version 2 schema upgrades to version 3 as soon as possible.
|
||||
|
||||
A list of changes between version 2 and version 3 are available in the [Task v3 Release Notes][version-3-release-notes].
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
|
||||
[version-3-release-notes]: https://github.com/go-task/task/releases/tag/v3.0.0
|
||||
[deprecated]: https://img.shields.io/badge/deprecated-red
|
@ -0,0 +1,50 @@
|
||||
---
|
||||
slug: /experiments/workflow/
|
||||
---
|
||||
|
||||
# Workflow
|
||||
|
||||
Experiments are a way for us to test out new features in Task before committing to them in a major release. Because this concept is built around the idea of feedback from our community, we have built a workflow for the process of introducing these changes. This ensures that experiments are given the attention and time that they need and that we are getting the best possible results out of them.
|
||||
|
||||
The sections below describe the various stages that an experiment must go through from its proposal all the way to being released in a major version of Task.
|
||||
|
||||
## 1. Proposal
|
||||
|
||||
All experimental features start with a proposal in the form of a GitHub issue. If the maintainers decide that an issue has enough support and is a breaking change or is complex/controversial enough to require user feedback, then the issue will be marked with the ![proposal][] label. At this point, the issue becomes a proposal and a period of consultation begins. During this period, we request that users provide feedback on the proposal and how it might effect their use of Task. It is up to the discretion of the maintainers to decide how long this period lasts.
|
||||
|
||||
## 2. Draft
|
||||
|
||||
Once a proposal's consultation ends, a contributor may pick up the work and begin the initial implementation. Once a PR is opened, the maintainers will ensure that it meets the requirements for an experimental feature (i.e. flags are in the right format etc) and merge the feature. Once this code is released, the status will be updated via the ![draft][] label. This indicates that an implementation is now available for use in a release and the experiment is open for feedback.
|
||||
|
||||
:::note
|
||||
|
||||
During the draft period, major changes to the implementation may be made based on the feedback received from users. There are _no stability guarantees_ and experimental features may be abandoned _at any time_.
|
||||
|
||||
:::
|
||||
|
||||
## 3. Candidate
|
||||
|
||||
Once an acceptable level of consensus has been reached by the community and feedback/changes are less frequent/significant, the status may be updated via the ![candidate][] label. This indicates that a proposal is _likely_ to accepted and will enter a period for final comments and minor changes.
|
||||
|
||||
## 4. Stable
|
||||
|
||||
Once a suitable amount of time has passed with no changes or feedback, an experiment will be given the ![stable][] label. At this point, the functionality will be treated like any other feature in Task and any changes _must_ be backward compatible. This allows users to migrate to the new functionality without having to worry about anything breaking in future releases. This provides the best experience for users migrating to a new major version.
|
||||
|
||||
## 5. Released
|
||||
|
||||
When making a new major release of Task, all experiments marked as ![stable][] will move to ![released][] and their behaviors will become the new default in Task. Experiments in an earlier stage (i.e. not stable) cannot be released and so will continue to be experiments in the new version.
|
||||
|
||||
## Abandoned / Superseded
|
||||
|
||||
If an experiment is unsuccessful at any point then it will be given the ![abandoned][] or ![superseded][] labels depending on which is more suitable. These experiments will be removed from Task.
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
[proposal]: https://img.shields.io/badge/experiment:%20proposal-purple
|
||||
[draft]: https://img.shields.io/badge/experiment:%20draft-purple
|
||||
[candidate]: https://img.shields.io/badge/experiment:%20candidate-purple
|
||||
[stable]: https://img.shields.io/badge/experiment:%20stable-purple
|
||||
[released]: https://img.shields.io/badge/experiment:%20released-purple
|
||||
[abandoned]: https://img.shields.io/badge/experiment:%20abandoned-purple
|
||||
[superseded]: https://img.shields.io/badge/experiment:%20superseded-purple
|
@ -1,15 +1,12 @@
|
||||
---
|
||||
slug: /faq/
|
||||
sidebar_position: 6
|
||||
sidebar_position: 7
|
||||
---
|
||||
|
||||
# Perguntas frequentes
|
||||
|
||||
This page contains a list of frequently asked questions about Task.
|
||||
|
||||
- [Why won't my task update my shell environment?](#why-wont-my-task-update-my-shell-environment)
|
||||
- ['x' builtin command doesn't work on Windows](#x-builtin-command-doesnt-work-on-windows)
|
||||
|
||||
## Why won't my task update my shell environment?
|
||||
|
||||
This is a limitation of how shells work. Task runs as a subprocess of your current shell, so it can't change the environment of the shell that started it. This limitation is shared by other task runners and build tools too.
|
||||
@ -25,6 +22,52 @@ my-shell-env:
|
||||
|
||||
Now run `eval $(task my-shell-env)` and the variables `$FOO` and `$BAR` will be available in your shell.
|
||||
|
||||
## I can't reuse my shell in a task's commands
|
||||
|
||||
Task runs each command as a separate shell process, so something you do in one command won't effect any future commands. For example, this won't work:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
foo:
|
||||
cmds:
|
||||
- a=foo
|
||||
- echo $a
|
||||
# outputs ""
|
||||
```
|
||||
|
||||
To work around this you can either use a multiline command:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
foo:
|
||||
cmds:
|
||||
- |
|
||||
a=foo
|
||||
echo $a
|
||||
# outputs "foo"
|
||||
```
|
||||
|
||||
Or for more complex multi-line commands it is recommended to move your code into a separate file and call that instead:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
foo:
|
||||
cmds:
|
||||
- ./foo-printer.bash
|
||||
```
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
a=foo
|
||||
echo $a
|
||||
```
|
||||
|
||||
## 'x' builtin command doesn't work on Windows
|
||||
|
||||
The default shell on Windows (`cmd` and `powershell`) do not have commands like `rm` and `cp` available as builtins. This means that these commands won't work. If you want to make your Taskfile fully cross-platform, you'll need to work around this limitation using one of the following methods:
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /integrations/
|
||||
sidebar_position: 5
|
||||
sidebar_position: 6
|
||||
---
|
||||
|
||||
# Integrations
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /releasing/
|
||||
sidebar_position: 11
|
||||
sidebar_position: 13
|
||||
---
|
||||
|
||||
# Releasing
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /styleguide/
|
||||
sidebar_position: 7
|
||||
sidebar_position: 8
|
||||
---
|
||||
|
||||
# Guia de estilo
|
||||
@ -207,3 +207,27 @@ tasks:
|
||||
```
|
||||
|
||||
This is also done automatically when using included Taskfiles.
|
||||
|
||||
## Prefer external scripts over complex multi-line commands
|
||||
|
||||
```yaml
|
||||
# bad
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
build:
|
||||
cmds:
|
||||
- |
|
||||
for i in $(seq 1 10); do
|
||||
echo $i
|
||||
echo "some other complex logic"
|
||||
done'
|
||||
|
||||
# good
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
build:
|
||||
cmds:
|
||||
- ./scripts/my_complex_script.sh
|
||||
```
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /taskfile-versions/
|
||||
sidebar_position: 12
|
||||
sidebar_position: 14
|
||||
---
|
||||
|
||||
# Versões do Taskfile
|
||||
@ -13,27 +13,148 @@ The Taskfile version follows the Task version. E.g. the change to Taskfile versi
|
||||
|
||||
The `version:` key on Taskfile accepts a semver string, so either `2`, `2.0` or `2.0.0` is accepted. If you choose to use `2.0` Task will not enable future `2.1` features, but if you choose to use `2`, then any `2.x.x` features will be available, but not `3.0.0+`.
|
||||
|
||||
## Version 1
|
||||
## Version 3 ![latest](https://img.shields.io/badge/latest-brightgreen)
|
||||
|
||||
> NOTE: Taskfiles in version 1 are not supported on Task >= v3.0.0 anymore.
|
||||
These are some major changes done on `v3`:
|
||||
|
||||
In the first version of the `Taskfile`, the `version:` key was not available, because the tasks was in the root of the YAML document. Like this:
|
||||
- Task's output will now be colored
|
||||
- Added support for `.env` like files
|
||||
- Added `label:` setting to task so one can override how the task name appear in the logs
|
||||
- A global `method:` was added to allow setting the default method, and Task's default changed to `checksum`
|
||||
- Two magic variables were added when using `status:`: `CHECKSUM` and `TIMESTAMP` which contains, respectively, the md5 checksum and greatest modification timestamp of the files listed on `sources:`
|
||||
- Also, the `TASK` variable is always available with the current task name
|
||||
- CLI variables are always treated as global variables
|
||||
- Added `dir:` option to `includes` to allow choosing on which directory an included Taskfile will run:
|
||||
|
||||
```yaml
|
||||
echo:
|
||||
cmds:
|
||||
includes:
|
||||
docs:
|
||||
taskfile: ./docs
|
||||
dir: ./docs
|
||||
```
|
||||
|
||||
- Implemented short task syntax. All below syntaxes are equivalent:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
print:
|
||||
cmds:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
print:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
The variable priority order was also different:
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
1. Call variables
|
||||
2. Environment
|
||||
3. Task variables
|
||||
4. `Taskvars.yml` variables
|
||||
tasks:
|
||||
print: echo "Hello, World!"
|
||||
```
|
||||
|
||||
- There was a major refactor on how variables are handled. They're now easier to understand. The `expansions:` setting was removed as it became unnecessary. This is the order in which Task will process variables, each level can see the variables set by the previous one and override those.
|
||||
- Environment variables
|
||||
- Global + CLI variables
|
||||
- Call variables
|
||||
- Task variables
|
||||
|
||||
## Version 2.6
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
Version 2.6 comes with `preconditions` stanza in tasks.
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
upload_environment:
|
||||
preconditions:
|
||||
- test -f .env
|
||||
cmds:
|
||||
- aws s3 cp .env s3://myenvironment
|
||||
```
|
||||
|
||||
Please check the [documentation][includes]
|
||||
|
||||
## Version 2.2
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
Version 2.2 comes with a global `includes` options to include other Taskfiles:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
includes:
|
||||
docs: ./documentation # will look for ./documentation/Taskfile.yml
|
||||
docker: ./DockerTasks.yml
|
||||
```
|
||||
|
||||
## Version 2.1
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
Version 2.1 includes a global `output` option, to allow having more control over how commands output are printed to the console (see [documentation][output] for more info):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
output: prefixed
|
||||
|
||||
tasks:
|
||||
server:
|
||||
cmds:
|
||||
- go run main.go
|
||||
prefix: server
|
||||
```
|
||||
|
||||
From this version it's also possible to ignore errors of a command or task (check documentation [here][ignore_errors]):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
example-1:
|
||||
cmds:
|
||||
- cmd: exit 1
|
||||
ignore_error: true
|
||||
- echo "This will be print"
|
||||
|
||||
example-2:
|
||||
cmds:
|
||||
- exit 1
|
||||
- echo "This will be print"
|
||||
ignore_error: true
|
||||
```
|
||||
|
||||
## Version 2.0
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
At version 2, we introduced the `version:` key, to allow us to evolve Task with new features without breaking existing Taskfiles. The new syntax is as follows:
|
||||
|
||||
```yaml
|
||||
@ -87,122 +208,33 @@ tasks:
|
||||
- echo "{{.FOOBARBAZ}}"
|
||||
```
|
||||
|
||||
## Version 2.1
|
||||
## Version 1
|
||||
|
||||
Version 2.1 includes a global `output` option, to allow having more control over how commands output are printed to the console (see [documentation][output] for more info):
|
||||
:::caution
|
||||
|
||||
v1 schema support was removed in Task >= v3.0.0.
|
||||
|
||||
:::
|
||||
|
||||
In the first version of the `Taskfile`, the `version:` key was not available, because the tasks was in the root of the YAML document. Like this:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
output: prefixed
|
||||
|
||||
tasks:
|
||||
server:
|
||||
cmds:
|
||||
- go run main.go
|
||||
prefix: server
|
||||
```
|
||||
|
||||
From this version it's also possible to ignore errors of a command or task (check documentation [here][ignore_errors]):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
example-1:
|
||||
cmds:
|
||||
- cmd: exit 1
|
||||
ignore_error: true
|
||||
- echo "This will be print"
|
||||
|
||||
example-2:
|
||||
cmds:
|
||||
- exit 1
|
||||
- echo "This will be print"
|
||||
ignore_error: true
|
||||
```
|
||||
|
||||
## Version 2.2
|
||||
|
||||
Version 2.2 comes with a global `includes` options to include other Taskfiles:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
includes:
|
||||
docs: ./documentation # will look for ./documentation/Taskfile.yml
|
||||
docker: ./DockerTasks.yml
|
||||
```
|
||||
|
||||
## Version 2.6
|
||||
|
||||
Version 2.6 comes with `preconditions` stanza in tasks.
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
upload_environment:
|
||||
preconditions:
|
||||
- test -f .env
|
||||
cmds:
|
||||
- aws s3 cp .env s3://myenvironment
|
||||
```
|
||||
|
||||
Please check the [documentation][includes]
|
||||
|
||||
## Version 3
|
||||
|
||||
These are some major changes done on `v3`:
|
||||
|
||||
- Task's output will now be colored
|
||||
- Added support for `.env` like files
|
||||
- Added `label:` setting to task so one can override how the task name appear in the logs
|
||||
- A global `method:` was added to allow setting the default method, and Task's default changed to `checksum`
|
||||
- Two magic variables were added when using `status:`: `CHECKSUM` and `TIMESTAMP` which contains, respectively, the md5 checksum and greatest modification timestamp of the files listed on `sources:`
|
||||
- Also, the `TASK` variable is always available with the current task name
|
||||
- CLI variables are always treated as global variables
|
||||
- Added `dir:` option to `includes` to allow choosing on which directory an included Taskfile will run:
|
||||
|
||||
```yaml
|
||||
includes:
|
||||
docs:
|
||||
taskfile: ./docs
|
||||
dir: ./docs
|
||||
```
|
||||
|
||||
- Implemented short task syntax. All below syntaxes are equivalent:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
print:
|
||||
cmds:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
print:
|
||||
echo:
|
||||
cmds:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
The variable priority order was also different:
|
||||
|
||||
tasks:
|
||||
print: echo "Hello, World!"
|
||||
```
|
||||
1. Call variables
|
||||
2. Environment
|
||||
3. Task variables
|
||||
4. `Taskvars.yml` variables
|
||||
|
||||
- There was a major refactor on how variables are handled. They're now easier to understand. The `expansions:` setting was removed as it became unnecessary. This is the order in which Task will process variables, each level can see the variables set by the previous one and override those.
|
||||
- Environment variables
|
||||
- Global + CLI variables
|
||||
- Call variables
|
||||
- Task variables
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
[output]: usage.md#output-syntax
|
||||
[ignore_errors]: usage.md#ignore-errors
|
||||
[includes]: usage.md#including-other-taskfiles
|
||||
[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /translate/
|
||||
sidebar_position: 14
|
||||
sidebar_position: 12
|
||||
---
|
||||
|
||||
# Traduza
|
||||
|
@ -1053,6 +1053,60 @@ tasks:
|
||||
- echo "{{.MESSAGE}}"
|
||||
```
|
||||
|
||||
## Warning Prompts
|
||||
|
||||
Warning Prompts to prompt a user for confirmation before a task is executed.
|
||||
|
||||
Below is an example using `prompt` with a dangerous command, that is called between two safe commands:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
example:
|
||||
cmds:
|
||||
- task: not-dangerous
|
||||
- task: dangerous
|
||||
- task: another-not-dangerous
|
||||
|
||||
not-dangerous:
|
||||
cmds:
|
||||
- echo 'not dangerous command'
|
||||
|
||||
another-not-dangerous:
|
||||
cmds:
|
||||
- echo 'another not dangerous command'
|
||||
|
||||
dangerous:
|
||||
prompt: This is a dangerous command... Do you want to continue?
|
||||
cmds:
|
||||
- echo 'dangerous command'
|
||||
```
|
||||
|
||||
```bash
|
||||
❯ task dangerous
|
||||
task: "This is a dangerous command... Do you want to continue?" [y/N]
|
||||
```
|
||||
|
||||
Warning prompts are called before executing a task. If a prompt is denied Task will exit with [exit code](api_reference.md#exit-codes) 205. If approved, Task will continue as normal.
|
||||
|
||||
```bash
|
||||
❯ task example
|
||||
not dangerous command
|
||||
task: "This is a dangerous command. Do you want to continue?" [y/N]
|
||||
y
|
||||
dangerous command
|
||||
another not dangerous command
|
||||
```
|
||||
|
||||
To skip warning prompts automatically, you can use the `--yes` (alias `-y`) option when calling the task. By including this option, all warnings, will be automatically confirmed, and no prompts will be shown.
|
||||
|
||||
:::caution
|
||||
|
||||
Tasks with prompts always fail by default on non-terminal environments, like a CI, where an `stdin` won't be available for the user to answer. In cases like, use `--yes` (`-y`) to force all tasks with a prompt to run.
|
||||
|
||||
:::
|
||||
|
||||
## Silent mode
|
||||
|
||||
Silent mode disables the echoing of commands before Task runs it. For the following Taskfile:
|
||||
|
@ -43,6 +43,7 @@ If `--` is given, all remaning arguments will be assigned to a special `CLI_ARGS
|
||||
| | `--output-group-error-only` | `bool` | `false` | Swallow command output on zero exit code. |
|
||||
| `-p` | `--parallel` | `bool` | `false` | Executes tasks provided on command line in parallel. |
|
||||
| `-s` | `--silent` | `bool` | `false` | Disables echoing. |
|
||||
| `-y` | `--yes` | `bool` | `false` | Assume "yes" as answer to all prompts. |
|
||||
| | `--status` | `bool` | `false` | Exits with non-zero exit code if any of the given tasks is not up-to-date. |
|
||||
| | `--summary` | `bool` | `false` | Show summary about a task. |
|
||||
| `-t` | `--taskfile` | `string` | `Taskfile.yml` or `Taskfile.yaml` | |
|
||||
@ -72,18 +73,21 @@ A full list of the exit codes and their descriptions can be found below:
|
||||
| 202 | The user tried to invoke a task that is internal |
|
||||
| 203 | There a multiple tasks with the same name or alias |
|
||||
| 204 | A task was called too many times |
|
||||
| 205 | A task was cancelled by the user |
|
||||
|
||||
These codes can also be found in the repository in [`errors/errors.go`](https://github.com/go-task/task/blob/main/errors/errors.go).
|
||||
|
||||
:::info
|
||||
|
||||
When Task is run with the `-x`/`--exit-code` flag, the exit code of any failed commands will be passed through to the user instead.
|
||||
|
||||
:::
|
||||
|
||||
## JSON Output
|
||||
|
||||
When using the `--json` flag in combination with either the `--list` or `--list-all` flags, the output will be a JSON object with the following structure:
|
||||
|
||||
```jsonc
|
||||
```json
|
||||
{
|
||||
"tasks": [
|
||||
{
|
||||
@ -202,6 +206,7 @@ vars:
|
||||
| `deps` | [`[]Dependency`](#dependency) | | A list of dependencies of this task. Tasks defined here will run in parallel before this task. |
|
||||
| `label` | `string` | | Overrides the name of the task in the output when a task is run. Supports variables. |
|
||||
| `desc` | `string` | | A short description of the task. This is displayed when calling `task --list`. |
|
||||
| `prompt` | `string` | | A prompt that will be presented before a task is run. Declining will cancel running the current and any subsequent tasks. |
|
||||
| `summary` | `string` | | A longer description of the task. This is displayed when calling `task --summary [task]`. |
|
||||
| `aliases` | `[]string` | | A list of alternative names by which the task can be called. |
|
||||
| `sources` | `[]string` | | A list of sources to check before running this task. Relevant for `checksum` and `timestamp` methods. Can be file paths or star globs. |
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /changelog/
|
||||
sidebar_position: 8
|
||||
sidebar_position: 9
|
||||
---
|
||||
|
||||
# Changelog
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /community/
|
||||
sidebar_position: 9
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
# Сообщество
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /contributing/
|
||||
sidebar_position: 10
|
||||
sidebar_position: 11
|
||||
---
|
||||
|
||||
# Помощь проекту
|
||||
@ -17,6 +17,7 @@ sidebar_position: 10
|
||||
|
||||
- **Текущее состояние разработки** - Проверьте уже открытые PR. Есть ли открытые "issues", обсуждающие особенности/изменения, которые вы хотите выполнить? Пожалуйста, убедитесь, что вы учитываете результаты этих обсуждений в своей работе.
|
||||
- **Обратная совместимость** - Повлияют ли ваши изменения на уже существующие TaskFile'ы? Скорее всего, ваше изменение будет применено, если оно обладает обратной совместимостью. Существует ли подход, который вы можете использовать для поддержания обратной совместимости? Если нет, откройте проблему(Вот тут ["Issues"](https://github.com/go-task/task/issues)), чтобы изменения API могли быть обсуждены до того, как вы потратите своё время на PR.
|
||||
- **Experiments** - If there is no way to make your change backward compatible then there is a procedure to introduce breaking changes into minor versions. We call these "\[experiments\]\[experiments\]". If you're intending to work on an experiment, then please read the \[experiments workflow\]\[experiments-workflow\] document carefully and submit a proposal first.
|
||||
|
||||
## 1. Настройка
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /donate/
|
||||
sidebar_position: 13
|
||||
sidebar_position: 15
|
||||
---
|
||||
|
||||
# Поддержать
|
||||
|
@ -0,0 +1,54 @@
|
||||
---
|
||||
slug: /experiments/
|
||||
sidebar_position: 5
|
||||
---
|
||||
|
||||
# Experiments
|
||||
|
||||
:::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.
|
||||
|
||||
:::
|
||||
|
||||
In order to allow Task to evolve quickly, we roll out breaking changes to minor versions behind experimental flags. This allows us to gather feedback on breaking changes before committing to a major release. This document describes the current set of experimental features and the deprecated feature that they are intended to replace.
|
||||
|
||||
You can enable an experimental feature by:
|
||||
|
||||
1. Using the `--x-{feature}` flag. This is intended for one-off invocations of Task to test out experimental features. You can also disable a feature by specifying a falsy value such as `--x-{feature}=false`.
|
||||
1. Using the `TASK_X_{FEATURE}=1` environment variable. This is intended for permanently enabling experimental features in your environment.
|
||||
|
||||
Flags will always override environment variables.
|
||||
|
||||
## Current Experimental Features and Deprecations
|
||||
|
||||
Each section below details an experiment or deprecation and explains what the flags/environment variables to enable the experiment are and how the feature's behavior will change. It will also explain what you need to do to migrate any existing Taskfiles to the new behavior.
|
||||
|
||||
<!-- EXPERIMENT TEMPLATE - Include sections as necessary...
|
||||
|
||||
### ![experiment] <Feature> ([#{issue}](https://github.com/go-task/task/issues/{issue})), ...)
|
||||
|
||||
- Flag to enable: `--x-{feature}`
|
||||
- Env to enable: `TASK_X_{feature}`
|
||||
- Deprecates: {list any existing functionality that will be deprecated by this experiment}
|
||||
|
||||
{Short description of the feature}
|
||||
|
||||
{Short explanation of how users should migrate to the new behavior}
|
||||
|
||||
-->
|
||||
|
||||
### ![deprecated][] Version 2 Schema ([#1197][deprecate-version-2-schema])
|
||||
|
||||
The Taskfile v2 schema was introduced in March 2018 and replaced by version 3 in August the following year. Users have had a long time to update and so we feel that it is time to tidy up the codebase and focus on new functionality instead.
|
||||
|
||||
This notice does not mean that we are immediately removing support for version 2 schemas. However, support will not be extended to future major releases and we _strongly recommend_ that anybody still using a version 2 schema upgrades to version 3 as soon as possible.
|
||||
|
||||
A list of changes between version 2 and version 3 are available in the [Task v3 Release Notes][version-3-release-notes].
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
|
||||
[version-3-release-notes]: https://github.com/go-task/task/releases/tag/v3.0.0
|
||||
[deprecated]: https://img.shields.io/badge/deprecated-red
|
@ -0,0 +1,50 @@
|
||||
---
|
||||
slug: /experiments/workflow/
|
||||
---
|
||||
|
||||
# Workflow
|
||||
|
||||
Experiments are a way for us to test out new features in Task before committing to them in a major release. Because this concept is built around the idea of feedback from our community, we have built a workflow for the process of introducing these changes. This ensures that experiments are given the attention and time that they need and that we are getting the best possible results out of them.
|
||||
|
||||
The sections below describe the various stages that an experiment must go through from its proposal all the way to being released in a major version of Task.
|
||||
|
||||
## 1. Proposal
|
||||
|
||||
All experimental features start with a proposal in the form of a GitHub issue. If the maintainers decide that an issue has enough support and is a breaking change or is complex/controversial enough to require user feedback, then the issue will be marked with the ![proposal][] label. At this point, the issue becomes a proposal and a period of consultation begins. During this period, we request that users provide feedback on the proposal and how it might effect their use of Task. It is up to the discretion of the maintainers to decide how long this period lasts.
|
||||
|
||||
## 2. Draft
|
||||
|
||||
Once a proposal's consultation ends, a contributor may pick up the work and begin the initial implementation. Once a PR is opened, the maintainers will ensure that it meets the requirements for an experimental feature (i.e. flags are in the right format etc) and merge the feature. Once this code is released, the status will be updated via the ![draft][] label. This indicates that an implementation is now available for use in a release and the experiment is open for feedback.
|
||||
|
||||
:::note
|
||||
|
||||
During the draft period, major changes to the implementation may be made based on the feedback received from users. There are _no stability guarantees_ and experimental features may be abandoned _at any time_.
|
||||
|
||||
:::
|
||||
|
||||
## 3. Candidate
|
||||
|
||||
Once an acceptable level of consensus has been reached by the community and feedback/changes are less frequent/significant, the status may be updated via the ![candidate][] label. This indicates that a proposal is _likely_ to accepted and will enter a period for final comments and minor changes.
|
||||
|
||||
## 4. Stable
|
||||
|
||||
Once a suitable amount of time has passed with no changes or feedback, an experiment will be given the ![stable][] label. At this point, the functionality will be treated like any other feature in Task and any changes _must_ be backward compatible. This allows users to migrate to the new functionality without having to worry about anything breaking in future releases. This provides the best experience for users migrating to a new major version.
|
||||
|
||||
## 5. Released
|
||||
|
||||
When making a new major release of Task, all experiments marked as ![stable][] will move to ![released][] and their behaviors will become the new default in Task. Experiments in an earlier stage (i.e. not stable) cannot be released and so will continue to be experiments in the new version.
|
||||
|
||||
## Abandoned / Superseded
|
||||
|
||||
If an experiment is unsuccessful at any point then it will be given the ![abandoned][] or ![superseded][] labels depending on which is more suitable. These experiments will be removed from Task.
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
[proposal]: https://img.shields.io/badge/experiment:%20proposal-purple
|
||||
[draft]: https://img.shields.io/badge/experiment:%20draft-purple
|
||||
[candidate]: https://img.shields.io/badge/experiment:%20candidate-purple
|
||||
[stable]: https://img.shields.io/badge/experiment:%20stable-purple
|
||||
[released]: https://img.shields.io/badge/experiment:%20released-purple
|
||||
[abandoned]: https://img.shields.io/badge/experiment:%20abandoned-purple
|
||||
[superseded]: https://img.shields.io/badge/experiment:%20superseded-purple
|
@ -1,15 +1,12 @@
|
||||
---
|
||||
slug: /faq/
|
||||
sidebar_position: 6
|
||||
sidebar_position: 7
|
||||
---
|
||||
|
||||
# FAQ
|
||||
|
||||
This page contains a list of frequently asked questions about Task.
|
||||
|
||||
- [Why won't my task update my shell environment?](#why-wont-my-task-update-my-shell-environment)
|
||||
- ['x' builtin command doesn't work on Windows](#x-builtin-command-doesnt-work-on-windows)
|
||||
|
||||
## Why won't my task update my shell environment?
|
||||
|
||||
This is a limitation of how shells work. Task runs as a subprocess of your current shell, so it can't change the environment of the shell that started it. This limitation is shared by other task runners and build tools too.
|
||||
@ -25,6 +22,52 @@ my-shell-env:
|
||||
|
||||
Now run `eval $(task my-shell-env)` and the variables `$FOO` and `$BAR` will be available in your shell.
|
||||
|
||||
## I can't reuse my shell in a task's commands
|
||||
|
||||
Task runs each command as a separate shell process, so something you do in one command won't effect any future commands. For example, this won't work:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
foo:
|
||||
cmds:
|
||||
- a=foo
|
||||
- echo $a
|
||||
# outputs ""
|
||||
```
|
||||
|
||||
To work around this you can either use a multiline command:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
foo:
|
||||
cmds:
|
||||
- |
|
||||
a=foo
|
||||
echo $a
|
||||
# outputs "foo"
|
||||
```
|
||||
|
||||
Or for more complex multi-line commands it is recommended to move your code into a separate file and call that instead:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
foo:
|
||||
cmds:
|
||||
- ./foo-printer.bash
|
||||
```
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
a=foo
|
||||
echo $a
|
||||
```
|
||||
|
||||
## 'x' builtin command doesn't work on Windows
|
||||
|
||||
The default shell on Windows (`cmd` and `powershell`) do not have commands like `rm` and `cp` available as builtins. This means that these commands won't work. If you want to make your Taskfile fully cross-platform, you'll need to work around this limitation using one of the following methods:
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /integrations/
|
||||
sidebar_position: 5
|
||||
sidebar_position: 6
|
||||
---
|
||||
|
||||
# Интеграции
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /releasing/
|
||||
sidebar_position: 11
|
||||
sidebar_position: 13
|
||||
---
|
||||
|
||||
# Релизы
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /styleguide/
|
||||
sidebar_position: 7
|
||||
sidebar_position: 8
|
||||
---
|
||||
|
||||
# Стайлгайд
|
||||
@ -207,3 +207,27 @@ tasks:
|
||||
```
|
||||
|
||||
Это также происходит автоматически при использовании включенных Taskfiles.
|
||||
|
||||
## Prefer external scripts over complex multi-line commands
|
||||
|
||||
```yaml
|
||||
# bad
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
build:
|
||||
cmds:
|
||||
- |
|
||||
for i in $(seq 1 10); do
|
||||
echo $i
|
||||
echo "some other complex logic"
|
||||
done'
|
||||
|
||||
# good
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
build:
|
||||
cmds:
|
||||
- ./scripts/my_complex_script.sh
|
||||
```
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /taskfile-versions/
|
||||
sidebar_position: 12
|
||||
sidebar_position: 14
|
||||
---
|
||||
|
||||
# Версии Taskfile
|
||||
@ -13,145 +13,7 @@ sidebar_position: 12
|
||||
|
||||
`version:` ключ Taskfile принимает [semVer](https://semver.org/lang/ru/) строку. Пример: `2`, `2.0` или `2.0.0`. Если вы решите использовать Task версии `2.0`, то у вас не будет доступа к функциям версии `2.1`, но если вы решите использовать версию `2`, то любые функции версий `2.x.x` будут доступны, но не `3.0.0+`.
|
||||
|
||||
## Версия 1
|
||||
|
||||
> ПРИМЕЧАНИЕ: Taskfiles версии 1 больше не поддерживаются в версии Task >= v3.0.0.
|
||||
|
||||
В первой версии `Taskfile` поле `version:` не доступно, потому что задачи были в корне документа YAML. Пример:
|
||||
|
||||
```yaml
|
||||
echo:
|
||||
cmds:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
Порядок приоритетов переменных также отличается:
|
||||
|
||||
1. Вызов переменных
|
||||
2. Переменные среды
|
||||
3. Переменные Task
|
||||
4. Переменные `Taskvars.yml`
|
||||
|
||||
## Версия 2.0
|
||||
|
||||
В версии 2 был добавлен ключ `version: `. Он позволяет выпускать обновления сохраняя обратную совместимость. Пример использования:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
echo:
|
||||
cmds:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
Версия 2 позволяет создавать глобальные переменные непосредственно в Taskfile, если вы не хотите создавать `Taskvars.yml`:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
vars:
|
||||
GREETING: Hello, World!
|
||||
|
||||
tasks:
|
||||
greet:
|
||||
cmds:
|
||||
- echo "{{.GREETING}}"
|
||||
```
|
||||
|
||||
Порядок приоритетов переменных также отличается:
|
||||
|
||||
1. Переменные Task
|
||||
2. Call variables
|
||||
3. Переменные Taskfile
|
||||
4. Переменные `Taskvars.yml`
|
||||
5. Переменные окружения
|
||||
|
||||
Добавлена новая глобальная опция для настройки количества расширений переменных (по умолчанию 2):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
expansions: 3
|
||||
|
||||
vars:
|
||||
FOO: foo
|
||||
BAR: bar
|
||||
BAZ: baz
|
||||
FOOBAR: '{{.FOO}}{{.BAR}}'
|
||||
FOOBARBAZ: '{{.FOOBAR}}{{.BAZ}}'
|
||||
|
||||
tasks:
|
||||
default:
|
||||
cmds:
|
||||
- echo "{{.FOOBARBAZ}}"
|
||||
```
|
||||
|
||||
## Версия 2.1
|
||||
|
||||
В версии 2.1 появилась глобальная опция `output`, которая позволяет иметь больше контроля над тем, как вывод команд печатается на консоли (см. [документацию][output]):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
output: prefixed
|
||||
|
||||
tasks:
|
||||
server:
|
||||
cmds:
|
||||
- go run main.go
|
||||
prefix: server
|
||||
```
|
||||
|
||||
Начиная с этой версии можно игнорировать ошибки команды или задачи (смотрите документацию [здесь][ignore_errors]):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
example-1:
|
||||
cmds:
|
||||
- cmd: exit 1
|
||||
ignore_error: true
|
||||
- echo "This will be print"
|
||||
|
||||
example-2:
|
||||
cmds:
|
||||
- exit 1
|
||||
- echo "This will be print"
|
||||
ignore_error: true
|
||||
```
|
||||
|
||||
## Версия 2.2
|
||||
|
||||
В Версии 2.2 появилась новая глобальная опция `includes`, которая позволяет импортировать другие Taskfile'ы:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
includes:
|
||||
docs: ./documentation # will look for ./documentation/Taskfile.yml
|
||||
docker: ./DockerTasks.yml
|
||||
```
|
||||
|
||||
## Версия 2.6
|
||||
|
||||
Версия 2.6 поставляется с `preconditions` опцией в задачах.
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
upload_environment:
|
||||
preconditions:
|
||||
- test -f .env
|
||||
cmds:
|
||||
- aws s3 cp .env s3://myenvironment
|
||||
```
|
||||
|
||||
Пожалуйста, проверьте [документацию][includes]
|
||||
|
||||
## Версия 3
|
||||
## Version 3 ![latest](https://img.shields.io/badge/latest-brightgreen)
|
||||
|
||||
Основные изменения, сделанные в `v3`:
|
||||
|
||||
@ -200,9 +62,179 @@ tasks:
|
||||
- Был произведён большой рефакторинг обработки переменных. Теперь всё стало более прозрачно. The `expansions:` setting was removed as it became unnecessary. Это порядок, в котором Task будет обрабатывать переменные, каждый уровень может видеть переменные, объявленные на предыдущем и переопределять их.
|
||||
- Переменные окружения
|
||||
- Глобальные + CLI переменные
|
||||
- Call variables
|
||||
- Вызов переменных
|
||||
- Переменные Task
|
||||
|
||||
## Версия 2.6
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
Версия 2.6 поставляется с `preconditions` опцией в задачах.
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
upload_environment:
|
||||
preconditions:
|
||||
- test -f .env
|
||||
cmds:
|
||||
- aws s3 cp .env s3://myenvironment
|
||||
```
|
||||
|
||||
Пожалуйста, проверьте [документацию][includes]
|
||||
|
||||
## Версия 2.2
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
В Версии 2.2 появилась новая глобальная опция `includes`, которая позволяет импортировать другие Taskfile'ы:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
includes:
|
||||
docs: ./documentation # will look for ./documentation/Taskfile.yml
|
||||
docker: ./DockerTasks.yml
|
||||
```
|
||||
|
||||
## Версия 2.1
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
В версии 2.1 появилась глобальная опция `output`, которая позволяет иметь больше контроля над тем, как вывод команд печатается на консоли (см. [документацию][output]):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
output: prefixed
|
||||
|
||||
tasks:
|
||||
server:
|
||||
cmds:
|
||||
- go run main.go
|
||||
prefix: server
|
||||
```
|
||||
|
||||
Начиная с этой версии можно игнорировать ошибки команды или задачи (смотрите документацию [здесь][ignore_errors]):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
example-1:
|
||||
cmds:
|
||||
- cmd: exit 1
|
||||
ignore_error: true
|
||||
- echo "This will be print"
|
||||
|
||||
example-2:
|
||||
cmds:
|
||||
- exit 1
|
||||
- echo "This will be print"
|
||||
ignore_error: true
|
||||
```
|
||||
|
||||
## Версия 2.0
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
В версии 2 был добавлен ключ `version: `. Он позволяет выпускать обновления сохраняя обратную совместимость. Пример использования:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
echo:
|
||||
cmds:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
Версия 2 позволяет создавать глобальные переменные непосредственно в Taskfile, если вы не хотите создавать `Taskvars.yml`:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
vars:
|
||||
GREETING: Hello, World!
|
||||
|
||||
tasks:
|
||||
greet:
|
||||
cmds:
|
||||
- echo "{{.GREETING}}"
|
||||
```
|
||||
|
||||
Порядок приоритетов переменных также отличается:
|
||||
|
||||
1. Переменные Task
|
||||
2. Call variables
|
||||
3. Переменные Taskfile
|
||||
4. Переменные `Taskvars.yml`
|
||||
5. Environment variables
|
||||
|
||||
Добавлена новая глобальная опция для настройки количества расширений переменных (по умолчанию 2):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
expansions: 3
|
||||
|
||||
vars:
|
||||
FOO: foo
|
||||
BAR: bar
|
||||
BAZ: baz
|
||||
FOOBAR: '{{.FOO}}{{.BAR}}'
|
||||
FOOBARBAZ: '{{.FOOBAR}}{{.BAZ}}'
|
||||
|
||||
tasks:
|
||||
default:
|
||||
cmds:
|
||||
- echo "{{.FOOBARBAZ}}"
|
||||
```
|
||||
|
||||
## Версия 1
|
||||
|
||||
:::caution
|
||||
|
||||
v1 schema support was removed in Task >= v3.0.0.
|
||||
|
||||
:::
|
||||
|
||||
В первой версии `Taskfile` поле `version:` не доступно, потому что задачи были в корне документа YAML. Пример:
|
||||
|
||||
```yaml
|
||||
echo:
|
||||
cmds:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
Порядок приоритетов переменных также отличается:
|
||||
|
||||
1. Call variables
|
||||
2. Переменные среды
|
||||
3. Переменные Task
|
||||
4. Переменные `Taskvars.yml`
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
[output]: usage.md#output-syntax
|
||||
[ignore_errors]: usage.md#ignore-errors
|
||||
[includes]: usage.md#including-other-taskfiles
|
||||
[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /translate/
|
||||
sidebar_position: 14
|
||||
sidebar_position: 12
|
||||
---
|
||||
|
||||
# Перевод
|
||||
|
@ -1053,6 +1053,60 @@ tasks:
|
||||
- echo "{{.MESSAGE}}"
|
||||
```
|
||||
|
||||
## Warning Prompts
|
||||
|
||||
Warning Prompts to prompt a user for confirmation before a task is executed.
|
||||
|
||||
Below is an example using `prompt` with a dangerous command, that is called between two safe commands:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
example:
|
||||
cmds:
|
||||
- task: not-dangerous
|
||||
- task: dangerous
|
||||
- task: another-not-dangerous
|
||||
|
||||
not-dangerous:
|
||||
cmds:
|
||||
- echo 'not dangerous command'
|
||||
|
||||
another-not-dangerous:
|
||||
cmds:
|
||||
- echo 'another not dangerous command'
|
||||
|
||||
dangerous:
|
||||
prompt: This is a dangerous command... Do you want to continue?
|
||||
cmds:
|
||||
- echo 'dangerous command'
|
||||
```
|
||||
|
||||
```bash
|
||||
❯ task dangerous
|
||||
task: "This is a dangerous command... Do you want to continue?" [y/N]
|
||||
```
|
||||
|
||||
Warning prompts are called before executing a task. If a prompt is denied Task will exit with [exit code](api_reference.md#exit-codes) 205. If approved, Task will continue as normal.
|
||||
|
||||
```bash
|
||||
❯ task example
|
||||
not dangerous command
|
||||
task: "This is a dangerous command. Do you want to continue?" [y/N]
|
||||
y
|
||||
dangerous command
|
||||
another not dangerous command
|
||||
```
|
||||
|
||||
To skip warning prompts automatically, you can use the `--yes` (alias `-y`) option when calling the task. By including this option, all warnings, will be automatically confirmed, and no prompts will be shown.
|
||||
|
||||
:::caution
|
||||
|
||||
Tasks with prompts always fail by default on non-terminal environments, like a CI, where an `stdin` won't be available for the user to answer. In cases like, use `--yes` (`-y`) to force all tasks with a prompt to run.
|
||||
|
||||
:::
|
||||
|
||||
## Silent mode
|
||||
|
||||
Silent mode disables the echoing of commands before Task runs it. For the following Taskfile:
|
||||
|
@ -43,6 +43,7 @@ task [--flags] [tasks...] [-- CLI_ARGS...]
|
||||
| | `--output-group-error-only` | `bool` | `false` | 在退出码为 0 时忽略命令输出。 |
|
||||
| `-p` | `--parallel` | `bool` | `false` | 并行执行命令行上提供的 task。 |
|
||||
| `-s` | `--silent` | `bool` | `false` | 禁用回显。 |
|
||||
| `-y` | `--yes` | `bool` | `false` | Assume "yes" as answer to all prompts. |
|
||||
| | `--status` | `bool` | `false` | 如果任何给定 task 不是最新的,则以非 0 退出码退出。 |
|
||||
| | `--summary` | `bool` | `false` | 显示有关 task 的摘要。 |
|
||||
| `-t` | `--taskfile` | `string` | `Taskfile.yml` 或 `Taskfile.yaml` | |
|
||||
@ -52,7 +53,7 @@ task [--flags] [tasks...] [-- CLI_ARGS...]
|
||||
|
||||
## 退出码
|
||||
|
||||
Task 有时会以特定的退出代码退出。 这些代码分为三组,范围如下:
|
||||
Task 有时会以特定的退出代码退出。 These codes are split into three groups with the following ranges:
|
||||
|
||||
- 一般错误 (0-99)
|
||||
- Taskfile 错误 (100-199)
|
||||
@ -60,30 +61,33 @@ Task 有时会以特定的退出代码退出。 这些代码分为三组,范
|
||||
|
||||
可以在下面找到退出代码及其描述的完整列表:
|
||||
|
||||
| 代码 | 描述 |
|
||||
| --- | ---------------------- |
|
||||
| 0 | 成功 |
|
||||
| 1 | 出现未知错误 |
|
||||
| 100 | 找不到 Taskfile |
|
||||
| 101 | 尝试初始化一个 Taskfile 时已经存在 |
|
||||
| 102 | Taskfile 无效或无法解析 |
|
||||
| 200 | 找不到指定的 task |
|
||||
| 201 | 在 task 中执行命令时出错 |
|
||||
| 202 | 用户试图调用内部 task |
|
||||
| 203 | 有多个具有相同名称或别名的 task |
|
||||
| 204 | 一个 task 被调用了太多次 |
|
||||
| 代码 | 描述 |
|
||||
| --- | -------------------------------- |
|
||||
| 0 | 成功 |
|
||||
| 1 | 出现未知错误 |
|
||||
| 100 | 找不到 Taskfile |
|
||||
| 101 | 尝试初始化一个 Taskfile 时已经存在 |
|
||||
| 102 | Taskfile 无效或无法解析 |
|
||||
| 200 | 找不到指定的 task |
|
||||
| 201 | 在 task 中执行命令时出错 |
|
||||
| 202 | 用户试图调用内部 task |
|
||||
| 203 | 有多个具有相同名称或别名的 task |
|
||||
| 204 | 一个 task 被调用了太多次 |
|
||||
| 205 | A task was cancelled by the user |
|
||||
|
||||
这些代码也可以在存储库的 [`errors/errors.go`](https://github.com/go-task/task/blob/main/errors/errors.go) 中找到。
|
||||
These codes can also be found in the repository in [`errors/errors.go`](https://github.com/go-task/task/blob/main/errors/errors.go).
|
||||
|
||||
:::info
|
||||
当使用 `-x`/`--exit-code` 标志运行 Task 时,任何失败命令的退出代码都将传递给用户。
|
||||
|
||||
When Task is run with the `-x`/`--exit-code` flag, the exit code of any failed commands will be passed through to the user instead.
|
||||
|
||||
:::
|
||||
|
||||
## JSON 输出
|
||||
|
||||
将 `--json` 标志与 `--list` 或 `--list-all` 标志结合使用时,将输出具有以下结构的 JSON 对象:
|
||||
|
||||
```jsonc
|
||||
```json
|
||||
{
|
||||
"tasks": [
|
||||
{
|
||||
@ -202,6 +206,7 @@ vars:
|
||||
| `deps` | [`[]Dependency`](#dependency) | | 此 task 的依赖项列表。 此处定义的 task 将在此 task 之前并行运行。 |
|
||||
| `label` | `string` | | 运行 task 时覆盖输出中的 task 名称。 支持变量。 |
|
||||
| `desc` | `string` | | task 的简短描述。 这在调用 `task --list` 时显示。 |
|
||||
| `prompt` | `string` | | A prompt that will be presented before a task is run. Declining will cancel running the current and any subsequent tasks. |
|
||||
| `summary` | `string` | | task 的较长描述。 这在调用 `task --summary [task]` 时显示。 |
|
||||
| `aliases` | `[]string` | | 可以调用 task 的别名列表。 |
|
||||
| `sources` | `[]string` | | 运行此 task 之前要检查的源列表。 与 `checksum` 和 `timestamp` 方法相关。 可以是文件路径或星号。 |
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /changelog/
|
||||
sidebar_position: 8
|
||||
sidebar_position: 9
|
||||
---
|
||||
|
||||
# 更新日志
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /community/
|
||||
sidebar_position: 9
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
# 社区
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /contributing/
|
||||
sidebar_position: 10
|
||||
sidebar_position: 11
|
||||
---
|
||||
|
||||
# 贡献
|
||||
@ -17,6 +17,7 @@ sidebar_position: 10
|
||||
|
||||
- **检查已有工作** - 是否已经存在 PR? 是否存在 Issue 正在讨论您要进行的功能/更改? 请确保你的工作中确实考虑了这些相关的讨论内容。
|
||||
- **向后兼容** - 你的变更是否破坏了已经存在的 Taskfile? 向后兼容的变更会更容易被合并进去。 您是否可以采取一种方法来保持这种兼容性? 如果没有,请考虑先提出一个 Issue,以便在您投入时间进行 PR 之前讨论 API 的更改。
|
||||
- **Experiments** - If there is no way to make your change backward compatible then there is a procedure to introduce breaking changes into minor versions. We call these "\[experiments\]\[experiments\]". If you're intending to work on an experiment, then please read the \[experiments workflow\]\[experiments-workflow\] document carefully and submit a proposal first.
|
||||
|
||||
## 1. 设置
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /donate/
|
||||
sidebar_position: 13
|
||||
sidebar_position: 15
|
||||
---
|
||||
|
||||
# 赞助
|
||||
|
@ -0,0 +1,54 @@
|
||||
---
|
||||
slug: /experiments/
|
||||
sidebar_position: 5
|
||||
---
|
||||
|
||||
# Experiments
|
||||
|
||||
:::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.
|
||||
|
||||
:::
|
||||
|
||||
In order to allow Task to evolve quickly, we roll out breaking changes to minor versions behind experimental flags. This allows us to gather feedback on breaking changes before committing to a major release. This document describes the current set of experimental features and the deprecated feature that they are intended to replace.
|
||||
|
||||
You can enable an experimental feature by:
|
||||
|
||||
1. Using the `--x-{feature}` flag. This is intended for one-off invocations of Task to test out experimental features. You can also disable a feature by specifying a falsy value such as `--x-{feature}=false`.
|
||||
1. Using the `TASK_X_{FEATURE}=1` environment variable. This is intended for permanently enabling experimental features in your environment.
|
||||
|
||||
Flags will always override environment variables.
|
||||
|
||||
## Current Experimental Features and Deprecations
|
||||
|
||||
Each section below details an experiment or deprecation and explains what the flags/environment variables to enable the experiment are and how the feature's behavior will change. It will also explain what you need to do to migrate any existing Taskfiles to the new behavior.
|
||||
|
||||
<!-- EXPERIMENT TEMPLATE - Include sections as necessary...
|
||||
|
||||
### ![experiment] <Feature> ([#{issue}](https://github.com/go-task/task/issues/{issue})), ...)
|
||||
|
||||
- Flag to enable: `--x-{feature}`
|
||||
- Env to enable: `TASK_X_{feature}`
|
||||
- Deprecates: {list any existing functionality that will be deprecated by this experiment}
|
||||
|
||||
{Short description of the feature}
|
||||
|
||||
{Short explanation of how users should migrate to the new behavior}
|
||||
|
||||
-->
|
||||
|
||||
### ![deprecated][] Version 2 Schema ([#1197][deprecate-version-2-schema])
|
||||
|
||||
The Taskfile v2 schema was introduced in March 2018 and replaced by version 3 in August the following year. Users have had a long time to update and so we feel that it is time to tidy up the codebase and focus on new functionality instead.
|
||||
|
||||
This notice does not mean that we are immediately removing support for version 2 schemas. However, support will not be extended to future major releases and we _strongly recommend_ that anybody still using a version 2 schema upgrades to version 3 as soon as possible.
|
||||
|
||||
A list of changes between version 2 and version 3 are available in the [Task v3 Release Notes][version-3-release-notes].
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
|
||||
[version-3-release-notes]: https://github.com/go-task/task/releases/tag/v3.0.0
|
||||
[deprecated]: https://img.shields.io/badge/deprecated-red
|
@ -0,0 +1,50 @@
|
||||
---
|
||||
slug: /experiments/workflow/
|
||||
---
|
||||
|
||||
# Workflow
|
||||
|
||||
Experiments are a way for us to test out new features in Task before committing to them in a major release. Because this concept is built around the idea of feedback from our community, we have built a workflow for the process of introducing these changes. This ensures that experiments are given the attention and time that they need and that we are getting the best possible results out of them.
|
||||
|
||||
The sections below describe the various stages that an experiment must go through from its proposal all the way to being released in a major version of Task.
|
||||
|
||||
## 1. Proposal
|
||||
|
||||
All experimental features start with a proposal in the form of a GitHub issue. If the maintainers decide that an issue has enough support and is a breaking change or is complex/controversial enough to require user feedback, then the issue will be marked with the ![proposal][] label. At this point, the issue becomes a proposal and a period of consultation begins. During this period, we request that users provide feedback on the proposal and how it might effect their use of Task. It is up to the discretion of the maintainers to decide how long this period lasts.
|
||||
|
||||
## 2. Draft
|
||||
|
||||
Once a proposal's consultation ends, a contributor may pick up the work and begin the initial implementation. Once a PR is opened, the maintainers will ensure that it meets the requirements for an experimental feature (i.e. flags are in the right format etc) and merge the feature. Once this code is released, the status will be updated via the ![draft][] label. This indicates that an implementation is now available for use in a release and the experiment is open for feedback.
|
||||
|
||||
:::note
|
||||
|
||||
During the draft period, major changes to the implementation may be made based on the feedback received from users. There are _no stability guarantees_ and experimental features may be abandoned _at any time_.
|
||||
|
||||
:::
|
||||
|
||||
## 3. Candidate
|
||||
|
||||
Once an acceptable level of consensus has been reached by the community and feedback/changes are less frequent/significant, the status may be updated via the ![candidate][] label. This indicates that a proposal is _likely_ to accepted and will enter a period for final comments and minor changes.
|
||||
|
||||
## 4. Stable
|
||||
|
||||
Once a suitable amount of time has passed with no changes or feedback, an experiment will be given the ![stable][] label. At this point, the functionality will be treated like any other feature in Task and any changes _must_ be backward compatible. This allows users to migrate to the new functionality without having to worry about anything breaking in future releases. This provides the best experience for users migrating to a new major version.
|
||||
|
||||
## 5. Released
|
||||
|
||||
When making a new major release of Task, all experiments marked as ![stable][] will move to ![released][] and their behaviors will become the new default in Task. Experiments in an earlier stage (i.e. not stable) cannot be released and so will continue to be experiments in the new version.
|
||||
|
||||
## Abandoned / Superseded
|
||||
|
||||
If an experiment is unsuccessful at any point then it will be given the ![abandoned][] or ![superseded][] labels depending on which is more suitable. These experiments will be removed from Task.
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
[proposal]: https://img.shields.io/badge/experiment:%20proposal-purple
|
||||
[draft]: https://img.shields.io/badge/experiment:%20draft-purple
|
||||
[candidate]: https://img.shields.io/badge/experiment:%20candidate-purple
|
||||
[stable]: https://img.shields.io/badge/experiment:%20stable-purple
|
||||
[released]: https://img.shields.io/badge/experiment:%20released-purple
|
||||
[abandoned]: https://img.shields.io/badge/experiment:%20abandoned-purple
|
||||
[superseded]: https://img.shields.io/badge/experiment:%20superseded-purple
|
@ -1,15 +1,12 @@
|
||||
---
|
||||
slug: /faq/
|
||||
sidebar_position: 6
|
||||
sidebar_position: 7
|
||||
---
|
||||
|
||||
# 常见问题
|
||||
|
||||
此页面包含有关 Task 的常见问题列表。
|
||||
|
||||
- [为什么我的 task 不会更新我的 shell 环境?](#为什么我的-task-不会更新我的-shell-环境)
|
||||
- [内置的 'x' 命令在 Windows 上不起作用](#内置的-x-命令在-windows-上不起作用)
|
||||
|
||||
## 为什么我的 task 不会更新我的 shell 环境?
|
||||
|
||||
这是 shell 工作方式的限制。 Task 作为当前 shell 的子进程运行,因此它不能更改启动它的 shell 的环境。 其他任务运行器和构建工具也有此限制。
|
||||
@ -25,6 +22,52 @@ my-shell-env:
|
||||
|
||||
现在运行 `eval $(task my-shell-env)` 变量 `$FOO` 和 `$BAR` 将在您的 shell 中可用。
|
||||
|
||||
## I can't reuse my shell in a task's commands
|
||||
|
||||
Task runs each command as a separate shell process, so something you do in one command won't effect any future commands. For example, this won't work:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
foo:
|
||||
cmds:
|
||||
- a=foo
|
||||
- echo $a
|
||||
# outputs ""
|
||||
```
|
||||
|
||||
To work around this you can either use a multiline command:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
foo:
|
||||
cmds:
|
||||
- |
|
||||
a=foo
|
||||
echo $a
|
||||
# outputs "foo"
|
||||
```
|
||||
|
||||
Or for more complex multi-line commands it is recommended to move your code into a separate file and call that instead:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
foo:
|
||||
cmds:
|
||||
- ./foo-printer.bash
|
||||
```
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
a=foo
|
||||
echo $a
|
||||
```
|
||||
|
||||
## 内置的 'x' 命令在 Windows 上不起作用
|
||||
|
||||
Windows 上的默认 shell(`cmd` 和 `powershell`)没有像 `rm` 和 `cp` 这样的内置命令。 这意味着这些命令将不起作用。 如果你想让你的 Taskfile 完全跨平台,你需要使用以下方法之一来解决这个限制:
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /integrations/
|
||||
sidebar_position: 5
|
||||
sidebar_position: 6
|
||||
---
|
||||
|
||||
# 集成
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /releasing/
|
||||
sidebar_position: 11
|
||||
sidebar_position: 13
|
||||
---
|
||||
|
||||
# 发布
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /styleguide/
|
||||
sidebar_position: 7
|
||||
sidebar_position: 8
|
||||
---
|
||||
|
||||
# 风格指南
|
||||
@ -207,3 +207,27 @@ tasks:
|
||||
```
|
||||
|
||||
这在使用包含的任务文件时也会自动完成。
|
||||
|
||||
## Prefer external scripts over complex multi-line commands
|
||||
|
||||
```yaml
|
||||
# bad
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
build:
|
||||
cmds:
|
||||
- |
|
||||
for i in $(seq 1 10); do
|
||||
echo $i
|
||||
echo "some other complex logic"
|
||||
done'
|
||||
|
||||
# good
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
build:
|
||||
cmds:
|
||||
- ./scripts/my_complex_script.sh
|
||||
```
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /taskfile-versions/
|
||||
sidebar_position: 12
|
||||
sidebar_position: 14
|
||||
---
|
||||
|
||||
# Taskfile 版本
|
||||
@ -13,145 +13,7 @@ Taskfile 版本遵循 Task 版本。 例如, taskfile version `2` 意味着应
|
||||
|
||||
Taskfile 文件的 `version:` 关键字接受语义化字符串, 所以 `2`, `2.0` 或 `2.0.0` 都可以。 如果使用版本号 `2.0`,那么 Task 就不会使用 `2.1` 的功能, 但如果使用版本号 `2`, 那么任意 `2.x.x` 版本中的功能都是可用的, 但 `3.0.0+` 的功能不可用。
|
||||
|
||||
## 版本 1
|
||||
|
||||
> 注意:Task v3.0.0 以后就不再支持 Taskfiles 的 1 版本了。
|
||||
|
||||
最初的 `Taskfile` 并不支持 `version:` 关键字,因为 YAML 文档中的根属性都是 task。 就像这样:
|
||||
|
||||
```yaml
|
||||
echo:
|
||||
cmds:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
变量的优先级也不同:
|
||||
|
||||
1. 调用变量
|
||||
2. 环境变量
|
||||
3. Task 变量
|
||||
4. `Taskvars.yml` 定义变量
|
||||
|
||||
## 版本 2.0
|
||||
|
||||
到了 2.0 版本,我们引入了 `version:` 字段, 在不破坏已存在的 Taskfiles 的前提下,在 Task 中引入新功能。 新语法如下:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
echo:
|
||||
cmds:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
如果您不想创建 `Taskvars.yml`,版本 2 允许您直接在 Taskfile 中写入全局变量:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
vars:
|
||||
GREETING: Hello, World!
|
||||
|
||||
tasks:
|
||||
greet:
|
||||
cmds:
|
||||
- echo "{{.GREETING}}"
|
||||
```
|
||||
|
||||
变量的优先级调整为:
|
||||
|
||||
1. Task 变量
|
||||
2. 调用变量
|
||||
3. Taskfile 定义变量
|
||||
4. Taskvars 文件定义变量
|
||||
5. 环境变量
|
||||
|
||||
添加了一个新的全局配置项来配置变量扩展的数量(默认为 2):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
expansions: 3
|
||||
|
||||
vars:
|
||||
FOO: foo
|
||||
BAR: bar
|
||||
BAZ: baz
|
||||
FOOBAR: '{{.FOO}}{{.BAR}}'
|
||||
FOOBARBAZ: '{{.FOOBAR}}{{.BAZ}}'
|
||||
|
||||
tasks:
|
||||
default:
|
||||
cmds:
|
||||
- echo "{{.FOOBARBAZ}}"
|
||||
```
|
||||
|
||||
## 版本 2.1
|
||||
|
||||
2.1 版包括一个全局 `output` 选项,以允许更好地控制如何将命令输出打印到控制台(有关更多信息,请参阅 [文档][output]):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
output: prefixed
|
||||
|
||||
tasks:
|
||||
server:
|
||||
cmds:
|
||||
- go run main.go
|
||||
prefix: server
|
||||
```
|
||||
|
||||
从这个版本开始,也可以忽略命令或 task 的错误(在 [此处][ignore_errors] 查看文档):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
example-1:
|
||||
cmds:
|
||||
- cmd: exit 1
|
||||
ignore_error: true
|
||||
- echo "This will be print"
|
||||
|
||||
example-2:
|
||||
cmds:
|
||||
- exit 1
|
||||
- echo "This will be print"
|
||||
ignore_error: true
|
||||
```
|
||||
|
||||
## 版本 2.2
|
||||
|
||||
2.2 版带有全局 `includes` 选项来包含其他 Taskfiles:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
includes:
|
||||
docs: ./documentation # will look for ./documentation/Taskfile.yml
|
||||
docker: ./DockerTasks.yml
|
||||
```
|
||||
|
||||
## 版本 2.6
|
||||
|
||||
2.6 版本增加任务的先决条件字段 `preconditions`。
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
upload_environment:
|
||||
preconditions:
|
||||
- test -f .env
|
||||
cmds:
|
||||
- aws s3 cp .env s3://myenvironment
|
||||
```
|
||||
|
||||
请检查 [文档][includes]
|
||||
|
||||
## 版本 3
|
||||
## Version 3 ![latest](https://img.shields.io/badge/latest-brightgreen)
|
||||
|
||||
以下是 `v3` 所做的一些主要变更:
|
||||
|
||||
@ -203,6 +65,176 @@ tasks:
|
||||
- 调用变量
|
||||
- Task 变量
|
||||
|
||||
## 版本 2.6
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
2.6 版本增加任务的先决条件字段 `preconditions`。
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
upload_environment:
|
||||
preconditions:
|
||||
- test -f .env
|
||||
cmds:
|
||||
- aws s3 cp .env s3://myenvironment
|
||||
```
|
||||
|
||||
请检查 [文档][includes]
|
||||
|
||||
## 版本 2.2
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
2.2 版带有全局 `includes` 选项来包含其他 Taskfiles:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
includes:
|
||||
docs: ./documentation # will look for ./documentation/Taskfile.yml
|
||||
docker: ./DockerTasks.yml
|
||||
```
|
||||
|
||||
## 版本 2.1
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
2.1 版包括一个全局 `output` 选项,以允许更好地控制如何将命令输出打印到控制台(有关更多信息,请参阅 [文档][output]):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
output: prefixed
|
||||
|
||||
tasks:
|
||||
server:
|
||||
cmds:
|
||||
- go run main.go
|
||||
prefix: server
|
||||
```
|
||||
|
||||
从这个版本开始,也可以忽略命令或 task 的错误(在 [此处][ignore_errors] 查看文档):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
example-1:
|
||||
cmds:
|
||||
- cmd: exit 1
|
||||
ignore_error: true
|
||||
- echo "This will be print"
|
||||
|
||||
example-2:
|
||||
cmds:
|
||||
- exit 1
|
||||
- echo "This will be print"
|
||||
ignore_error: true
|
||||
```
|
||||
|
||||
## 版本 2.0
|
||||
|
||||
:::caution
|
||||
|
||||
v2 schema support is [deprecated][deprecate-version-2-schema] and will be removed in a future release.
|
||||
|
||||
:::
|
||||
|
||||
到了 2.0 版本,我们引入了 `version:` 字段, 在不破坏已存在的 Taskfiles 的前提下,在 Task 中引入新功能。 新语法如下:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
tasks:
|
||||
echo:
|
||||
cmds:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
如果您不想创建 `Taskvars.yml`,版本 2 允许您直接在 Taskfile 中写入全局变量:
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
vars:
|
||||
GREETING: Hello, World!
|
||||
|
||||
tasks:
|
||||
greet:
|
||||
cmds:
|
||||
- echo "{{.GREETING}}"
|
||||
```
|
||||
|
||||
变量的优先级调整为:
|
||||
|
||||
1. Task 变量
|
||||
2. Call variables
|
||||
3. Taskfile 定义变量
|
||||
4. Taskvars 文件定义变量
|
||||
5. Environment variables
|
||||
|
||||
添加了一个新的全局配置项来配置变量扩展的数量(默认为 2):
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
expansions: 3
|
||||
|
||||
vars:
|
||||
FOO: foo
|
||||
BAR: bar
|
||||
BAZ: baz
|
||||
FOOBAR: '{{.FOO}}{{.BAR}}'
|
||||
FOOBARBAZ: '{{.FOOBAR}}{{.BAZ}}'
|
||||
|
||||
tasks:
|
||||
default:
|
||||
cmds:
|
||||
- echo "{{.FOOBARBAZ}}"
|
||||
```
|
||||
|
||||
## 版本 1
|
||||
|
||||
:::caution
|
||||
|
||||
v1 schema support was removed in Task >= v3.0.0.
|
||||
|
||||
:::
|
||||
|
||||
最初的 `Taskfile` 并不支持 `version:` 关键字,因为 YAML 文档中的根属性都是 task。 就像这样:
|
||||
|
||||
```yaml
|
||||
echo:
|
||||
cmds:
|
||||
- echo "Hello, World!"
|
||||
```
|
||||
|
||||
变量的优先级也不同:
|
||||
|
||||
1. 调用变量
|
||||
2. 环境变量
|
||||
3. Task 变量
|
||||
4. `Taskvars.yml` 定义变量
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
[output]: usage.md#输出语法
|
||||
[ignore_errors]: usage.md#忽略错误
|
||||
[includes]: usage.md#包含其他-taskfile
|
||||
[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
slug: /translate/
|
||||
sidebar_position: 14
|
||||
sidebar_position: 12
|
||||
---
|
||||
|
||||
# 翻译
|
||||
|
@ -1053,6 +1053,60 @@ tasks:
|
||||
- echo "{{.MESSAGE}}"
|
||||
```
|
||||
|
||||
## Warning Prompts
|
||||
|
||||
Warning Prompts to prompt a user for confirmation before a task is executed.
|
||||
|
||||
Below is an example using `prompt` with a dangerous command, that is called between two safe commands:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
tasks:
|
||||
example:
|
||||
cmds:
|
||||
- task: not-dangerous
|
||||
- task: dangerous
|
||||
- task: another-not-dangerous
|
||||
|
||||
not-dangerous:
|
||||
cmds:
|
||||
- echo 'not dangerous command'
|
||||
|
||||
another-not-dangerous:
|
||||
cmds:
|
||||
- echo 'another not dangerous command'
|
||||
|
||||
dangerous:
|
||||
prompt: This is a dangerous command... Do you want to continue?
|
||||
cmds:
|
||||
- echo 'dangerous command'
|
||||
```
|
||||
|
||||
```bash
|
||||
❯ task dangerous
|
||||
task: "This is a dangerous command... Do you want to continue?" [y/N]
|
||||
```
|
||||
|
||||
Warning prompts are called before executing a task. If a prompt is denied Task will exit with [exit code](api_reference.md#exit-codes) 205. If approved, Task will continue as normal.
|
||||
|
||||
```bash
|
||||
❯ task example
|
||||
not dangerous command
|
||||
task: "This is a dangerous command. Do you want to continue?" [y/N]
|
||||
y
|
||||
dangerous command
|
||||
another not dangerous command
|
||||
```
|
||||
|
||||
To skip warning prompts automatically, you can use the `--yes` (alias `-y`) option when calling the task. By including this option, all warnings, will be automatically confirmed, and no prompts will be shown.
|
||||
|
||||
:::caution
|
||||
|
||||
Tasks with prompts always fail by default on non-terminal environments, like a CI, where an `stdin` won't be available for the user to answer. In cases like, use `--yes` (`-y`) to force all tasks with a prompt to run.
|
||||
|
||||
:::
|
||||
|
||||
## 静默模式
|
||||
|
||||
静默模式在 Task 运行命令之前禁用命令回显。 对于以下 Taskfile:
|
||||
|
Loading…
Reference in New Issue
Block a user