rayan/go-task
1
0
Fork 0
mirror of https://github.com/go-task/task.git synced 2026-06-29 15:44:30 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: sync translations (#1206)

Browse Source
This commit is contained in:
task-bot
2023-06-10 21:18:54 -03:00
committed by GitHub
parent 5af361ab1c
commit 127b685104
70 changed files with 2035 additions and 720 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
docs/i18n/ru-RU/docusaurus-plugin-content-docs/current/api_reference.md
View File

@@ -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. |

2
docs/i18n/ru-RU/docusaurus-plugin-content-docs/current/changelog.md
View File

@@ -1,6 +1,6 @@
---
slug: /changelog/
sidebar_position: 8
sidebar_position: 9
---
# Changelog

2
docs/i18n/ru-RU/docusaurus-plugin-content-docs/current/community.md
View File

@@ -1,6 +1,6 @@
---
slug: /community/
sidebar_position: 9
sidebar_position: 10
---
# Сообщество

3
docs/i18n/ru-RU/docusaurus-plugin-content-docs/current/contributing.md
View File

@@ -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. Настройка

2
docs/i18n/ru-RU/docusaurus-plugin-content-docs/current/donate.md
View File

@@ -1,6 +1,6 @@
---
slug: /donate/
sidebar_position: 13
sidebar_position: 15
---
# Поддержать

54
docs/i18n/ru-RU/docusaurus-plugin-content-docs/current/experiments/experiments.md Normal file
View File

@@ -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

50
docs/i18n/ru-RU/docusaurus-plugin-content-docs/current/experiments/workflow.md Normal file
View File

@@ -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

51
docs/i18n/ru-RU/docusaurus-plugin-content-docs/current/faq.md
View File

@@ -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:

2
docs/i18n/ru-RU/docusaurus-plugin-content-docs/current/integrations.md
View File

@@ -1,6 +1,6 @@
---
slug: /integrations/
sidebar_position: 5
sidebar_position: 6
---
# Интеграции

2
docs/i18n/ru-RU/docusaurus-plugin-content-docs/current/releasing.md
View File

@@ -1,6 +1,6 @@
---
slug: /releasing/
sidebar_position: 11
sidebar_position: 13
---
# Релизы

26
docs/i18n/ru-RU/docusaurus-plugin-content-docs/current/styleguide.md
View File

@@ -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
```

314
docs/i18n/ru-RU/docusaurus-plugin-content-docs/current/taskfile_versions.md
View File

@@ -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

2
docs/i18n/ru-RU/docusaurus-plugin-content-docs/current/translate.md
View File

@@ -1,6 +1,6 @@
---
slug: /translate/
sidebar_position: 14
sidebar_position: 12
---
# Перевод

54
docs/i18n/ru-RU/docusaurus-plugin-content-docs/current/usage.md
View File

@@ -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: