Compare commits

...

68 Commits

Author SHA1 Message Date
Andrey Nering
99d247e254 release: v3.30.1 2023-09-14 21:31:13 -03:00
Pete Davison
d1d312f396 refactor: minor improvements to setCurrentDir 2023-09-14 21:28:43 -03:00
Pete Davison
ba299aa71f fix: incorrect remote taskfiles cache directory 2023-09-14 21:28:43 -03:00
Pete Davison
92f30d4d70 chore: changelog 2023-09-14 21:28:43 -03:00
Pete Davison
93cccd4027 fix: only create a cache if the node is remote 2023-09-14 21:28:43 -03:00
Pete Davison
8e7e231aec fix: e.Dir not being set to the correct directory 2023-09-14 21:28:43 -03:00
Andrey Nering
72d77eb6c0 chore(deps): upgrade slim-sprig to v3.0.0 (#1329) 2023-09-14 01:59:35 +00:00
Andrey Nering
42ac242927 release: v3.30.0 2023-09-13 22:04:01 -03:00
Andrey Nering
d0551353f3 chore: add changelog entry for #1325 2023-09-13 21:43:40 -03:00
Reilly Brogan
1417f9f6cd feat(checksum): replace md5 with xxh3 to improve performance (#1325) 2023-09-13 21:26:48 -03:00
dependabot[bot]
978d66e148 chore(deps): bump golang.org/x/term from 0.11.0 to 0.12.0 (#1326) 2023-09-13 21:12:47 -03:00
task-bot
4fd69154a3 chore: sync translations (#1328) 2023-09-13 21:12:26 -03:00
Pete Davison
22ce67c5e5 feat: remote taskfiles (HTTP) (#1152)
* feat: remote taskfiles over http

* feat: allow insecure connections when --insecure flag is provided

* feat: better error handling for fetch errors

* fix: ensure cache directory always exists

* fix: setup logger before everything else

* feat: put remote taskfiles behind an experiment

* feat: --download and --offline flags for remote taskfiles

* feat: node.Read accepts a context

* feat: experiment docs

* chore: changelog

* chore: remove unused optional param from Node interface

* chore: tidy up and generalise NewNode function

* fix: use sha256 in remote checksum

* feat: --download by itself will not run a task

* feat: custom error if remote taskfiles experiment is not enabled

* refactor: BaseNode functional options and simplified FileNode

* fix: use hex encoding for checksum instead of b64
2023-09-12 22:42:54 +01:00
task-bot
84ad0056e4 chore: sync translations (#1323) 2023-09-04 09:46:45 -03:00
Pete Davison
07d5e80c57 fix: minor blog typos 2023-09-03 03:19:11 +00:00
Pete Davison
c6241af64a fix: il8n blog authors 2023-09-02 22:15:58 +00:00
Pete Davison
4f6eea8799 blog: introducing experiments 2023-09-02 21:52:43 +00:00
Pete Davison
a207289955 chore: update experiments and deprecation docs (#1315) 2023-09-02 17:48:05 -03:00
Andrey Nering
3f2abe011b chore: upgrade Go to v1.21.0 on lint and release actions 2023-09-02 17:43:45 -03:00
Pete Davison
afe8a618fe feat: node refactor (#1316)
* refactor: node reader interface

* refactor: rewrite Taskfile() as anon recursive func

* chore: NewNodeFromIncludedTaskfile

* chore: changelog
2023-09-02 21:24:01 +01:00
task-bot
b2e6c93b4b chore: sync translations (#1314) 2023-08-28 21:20:30 -03:00
Andrey Nering
c3d2437c3a chore(changelog): consolidate v3.29.0 and v3.29.1 2023-08-26 19:17:43 -03:00
Andrey Nering
e2552dae45 chore(website): update release docs to include instructions for winget 2023-08-26 19:17:24 -03:00
Andrey Nering
1189bdec87 goreleaser: skip automatic winget release on ci 2023-08-26 19:00:14 -03:00
Andrey Nering
f51f9621d1 fix: goreleaser deprecation on ci 2023-08-26 18:52:10 -03:00
Andrey Nering
19eba3cc14 v3.29.1 2023-08-26 18:45:44 -03:00
Andrey Nering
5b8b58b6d9 v3.29.0 2023-08-26 18:39:18 -03:00
Andrey Nering
d1f643ebd9 fix: --status flag should not have side-effects (#1313)
Closes #1305
Closes #1307

Co-authored-by: Giovanni Visciano <giovanni_visciano@yahoo.it>
2023-08-26 21:30:23 +00:00
Andrey Nering
e96712b020 fix: make sure USER_WORKING_DIR works corrently with includes (#1309)
Closes #1046
Closes #1205
Closes #1250
Closes #1293
Closes #1274
Closes #1309
Closes #1312

Co-authored-by: Marcus Spading <ms@fragmentum.net>
2023-08-26 21:06:50 +00:00
task-bot
6102900060 chore: sync translations (#1308) 2023-08-18 00:06:37 +00:00
Pete Davison
6f986af0d4 feat: bump minimum go version to 1.20 (#1302) 2023-08-11 22:46:37 +01:00
Andrey Nering
dd9b1a1065 chore: fix goreleaser deprecations 2023-08-09 22:50:07 -03:00
Andrey Nering
ae135f5203 chore: release automatically to winget using goreleaser 2023-08-09 22:44:29 -03:00
Calvin McLean
c42bc6914e fix: defer keyword in json schema
Closes #1288
2023-08-09 22:03:17 -03:00
Andrey Nering
0cddd8c167 chore(vscode): add sample settings.json with yaml schema configuration 2023-08-09 21:30:15 -03:00
Andrey Nering
22cd0edfc9 fix: signal and watch tests 2023-08-09 21:12:50 -03:00
Filip Solich
600966ac26 fix: add missing \n to watcher log
Closes #1285
Closes #1297
2023-08-09 21:09:11 -03:00
Andrey Nering
2b21fd2eda chore(website): reactivate carbon 2023-08-09 20:58:59 -03:00
task-bot
90a8c26b25 chore: sync translations (#1291) 2023-08-05 11:33:39 -03:00
dependabot[bot]
7145791f62 chore(deps): bump golang.org/x/term from 0.10.0 to 0.11.0 (#1298) 2023-08-05 11:33:18 -03:00
James Sansbury
d9a4b4241e docs: add required version for supporting loops (#1290) 2023-08-01 11:26:40 -03:00
task-bot
f219e1ee76 chore: sync translations (#1287) 2023-07-30 20:21:40 +00:00
skaluzka
c0d9c81393 docs: fix few typos in the api reference page (#1286) 2023-07-30 17:14:09 -03:00
task-bot
7bcdccc645 chore: sync translations (#1280) 2023-07-26 12:51:01 +00:00
Andrey Nering
44ca1fc77e release: v3.28.0 2023-07-24 22:12:09 -03:00
Andrey Nering
a16a5ea81a docs: small adjustment for #1220 2023-07-24 22:06:40 -03:00
Pete Davison
ca72f3c3a1 feat: added joinPath and relPath functions 2023-07-24 22:05:40 -03:00
Pete Davison
d447cc3f19 chore: make sources paths relative 2023-07-24 22:05:40 -03:00
Pete Davison
6be3ff6141 chore: sources instead of source 2023-07-24 22:05:40 -03:00
Pete Davison
36565bbbd2 fix: silent should be processed via taskCall 2023-07-24 22:05:40 -03:00
Pete Davison
755acd616c docs: for 2023-07-24 22:05:40 -03:00
Pete Davison
7ff1b1795e feat: for 2023-07-24 22:05:40 -03:00
Andrey Nering
7ece04e996 docs: add japanese and turkish translations (#1279) 2023-07-24 21:32:37 -03:00
Andrey Nering
d4d3571c96 changelog: add entry for #1263 2023-07-24 21:26:42 -03:00
Evan
364ddef56b fix: add nil guards in dependency merge (#1263) 2023-07-24 21:22:39 -03:00
Pete Davison
3908c05d14 chore: changelog 2023-07-24 21:13:37 -03:00
Pete Davison
6059ce2ac4 fix: exit codes for indirect tasks 2023-07-24 21:13:37 -03:00
task-bot
659ba317c1 chore: sync translations (#1267) 2023-07-24 20:53:17 -03:00
Andrey Nering
7e7a016df3 chore(docs): update formatting 2023-07-18 11:03:41 -03:00
task-bot
5041c8058d chore: sync translations (#1262) 2023-07-18 10:59:05 -03:00
dependabot[bot]
a66e804904 chore(deps): bump semver from 5.7.1 to 5.7.2 in /docs (#1258) 2023-07-11 11:17:44 -03:00
Andrey Nering
d6d571779d changelog: add entry for #1256 2023-07-08 11:44:57 -03:00
Hudson Clark
8a0689328b fix: propagate include vars in multi-level includes (#1256) 2023-07-08 11:42:38 -03:00
task-bot
2a0c99b5d8 chore: sync translations (#1253) 2023-07-08 11:08:59 -03:00
dependabot[bot]
6e3e95a721 chore(deps): bump golang.org/x/term from 0.9.0 to 0.10.0 (#1257) 2023-07-08 11:00:21 -03:00
Steve Russo
a4d242680b docs: fix two minor typos in usage.md (#1254) 2023-07-06 20:31:26 +00:00
task-bot
ee2e939d13 chore: sync translations (#1248) 2023-07-02 14:42:10 -03:00
Max Winterstein
788a63ca2f docs: add "tea" installation method (#1249) 2023-07-02 14:41:29 -03:00
238 changed files with 14291 additions and 860 deletions

View File

@@ -14,7 +14,7 @@ jobs:
steps:
- uses: actions/setup-go@v3
with:
go-version: 1.20.x
go-version: 1.21.x
- uses: actions/checkout@v3

View File

@@ -15,12 +15,12 @@ jobs:
- name: Set up Go
uses: actions/setup-go@v3
with:
go-version: 1.20.x
go-version: 1.21.x
- name: Run GoReleaser
uses: goreleaser/goreleaser-action@v2
with:
version: latest
args: release --rm-dist
args: release --clean
env:
GITHUB_TOKEN: ${{secrets.GH_PAT}}

View File

@@ -13,7 +13,7 @@ jobs:
name: Test
strategy:
matrix:
go-version: [1.19.x, 1.20.x]
go-version: [1.20.x, 1.21.x]
platform: [ubuntu-latest, macos-latest, windows-latest]
runs-on: ${{matrix.platform}}
steps:

3
.gitignore vendored
View File

@@ -21,7 +21,8 @@ dist/
# editors
.idea/
.vscode/
.vscode/*
!.vscode/*-sample.json
.fleet/
# exuberant ctags

View File

@@ -1,28 +1,28 @@
build:
binary: task
main: ./cmd/task
goos:
- windows
- darwin
- linux
- freebsd
goarch:
- '386'
- amd64
- arm
- arm64
goarm:
- '6'
ignore:
- goos: darwin
goarch: '386'
env:
- CGO_ENABLED=0
mod_timestamp: '{{ .CommitTimestamp }}'
flags:
- -trimpath
ldflags:
- -s -w # Don't set main.version.
builds:
- binary: task
main: ./cmd/task
goos:
- windows
- darwin
- linux
- freebsd
goarch:
- '386'
- amd64
- arm
- arm64
goarm:
- '6'
ignore:
- goos: darwin
goarch: '386'
env:
- CGO_ENABLED=0
mod_timestamp: '{{ .CommitTimestamp }}'
flags:
- -trimpath
ldflags:
- -s -w # Don't set main.version.
gomod:
proxy: true
@@ -72,7 +72,7 @@ brews:
license: MIT
homepage: https://taskfile.dev
folder: Formula
tap:
repository:
owner: go-task
name: homebrew-tap
test:
@@ -85,3 +85,41 @@ brews:
commit_author:
name: task-bot
email: 106601941+task-bot@users.noreply.github.com
winget:
- name: Task
publisher: Task
short_description: A task runner / simpler Make alternative written in Go
description: Task is a task runner / build tool that aims to be simpler and easier to use than, for example, GNU Make.
license: MIT
homepage: https://taskfile.dev/
publisher_url: https://taskfile.dev/
publisher_support_url: https://github.com/go-task/task/issues
package_identifier: Task.Task
commit_author:
name: task-bot
email: 106601941+task-bot@users.noreply.github.com
commit_msg_template: "chore: bump {{.PackageIdentifier}} to {{.Tag}}"
release_notes_url: https://github.com/go-task/task/releases/tag/{{.Tag}}
tags:
- build
- build-tool
- devops
- go
- make
- makefile
- runner
- task
- task-runner
- taskfile
- tool
skip_upload: true
repository:
owner: microsoft
name: winget-pkgs
pull_request:
enabled: true
base:
owner: go-task
name: winget-pkgs
branch: "bump-task-to-{{.Tag}}"

5
.vscode/settings-sample.json vendored Normal file
View File

@@ -0,0 +1,5 @@
{
"yaml.schemas": {
"./docs/static/schema.json": "Taskfile.yml"
}
}

View File

@@ -1,5 +1,46 @@
# Changelog
## v3.30.1 - 2023-09-14
- Fixed a regression where some special variables weren't being set correctly
(#1331, #1334 by @pd93).
## v3.30.0 - 2023-09-13
- Prep work for Remote Taskfiles (#1316 by @pd93).
- Added the
[Remote Taskfiles experiment](https://taskfile.dev/experiments/remote-taskfiles)
as a draft (#1152, #1317 by @pd93).
- Improve performance of content checksuming on `sources:` by replacing md5 with
[XXH3](https://xxhash.com/) which is much faster. This is a soft breaking
change because checksums will be invalidated when upgrading to this release
(#1325 by @ReillyBrogan).
## v3.29.1 - 2023-08-26
- Update to Go 1.21 (bump minimum version to 1.20) (#1302 by @pd93)
- Fix a missing a line break on log when using `--watch` mode (#1285, #1297 by
@FilipSolich).
- Fix `defer` on JSON Schema (#1288 by @calvinmclean and @andreynering).
- Fix bug in usage of special variables like `{{.USER_WORKING_DIR}}` in
combination with `includes` (#1046, #1205, #1250, #1293, #1312, #1274 by
@andarto, #1309 by @andreynering).
- Fix bug on `--status` flag. Running this flag should not have side-effects: it
should not update the checksum on `.task`, only report its status (#1305,
#1307 by @visciang, #1313 by @andreynering).
## v3.28.0 - 2023-07-24
- Added the ability to
[loop over commands and tasks](https://taskfile.dev/usage/#looping-over-values)
using `for` (#82, #1220 by @pd93).
- Fixed variable propagation in multi-level includes (#778, #996, #1256 by
@hudclark).
- Fixed a bug where the `--exit-code` code flag was not returning the correct
exit code when calling commands indirectly (#1266, #1270 by @pd93).
- Fixed a `nil` panic when a dependency was commented out or left empty (#1263
by @neomantra).
## v3.27.1 - 2023-06-30
- Fix panic when a `.env` directory (not file) is present on current directory
@@ -13,7 +54,8 @@
- Bug fixes were made to the
[npm installation method](https://taskfile.dev/installation/#npm). (#1190, by
@sounisi5011).
- Added the [gentle force experiment](https://taskfile.dev/experiments) as a
- Added the
[gentle force experiment](https://taskfile.dev/experiments/gentle-force) as a
draft (#1200, #1216 by @pd93).
- Added an `--experiments` flag to allow you to see which experiments are
enabled (#1242 by @pd93).

View File

@@ -116,7 +116,7 @@ tasks:
test-release:
desc: Tests release process without publishing
cmds:
- goreleaser --snapshot --rm-dist
- goreleaser --snapshot --clean
release:
desc: Prepare the project for a new release

View File

@@ -8,7 +8,7 @@ import (
// ParseV3 parses command line argument: tasks and global variables
func ParseV3(args ...string) ([]taskfile.Call, *taskfile.Vars) {
var calls []taskfile.Call
calls := []taskfile.Call{}
globals := &taskfile.Vars{}
for _, arg := range args {
@@ -21,16 +21,12 @@ func ParseV3(args ...string) ([]taskfile.Call, *taskfile.Vars) {
globals.Set(name, taskfile.Var{Static: value})
}
if len(calls) == 0 {
calls = append(calls, taskfile.Call{Task: "default", Direct: true})
}
return calls, globals
}
// ParseV2 parses command line argument: tasks and vars of each task
func ParseV2(args ...string) ([]taskfile.Call, *taskfile.Vars) {
var calls []taskfile.Call
calls := []taskfile.Call{}
globals := &taskfile.Vars{}
for _, arg := range args {
@@ -51,10 +47,6 @@ func ParseV2(args ...string) ([]taskfile.Call, *taskfile.Vars) {
}
}
if len(calls) == 0 {
calls = append(calls, taskfile.Call{Task: "default", Direct: true})
}
return calls, globals
}

View File

@@ -73,22 +73,16 @@ func TestArgsV3(t *testing.T) {
},
},
{
Args: nil,
ExpectedCalls: []taskfile.Call{
{Task: "default", Direct: true},
},
Args: nil,
ExpectedCalls: []taskfile.Call{},
},
{
Args: []string{},
ExpectedCalls: []taskfile.Call{
{Task: "default", Direct: true},
},
Args: []string{},
ExpectedCalls: []taskfile.Call{},
},
{
Args: []string{"FOO=bar", "BAR=baz"},
ExpectedCalls: []taskfile.Call{
{Task: "default", Direct: true},
},
Args: []string{"FOO=bar", "BAR=baz"},
ExpectedCalls: []taskfile.Call{},
ExpectedGlobals: &taskfile.Vars{
OrderedMap: orderedmap.FromMapWithOrder(
map[string]taskfile.Var{
@@ -191,22 +185,16 @@ func TestArgsV2(t *testing.T) {
},
},
{
Args: nil,
ExpectedCalls: []taskfile.Call{
{Task: "default", Direct: true},
},
Args: nil,
ExpectedCalls: []taskfile.Call{},
},
{
Args: []string{},
ExpectedCalls: []taskfile.Call{
{Task: "default", Direct: true},
},
Args: []string{},
ExpectedCalls: []taskfile.Call{},
},
{
Args: []string{"FOO=bar", "BAR=baz"},
ExpectedCalls: []taskfile.Call{
{Task: "default", Direct: true},
},
Args: []string{"FOO=bar", "BAR=baz"},
ExpectedCalls: []taskfile.Call{},
ExpectedGlobals: &taskfile.Vars{
OrderedMap: orderedmap.FromMapWithOrder(
map[string]taskfile.Var{

View File

@@ -19,7 +19,7 @@ const (
const changelogTemplate = `---
slug: /changelog/
sidebar_position: 9
sidebar_position: 14
---`
var (

View File

@@ -53,6 +53,7 @@ var flags struct {
listJson bool
taskSort string
status bool
insecure bool
force bool
forceAll bool
watch bool
@@ -71,6 +72,8 @@ var flags struct {
interval time.Duration
global bool
experiments bool
download bool
offline bool
}
func main() {
@@ -112,6 +115,7 @@ func run() error {
pflag.BoolVarP(&flags.listJson, "json", "j", false, "Formats task list as JSON.")
pflag.StringVar(&flags.taskSort, "sort", "", "Changes the order of the tasks when listed. [default|alphanumeric|none].")
pflag.BoolVar(&flags.status, "status", false, "Exits with non-zero exit code if any of the given tasks is not up-to-date.")
pflag.BoolVar(&flags.insecure, "insecure", false, "Forces Task to download Taskfiles over insecure connections.")
pflag.BoolVarP(&flags.watch, "watch", "w", false, "Enables watch of the given task.")
pflag.BoolVarP(&flags.verbose, "verbose", "v", false, "Enables verbose mode.")
pflag.BoolVarP(&flags.silent, "silent", "s", false, "Disables echoing.")
@@ -140,6 +144,12 @@ func run() error {
pflag.BoolVarP(&flags.forceAll, "force", "f", false, "Forces execution even when the task is up-to-date.")
}
// Remote Taskfiles experiment will adds the "download" and "offline" flags
if experiments.RemoteTaskfiles {
pflag.BoolVar(&flags.download, "download", false, "Downloads a cached version of a remote Taskfile.")
pflag.BoolVar(&flags.offline, "offline", false, "Forces Task to only use local or cached Taskfiles.")
}
pflag.Parse()
if flags.version {
@@ -173,6 +183,10 @@ func run() error {
return nil
}
if flags.download && flags.offline {
return errors.New("task: You can't set both --download and --offline flags")
}
if flags.global && flags.dir != "" {
log.Fatal("task: You can't set both --global and --dir")
return nil
@@ -216,12 +230,15 @@ func run() error {
e := task.Executor{
Force: flags.force,
ForceAll: flags.forceAll,
Insecure: flags.insecure,
Download: flags.download,
Offline: flags.offline,
Watch: flags.watch,
Verbose: flags.verbose,
Silent: flags.silent,
AssumeYes: flags.assumeYes,
Dir: flags.dir,
Dry: flags.dry,
Dry: flags.dry || flags.status,
Entrypoint: flags.entrypoint,
Summary: flags.summary,
Parallel: flags.parallel,
@@ -278,6 +295,13 @@ func run() error {
calls, globals = args.ParseV2(tasksAndVars...)
}
// If there are no calls, run the default task instead
// Unless the download flag is specified, in which case we want to download
// the Taskfile and do nothing else
if len(calls) == 0 && !flags.download {
calls = append(calls, taskfile.Call{Task: "default", Direct: true})
}
globals.Set("CLI_ARGS", taskfile.Var{Static: cliArgs})
e.Taskfile.Vars.Merge(globals)

View File

@@ -0,0 +1,142 @@
---
title: Introducing Experiments
description:
A look at where task is, where it's going and how we're going to get there.
slug: task-in-2023
authors: [pd93]
tags: [experiments, breaking-changes, roadmap, v4]
image: https://i.imgur.com/mErPwqL.png
hide_table_of_contents: false
---
Lately, Task has been growing extremely quickly and I've found myself thinking a
lot about the future of the project and how we continue to evolve and grow. I'm
not much of a writer, but I think one of the things we could do better is to
communicate these kinds of thoughts to the community. So, with that in mind,
this is the first (hopefully of many) blog posts talking about Task and what
we're up to.
<!--truncate-->
## :calendar: So, what have we been up to?
Over the past 12 months or so, [@andreynering] (Author and maintainer of the
project) and I ([@pd93]) have been working in our spare time to maintain and
improve v3 of Task and we've made some amazing progress. Here are just some of
the things we've released in that time:
- An official [extension for VS Code][vscode-task].
- Internal Tasks ([#818](https://github.com/go-task/task/pull/818)).
- Task aliases ([#879](https://github.com/go-task/task/pull/879)).
- Looping over tasks ([#1220](https://github.com/go-task/task/pull/1200)).
- A series of refactors to the core codebase to make it more maintainable and
extensible.
- Loads of bug fixes and improvements.
- An integration with [Crowdin][crowdin]. Work is in progress on making our docs
available in **7 new languages** (Special thanks to all our translators for
the huge help with this!).
- And much, much more! :sparkles:
We're also working on adding some really exciting and highly requested features
to Task such as having the ability to run remote Taskfiles
([#1317](https://github.com/go-task/task/issues/1317)).
None of this would have been possible without the [150 or so (and growing)
contributors][contributors] to the project, numerous sponsors and a passionate
community of users. Together we have more than doubled the number of GitHub
stars to over 8400 :star: since the beginning of 2022 and this continues to
accelerate. We can't thank you all enough for your help and support! :rocket:
[![Star History Chart](https://api.star-history.com/svg?repos=go-task/task&type=Date)](https://star-history.com/#go-task/task&Date)
## What's next? :thinking_face:
It's extremely motivating to see so many people using and loving Task. However,
in this time we've also seen an increase in the number of issues and feature
requests. In particular, issues that require some kind of breaking change to
Task. This isn't a bad thing, but as we grow we need to be more responsible
about how we address these changes in a way that ensures stability and
compatibility for existing users and their Taskfiles.
At this point you're probably thinking something like:
> "But you use [semantic versioning][semver] - Just release a new major version
> with your breaking changes."
And you'd be right... sort of. In theory, this sounds great, but the reality is
that we don't have the time to commit to a major overhaul of Task in one big
bang release. This would require a colossal amount of time and coordination and
with full time jobs and personal lives to tend to, this is a difficult
commitment to make. Smaller, more frequent major releases are also a significant
inconvenience for users as they have to constantly keep up-to-date with our
breaking changes. Fortunately, there is a better way.
## What's going to change? :face_with_monocle:
Going forwards, breaking changes will be allowed into _minor_ versions of Task
as "experimental features". To access these features users will need opt-in by
enabling feature flags. This will allow us to release new features slowly and
gather feedback from the community before making them the default behavior in a
future major release.
To prepare users for the next major release, we will maintain a list of
[deprecated features][deprecations] and [experiments][experiments] on our docs
website and publish information on how to migrate to the new behavior.
You can read the [full breaking change proposal][breaking-change-proposal] and
view all the [current experiments and their status][experiments-project] on
GitHub including the [Gentle Force][gentle-force-experiment] and [Remote
Taskfiles][remote-taskfiles-experiment] experiments.
## What will happen to v2/v3 features?
v2 has been [officially deprecated][deprecate-version-2-schema]. If you're still
using a Taskfile with `version: "2"` at the top we _strongly recommend_ that you
upgrade as soon as possible. Removing v2 will allow us to tidy up the codebase
and focus on new functionality instead.
When v4 is released, we will continue to support v3 for a period of time (bug
fixes etc). However, since we are moving from a backward-compatibility model to
a forwards-compatibility model, **v4 itself will not be backwards compatible
with v3**.
## v4 When? :eyes:
:shrug: When it's ready.
In all seriousness, we don't have a timeline for this yet. We'll be working on
the most serious deficiencies of the v3 API first and regularly evaluating the
state of the project. When we feel its in a good, stable place and we have a
clear upgrade path for users and a number of stable experiments, we'll start to
think about v4.
## :wave: Final thoughts
Task is growing fast and we're excited to see where it goes next. We hope that
the steps we're taking to improve the project and our process will help us to
continue to grow. As always, if you have any questions or feedback, we encourage
you to comment on or open [issues][issues] and [discussions][discussions] on
GitHub. Alternatively, you can join us on [Discord][discord].
I plan to write more of these blog posts in the future on a variety of
Task-related topics, so make sure to check in occasionally and see what we're up
to!
<!-- prettier-ignore-start -->
[vscode-task]: https://github.com/go-task/vscode-task
[crowdin]: https://crowdin.com
[contributors]: https://github.com/go-task/task/graphs/contributors
[semver]: https://semver.org
[breaking-change-proposal]: https://github.com/go-task/task/discussions/1191
[@andreynering]: https://github.com/andreynering
[@pd93]: https://github.com/pd93
[experiments]: https://taskfile.dev/experiments
[deprecations]: https://taskfile.dev/deprecations
[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
[issues]: https://github.com/go-task/task/issues
[discussions]: https://github.com/go-task/task/discussions
[discord]: https://discord.gg/6TY36E39UK
[experiments-project]: https://github.com/orgs/go-task/projects/1
[gentle-force-experiment]: https://github.com/go-task/task/issues/1200
[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317
<!-- prettier-ignore-end -->

View File

@@ -3,3 +3,8 @@ andreynering:
title: Maintainer of Task
url: https://github.com/andreynering
image_url: https://github.com/andreynering.png
pd93:
name: Pete Davison
title: Maintainer of Task
url: https://github.com/pd93
image_url: https://github.com/pd93.png

View File

@@ -17,7 +17,7 @@ task [--flags] [tasks...] [-- CLI_ARGS...]
:::tip
If `--` is given, all remaning arguments will be assigned to a special
If `--` is given, all remaining arguments will be assigned to a special
`CLI_ARGS` variable
:::
@@ -126,12 +126,13 @@ There are some special variables that is available on the templating system:
| `TASKFILE_DIR` | The absolute path of the included Taskfile. |
| `USER_WORKING_DIR` | The absolute path of the directory `task` was called from. |
| `CHECKSUM` | The checksum of the files listed in `sources`. Only available within the `status` prop and if method is set to `checksum`. |
| `TIMESTAMP` | The date object of the greatest timestamp of the files listes in `sources`. Only available within the `status` prop and if method is set to `timestamp`. |
| `TIMESTAMP` | The date object of the greatest timestamp of the files listed in `sources`. Only available within the `status` prop and if method is set to `timestamp`. |
| `TASK_VERSION` | The current version of task. |
| `ITEM` | The value of the current iteration when using the `for` property. Can be changed to a different variable name using `as:`. |
## ENV
Some environment variables can be overriden to adjust Task behavior.
Some environment variables can be overridden to adjust Task behavior.
| ENV | Default | Description |
| -------------------- | ------- | ----------------------------------------------------------------------------------------------------------------- |
@@ -151,12 +152,12 @@ Some environment variables can be overriden to adjust Task behavior.
| ---------- | ---------------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `version` | `string` | | Version of the Taskfile. The current version is `3`. |
| `output` | `string` | `interleaved` | Output mode. Available options: `interleaved`, `group` and `prefixed`. |
| `method` | `string` | `checksum` | Default method in this Taskfile. Can be overriden in a task by task basis. Available options: `checksum`, `timestamp` and `none`. |
| `method` | `string` | `checksum` | Default method in this Taskfile. Can be overridden in a task by task basis. Available options: `checksum`, `timestamp` and `none`. |
| `includes` | [`map[string]Include`](#include) | | Additional Taskfiles to be included. |
| `vars` | [`map[string]Variable`](#variable) | | A set of global variables. |
| `env` | [`map[string]Variable`](#variable) | | A set of global environment variables. |
| `tasks` | [`map[string]Task`](#task) | | A set of task definitions. |
| `silent` | `bool` | `false` | Default 'silent' options for this Taskfile. If `false`, can be overidden with `true` in a task by task basis. |
| `silent` | `bool` | `false` | Default 'silent' options for this Taskfile. If `false`, can be overridden with `true` in a task by task basis. |
| `dotenv` | `[]string` | | A list of `.env` file paths to be parsed. |
| `run` | `string` | `always` | Default 'run' option for this Taskfile. Available options: `always`, `once` and `when_changed`. |
| `interval` | `string` | `5s` | Sets a different watch interval when using `--watch`, the default being 5 seconds. This string should be a valid [Go Duration](https://pkg.go.dev/time#ParseDuration). |
@@ -262,8 +263,9 @@ tasks:
| Attribute | Type | Default | Description |
| -------------- | ---------------------------------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `cmd` | `string` | | The shell command to be executed. |
| `silent` | `bool` | `false` | Skips some output for this command. Note that STDOUT and STDERR of the commands will still be redirected. |
| `task` | `string` | | Set this to trigger execution of another task instead of running a command. This cannot be set together with `cmd`. |
| `for` | [`For`](#for) | | Runs the command once for each given value. |
| `silent` | `bool` | `false` | Skips some output for this command. Note that STDOUT and STDERR of the commands will still be redirected. |
| `vars` | [`map[string]Variable`](#variable) | | Optional additional variables to be passed to the referenced task. Only relevant when setting `task` instead of `cmd`. |
| `ignore_error` | `bool` | `false` | Continue execution if errors happen while executing the command. |
| `defer` | `string` | | Alternative to `cmd`, but schedules the command to be executed at the end of this task instead of immediately. This cannot be used together with `cmd`. |
@@ -306,6 +308,26 @@ tasks:
:::
#### For
The `for` parameter can be defined as a string, a list of strings or a map. If
it is defined as a string, you can give it any of the following values:
- `source` - Will run the command for each source file defined on the task.
(Glob patterns will be resolved, so `*.go` will run for every Go file that
matches).
If it is defined as a list of strings, the command will be run for each value.
Finally, the `for` parameter can be defined as a map when you want to use a
variable to define the values to loop over:
| Attribute | Type | Default | Description |
| --------- | -------- | ---------------- | -------------------------------------------- |
| `var` | `string` | | The name of the variable to use as an input. |
| `split` | `string` | (any whitespace) | What string the variable should be split on. |
| `as` | `string` | `ITEM` | The name of the iterator variable. |
#### Precondition
| Attribute | Type | Default | Description |

View File

@@ -1,10 +1,51 @@
---
slug: /changelog/
sidebar_position: 9
sidebar_position: 14
---
# Changelog
## v3.30.1 - 2023-09-14
- Fixed a regression where some special variables weren't being set correctly
([#1331](https://github.com/go-task/task/issues/1331), [#1334](https://github.com/go-task/task/issues/1334) by [@pd93](https://github.com/pd93)).
## v3.30.0 - 2023-09-13
- Prep work for Remote Taskfiles ([#1316](https://github.com/go-task/task/issues/1316) by [@pd93](https://github.com/pd93)).
- Added the
[Remote Taskfiles experiment](https://taskfile.dev/experiments/remote-taskfiles)
as a draft ([#1152](https://github.com/go-task/task/issues/1152), [#1317](https://github.com/go-task/task/issues/1317) by [@pd93](https://github.com/pd93)).
- Improve performance of content checksuming on `sources:` by replacing md5 with
[XXH3](https://xxhash.com/) which is much faster. This is a soft breaking
change because checksums will be invalidated when upgrading to this release
([#1325](https://github.com/go-task/task/issues/1325) by [@ReillyBrogan](https://github.com/ReillyBrogan)).
## v3.29.1 - 2023-08-26
- Update to Go 1.21 (bump minimum version to 1.20) ([#1302](https://github.com/go-task/task/issues/1302) by [@pd93](https://github.com/pd93))
- Fix a missing a line break on log when using `--watch` mode ([#1285](https://github.com/go-task/task/issues/1285), [#1297](https://github.com/go-task/task/issues/1297) by
[@FilipSolich](https://github.com/FilipSolich)).
- Fix `defer` on JSON Schema ([#1288](https://github.com/go-task/task/issues/1288) by [@calvinmclean](https://github.com/calvinmclean) and [@andreynering](https://github.com/andreynering)).
- Fix bug in usage of special variables like `{{.USER_WORKING_DIR}}` in
combination with `includes` ([#1046](https://github.com/go-task/task/issues/1046), [#1205](https://github.com/go-task/task/issues/1205), [#1250](https://github.com/go-task/task/issues/1250), [#1293](https://github.com/go-task/task/issues/1293), [#1312](https://github.com/go-task/task/issues/1312), [#1274](https://github.com/go-task/task/issues/1274) by
[@andarto](https://github.com/andarto), [#1309](https://github.com/go-task/task/issues/1309) by [@andreynering](https://github.com/andreynering)).
- Fix bug on `--status` flag. Running this flag should not have side-effects: it
should not update the checksum on `.task`, only report its status ([#1305](https://github.com/go-task/task/issues/1305),
[#1307](https://github.com/go-task/task/issues/1307) by [@visciang](https://github.com/visciang), [#1313](https://github.com/go-task/task/issues/1313) by [@andreynering](https://github.com/andreynering)).
## v3.28.0 - 2023-07-24
- Added the ability to
[loop over commands and tasks](https://taskfile.dev/usage/#looping-over-values)
using `for` ([#82](https://github.com/go-task/task/issues/82), [#1220](https://github.com/go-task/task/issues/1220) by [@pd93](https://github.com/pd93)).
- Fixed variable propagation in multi-level includes ([#778](https://github.com/go-task/task/issues/778), [#996](https://github.com/go-task/task/issues/996), [#1256](https://github.com/go-task/task/issues/1256) by
[@hudclark](https://github.com/hudclark)).
- Fixed a bug where the `--exit-code` code flag was not returning the correct
exit code when calling commands indirectly ([#1266](https://github.com/go-task/task/issues/1266), [#1270](https://github.com/go-task/task/issues/1270) by [@pd93](https://github.com/pd93)).
- Fixed a `nil` panic when a dependency was commented out or left empty ([#1263](https://github.com/go-task/task/issues/1263)
by [@neomantra](https://github.com/neomantra)).
## v3.27.1 - 2023-06-30
- Fix panic when a `.env` directory (not file) is present on current directory
@@ -18,7 +59,8 @@ sidebar_position: 9
- Bug fixes were made to the
[npm installation method](https://taskfile.dev/installation/#npm). ([#1190](https://github.com/go-task/task/issues/1190), by
[@sounisi5011](https://github.com/sounisi5011)).
- Added the [gentle force experiment](https://taskfile.dev/experiments) as a
- Added the
[gentle force experiment](https://taskfile.dev/experiments/gentle-force) as a
draft ([#1200](https://github.com/go-task/task/issues/1200), [#1216](https://github.com/go-task/task/issues/1216) by [@pd93](https://github.com/pd93)).
- Added an `--experiments` flag to allow you to see which experiments are
enabled ([#1242](https://github.com/go-task/task/issues/1242) by [@pd93](https://github.com/pd93)).

View File

@@ -1,6 +1,6 @@
---
slug: /community/
sidebar_position: 10
sidebar_position: 9
---
# Community
@@ -11,7 +11,8 @@ thankful for everyone that helps me to improve the overall experience.
## Translations
We use [Crowdin](https://crowdin.com/project/taskfile) to translate our document.
We use [Crowdin](https://crowdin.com/project/taskfile) to translate our
document.
## Integrations

View File

@@ -0,0 +1,19 @@
---
slug: /deprecations/
sidebar_position: 7
---
# Deprecations
As Task evolves, it occasionally outgrows some of its functionality. This can be
because they are no longer useful, because another feature has replaced it or
because of a change in the way that Task works internally.
When this happens, we mark the functionality as deprecated. This means that it
will be removed in a future version of Task. This functionality will continue to
work until that time, but we strongly recommend that you do not implement this
functionality in new Taskfiles and make a plan to migrate away from it as soon
as possible.
You can view a full list of active deprecations in the "Deprecations" section of
the sidebar.

View File

@@ -0,0 +1,18 @@
---
# This is a template for an experiments documentation
# Copy this page and fill in the details as necessary
title: '--- Template ---'
sidebar_position: -1 # Always push to the top
draft: true # Hide in production
---
# {Name of Deprecated Feature}
- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
- Breaks:
- {list any existing functionality that will be broken by this experiment}
{Short description of the feature/behavior and why it is being deprecated}
{Short explanation of any replacement features/behaviors and how users should
migrate to it}

View File

@@ -0,0 +1,27 @@
---
slug: /deprecations/version-2-schema/
---
# Version 2 Schema
- Issue: [#1197][deprecate-version-2-schema]
- Breaks:
- Any Taskfiles that use the version 2 schema
- `Taskvar.yml` files
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 -->
[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
<!-- prettier-ignore-end -->

View File

@@ -1,6 +1,6 @@
---
slug: /donate/
sidebar_position: 15
sidebar_position: 16
---
# Donate

View File

@@ -1,6 +1,6 @@
---
slug: /experiments/
sidebar_position: 5
sidebar_position: 6
---
# Experiments
@@ -16,8 +16,11 @@ 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.
the current set of experimental features and their status in the
[workflow](#workflow).
You can view a full list of active experiments in the "Experiments" section of
the sidebar.
You can enable an experimental feature by:
@@ -42,59 +45,83 @@ 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...
## Workflow
### ![experiment] {Feature} ([#{issue}](https://github.com/go-task/task/issues/{issue})), ...)
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.
- Environment variable: `TASK_X_{feature}`
- Deprecates: {list any existing functionality that will be deprecated by this experiment}
- Breaks: {list any existing functionality that will be broken by this experiment}
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.
{Short description of the feature}
### 1. Proposal
{Short explanation of how users should migrate to the new behavior}
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
### ![deprecated] Version 2 Schema ([#1197][deprecate-version-2-schema])
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.
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.
:::note
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.
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_.
A list of changes between version 2 and version 3 are available in the [Task v3
Release Notes][version-3-release-notes].
:::
### ![experiment] Gentle Force ([#1200](https://github.com/go-task/task/issues/1200))
### 3. Candidate
- Environment variable: `TASK_X_FORCE=1`
- Breaks: `--force` flag
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.
The `--force` flag currently forces _all_ tasks to run regardless of the status
checks. This can be useful, but we have found that most of the time users only
expect the direct task they are calling to be forced and _not_ all of its
dependant tasks.
### 4. Stable
This experiment changes the `--force` flag to only force the directly called
task. All dependant tasks will have their statuses checked as normal and will
only run if Task considers them to be out of date. A new `--force-all` flag will
also be added to maintain the current behavior for users that need this
functionality.
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.
If you want to migrate, but continue to force all dependant tasks to run, you
should replace all uses of the `--force` flag with `--force-all`. Alternatively,
if you want to adopt the new behavior, you can continue to use the `--force`
flag as you do now!
### 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 -->
[breaking-change-proposal]: https://github.com/go-task/task/discussions/1191
[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
[experiment]: https://img.shields.io/badge/experiment-yellow
[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
<!-- prettier-ignore-end -->

View File

@@ -0,0 +1,30 @@
---
slug: /experiments/gentle-force/
---
# Gentle Force
- Issue: [#1200][gentle-force-experiment]
- Environment variable: `TASK_X_FORCE=1`
- Breaks:
- `--force` flag
The `--force` flag currently forces _all_ tasks to run regardless of the status
checks. This can be useful, but we have found that most of the time users only
expect the direct task they are calling to be forced and _not_ all of its
dependant tasks.
This experiment changes the `--force` flag to only force the directly called
task. All dependant tasks will have their statuses checked as normal and will
only run if Task considers them to be out of date. A new `--force-all` flag will
also be added to maintain the current behavior for users that need this
functionality.
If you want to migrate, but continue to force all dependant tasks to run, you
should replace all uses of the `--force` flag with `--force-all`. Alternatively,
if you want to adopt the new behavior, you can continue to use the `--force`
flag as you do now!
<!-- prettier-ignore-start -->
[gentle-force-experiment]: https://github.com/go-task/task/issues/1200
<!-- prettier-ignore-end -->

View File

@@ -0,0 +1,81 @@
---
slug: /experiments/remote-taskfiles/
---
# Remote Taskfiles
- Issue: [#1317][remote-taskfiles-experiment]
- Environment variable: `TASK_X_REMOTE_TASKFILES=1`
This experiment allows you to specify a remote Taskfile URL when including a
Taskfile. For example:
```yaml
version: '3'
include:
my-remote-namespace: https://raw.githubusercontent.com/my-org/my-repo/main/Taskfile.yml
```
This works exactly the same way that including a local file does. Any tasks in
the remote Taskfile will be available to run from your main Taskfile via the
namespace `my-remote-namespace`. For example, if the remote file contains the
following:
```yaml
version: '3'
tasks:
hello:
silent: true
cmds:
- echo "Hello from the remote Taskfile!"
```
and you run `task my-remote-namespace:hello`, it will print the text: "Hello
from the remote Taskfile!" to your console.
## Security
Running commands from sources that you do not control is always a potential
security risk. For this reason, we have added some checks when using remote
Taskfiles:
1. When running a task from a remote Taskfile for the first time, Task will
print a warning to the console asking you to check that you are sure that you
trust the source of the Taskfile. If you do not accept the prompt, then Task
will exit with code `104` (not trusted) and nothing will run. If you accept
the prompt, the remote Taskfile will run and further calls to the remote
Taskfile will not prompt you again.
2. Whenever you run a remote Taskfile, Task will create and store a checksum of
the file that you are running. If the checksum changes, then Task will print
another warning to the console to inform you that the contents of the remote
file has changed. If you do not accept the prompt, then Task will exit with
code `104` (not trusted) and nothing will run. If you accept the prompt, the
checksum will be updated and the remote Taskfile will run.
Task currently supports both `http` and `https` URLs. However, the `http`
requests will not execute by default unless you run the task with the
`--insecure` flag. This is to protect you from accidentally running a remote
Taskfile that is hosted on and unencrypted connection. Sources that are not
protected by TLS are vulnerable to [man-in-the-middle
attacks][man-in-the-middle-attacks] and should be avoided unless you know what
you are doing.
## Caching & Running Offline
If for whatever reason, you don't have access to the internet, but you still
need to be able to run your tasks, you are able to use the `--download` flag to
store a cached copy of the remote Taskfile.
<!-- TODO: The following behavior may change -->
If Task detects that you have a local copy of the remote Taskfile, it will use
your local copy instead of downloading the remote file. You can force Task to
work offline by using the `--offline` flag. This will prevent Task from making
any calls to remote sources.
<!-- prettier-ignore-start -->
[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317
[man-in-the-middle-attacks]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack
<!-- prettier-ignore-end -->

View File

@@ -0,0 +1,20 @@
---
# This is a template for an experiments documentation
# Copy this page and fill in the details as necessary
title: '--- Template ---'
sidebar_position: -1 # Always push to the top
draft: true # Hide in production
---
# {Name of Experiment}
- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
- Environment variable: `TASK_X_{feature}`
- Breaks:
- {list any existing functionality that will be broken by this experiment}
- Deprecations:
- {link to any deprecation pages related to this experiment}
{Short description of the feature}
{Short explanation of how users should migrate to the new behavior}

View File

@@ -1,84 +0,0 @@
---
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 -->
[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
<!-- prettier-ignore-end -->

View File

@@ -1,6 +1,6 @@
---
slug: /faq/
sidebar_position: 7
sidebar_position: 15
---
# FAQ

View File

@@ -29,6 +29,23 @@ so you also have that option if you prefer:
brew install go-task
```
### Tea
If you're on macOS or Linux and have [tea][tea] installed, getting
Task is as simple as running:
```bash
tea task
```
or, if you have teas magic enabled:
```bash
task
```
This installation method is community owned. After a new release of Task, they
are automatically released by tea in a minimum of time.
### Snap
Task is available in [Snapcraft][snapcraft], but keep in mind that your Linux
@@ -281,4 +298,5 @@ Invoke-Expression -Command path/to/task.ps1
[godownloader]: https://github.com/goreleaser/godownloader
[choco]: https://chocolatey.org/
[scoop]: https://scoop.sh/
[tea]: https://tea.xyz/
<!-- prettier-ignore-end -->

View File

@@ -1,6 +1,6 @@
---
slug: /integrations/
sidebar_position: 6
sidebar_position: 8
---
# Integrations

View File

@@ -37,6 +37,15 @@ version:
- Moving both `amd64`, `armhf` and `arm64` new artifacts to the stable channel
on the [Snapcraft dashboard][snapcraftdashboard].
# winget
winget also requires manual steps to be completed. By running
`task test-release` locally, manifest files will be generated on
`dist/winget/manifests/t/Task/Task/v{version}`.
[Upload the manifest directory into this fork](https://github.com/go-task/winget-pkgs/tree/master/manifests/t/Task/Task)
and open a pull request into
[this repository](https://github.com/microsoft/winget-pkgs).
# Scoop
Scoop is a command-line package manager for the Windows operating system. Scoop

View File

@@ -1,6 +1,6 @@
---
slug: /styleguide/
sidebar_position: 8
sidebar_position: 10
---
# Styleguide

View File

@@ -1,6 +1,6 @@
---
slug: /taskfile-versions/
sidebar_position: 14
sidebar_position: 5
---
# Taskfile Versions
@@ -29,7 +29,7 @@ These are some major changes done on `v3`:
- 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
`TIMESTAMP` which contains, respectively, the XXH3 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

View File

@@ -883,17 +883,16 @@ you can use `requires`. This is useful when might not be clear to users which
variables are needed, or if you want clear message about what is required. Also
some tasks could have dangerous side effects if run with un-set variables.
Using `requires` you specify an array of strings in the `vars` sub-section
under `requires`, these strings are variable names which are checked prior to
running the task. If any variables are un-set the the task will error and not
run.
Using `requires` you specify an array of strings in the `vars` sub-section under
`requires`, these strings are variable names which are checked prior to running
the task. If any variables are un-set the the task will error and not run.
Environmental variables are also checked.
Syntax:
```yaml
requires:
requires:
vars: [] # Array of strings
```
@@ -914,7 +913,7 @@ tasks:
- 'docker build . -t {{.IMAGE_NAME}}:{{.IMAGE_TAG}}'
# Make sure these variables are set before running
requires:
requires:
vars: [IMAGE_NAME, IMAGE_TAG]
```
@@ -1000,6 +999,177 @@ tasks:
This works for all types of variables.
## Looping over values
As of v3.28.0, Task allows you to loop over certain values and execute a
command for each. There are a number of ways to do this depending on the type
of value you want to loop over.
### Looping over a static list
The simplest kind of loop is an explicit one. This is useful when you want to
loop over a set of values that are known ahead of time.
```yaml
version: '3'
tasks:
default:
cmds:
- for: ['foo.txt', 'bar.txt']
cmd: cat {{ .ITEM }}
```
### Looping over your task's sources
You are also able to loop over the sources of your task:
```yaml
version: '3'
tasks:
default:
sources:
- foo.txt
- bar.txt
cmds:
- for: sources
cmd: cat {{ .ITEM }}
```
This will also work if you use globbing syntax in your sources. For example, if
you specify a source for `*.txt`, the loop will iterate over all files that
match that glob.
Source paths will always be returned as paths relative to the task directory. If
you need to convert this to an absolute path, you can use the built-in
`joinPath` function.
There are some [special variables](/api/#special-variables) that you may find
useful for this.
```yaml
version: '3'
tasks:
default:
vars:
MY_DIR: /path/to/dir
dir: '{{.MY_DIR}}'
sources:
- foo.txt
- bar.txt
cmds:
- for: sources
cmd: cat {{joinPath .MY_DIR .ITEM}}
```
### Looping over variables
To loop over the contents of a variable, you simply need to specify the variable
you want to loop over. By default, variables will be split on any whitespace
characters.
```yaml
version: '3'
tasks:
default:
vars:
MY_VAR: foo.txt bar.txt
cmds:
- for: { var: MY_VAR }
cmd: cat {{.ITEM}}
```
If you need to split on a different character, you can do this by specifying the
`split` property:
```yaml
version: '3'
tasks:
default:
vars:
MY_VAR: foo.txt,bar.txt
cmds:
- for: { var: MY_VAR, split: ',' }
cmd: cat {{.ITEM}}
```
All of this also works with dynamic variables!
```yaml
version: '3'
tasks:
default:
vars:
MY_VAR:
sh: find -type f -name '*.txt'
cmds:
- for: { var: MY_VAR }
cmd: cat {{.ITEM}}
```
### Renaming variables
If you want to rename the iterator variable to make it clearer what the value
contains, you can do so by specifying the `as` property:
```yaml
version: '3'
tasks:
default:
vars:
MY_VAR: foo.txt bar.txt
cmds:
- for: { var: MY_VAR, as: FILE }
cmd: cat {{.FILE}}
```
### Looping over tasks
Because the `for` property is defined at the `cmds` level, you can also use it
alongside the `task` keyword to run tasks multiple times with different
variables.
```yaml
version: '3'
tasks:
default:
cmds:
- for: [foo, bar]
task: my-task
vars:
FILE: '{{.ITEM}}'
my-task:
cmds:
- echo '{{.FILE}}'
```
Or if you want to run different tasks depending on the value of the loop:
```yaml
version: '3'
tasks:
default:
cmds:
- for: [foo, bar]
task: task-{{.ITEM}}
task-foo:
cmds:
- echo 'foo'
task-bar:
cmds:
- echo 'bar'
```
## Forwarding CLI arguments to commands
If `--` is given in the CLI, all following parameters are added to a special
@@ -1083,12 +1253,12 @@ tasks:
Task also adds the following functions:
- `OS`: Returns the operating system. Possible values are "windows", "linux",
"darwin" (macOS) and "freebsd".
- `ARCH`: return the architecture Task was compiled to: "386", "amd64", "arm" or
"s390x".
- `splitLines`: Splits Unix (\n) and Windows (\r\n) styled newlines.
- `catLines`: Replaces Unix (\n) and Windows (\r\n) styled newlines with a
- `OS`: Returns the operating system. Possible values are `windows`, `linux`,
`darwin` (macOS) and `freebsd`.
- `ARCH`: return the architecture Task was compiled to: `386`, `amd64`, `arm` or
`s390x`.
- `splitLines`: Splits Unix (`\n`) and Windows (`\r\n`) styled newlines.
- `catLines`: Replaces Unix (`\n`) and Windows (`\r\n`) styled newlines with a
space.
- `toSlash`: Does nothing on Unix, but on Windows converts a string from `\`
path format to `/`.
@@ -1260,7 +1430,8 @@ tasks:
## Warning Prompts
Warning Prompts to prompt a user for confirmation before a task is executed.
Warning Prompts are used 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:
@@ -1314,7 +1485,7 @@ 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,
CI, where an `stdin` won't be available for the user to answer. In those cases,
use `--yes` (`-y`) to force all tasks with a prompt to run.
:::

View File

@@ -31,18 +31,37 @@ const getConfig = async () => {
i18n: {
defaultLocale: 'en',
locales: ['en', 'fr-FR', 'pt-BR', 'ru-RU', 'es-ES', 'zh-Hans'],
locales: [
'en',
'es-ES',
'fr-FR',
'ja-JP',
'pt-BR',
'ru-RU',
'tr-TR',
'zh-Hans'
],
localeConfigs: {
en: {
label: 'English',
direction: 'ltr',
htmlLang: 'en-US'
},
'es-ES': {
label: `Español (${translationProgress['es-ES'] || 0}%)`,
direction: 'ltr',
htmlLang: 'es-ES'
},
'fr-FR': {
label: `Français (${translationProgress['fr'] || 0}%)`,
direction: 'ltr',
htmlLang: 'fr-FR'
},
'ja-JP': {
label: `日本語 (${translationProgress['ja'] || 0}%)`,
direction: 'ltr',
htmlLang: 'ja-JP'
},
'pt-BR': {
label: `Português (${translationProgress['pt-BR'] || 0}%)`,
direction: 'ltr',
@@ -53,10 +72,10 @@ const getConfig = async () => {
direction: 'ltr',
htmlLang: 'ru-RU'
},
'es-ES': {
label: `Español (${translationProgress['es-ES'] || 0}%)`,
'tr-TR': {
label: `Türkçe (${translationProgress['tr'] || 0}%)`,
direction: 'ltr',
htmlLang: 'es-ES'
htmlLang: 'tr-TR'
},
'zh-Hans': {
label: `简体中文 (${translationProgress['zh-CN'] || 0}%)`,
@@ -75,9 +94,12 @@ const getConfig = async () => {
routeBasePath: '/',
sidebarPath: require.resolve('./sidebars.js')
},
blog: false,
blog: {},
theme: {
customCss: [require.resolve('./src/css/custom.css')]
customCss: [
require.resolve('./src/css/custom.css'),
require.resolve('./src/css/carbon.css')
]
},
gtag: {
trackingID: 'G-4RT25NXQ7N',
@@ -92,6 +114,13 @@ const getConfig = async () => {
]
],
scripts: [
{
src: '/js/carbon.js',
async: true
}
],
themeConfig:
/** @type {import('@docusaurus/preset-classic').ThemeConfig} */
({
@@ -126,6 +155,11 @@ const getConfig = async () => {
position: 'left',
label: 'API'
},
{
to: 'blog',
label: 'Blog',
position: 'left'
},
{
type: 'doc',
docId: 'donate',

View File

@@ -0,0 +1,93 @@
---
title: Introducing Experiments
description: A look at where task is, where it's going and how we're going to get there.
slug: task-in-2023
authors:
- pd93
tags:
- experiments
- breaking-changes
- roadmap
- v4
image: https://i.imgur.com/mErPwqL.png
hide_table_of_contents: false
---
Lately, Task has been growing extremely quickly and I've found myself thinking a lot about the future of the project and how we continue to evolve and grow. I'm not much of a writer, but I think one of the things we could do better is to communicate these kinds of thoughts to the community. So, with that in mind, this is the first (hopefully of many) blog posts talking about Task and what we're up to.
<!--truncate-->
## :calendar: So, what have we been up to?
Over the past 12 months or so, [@andreynering][] (Author and maintainer of the project) and I ([@pd93][]) have been working in our spare time to maintain and improve v3 of Task and we've made some amazing progress. Here are just some of the things we've released in that time:
- An official [extension for VS Code][vscode-task].
- Internal Tasks ([#818](https://github.com/go-task/task/pull/818)).
- Task aliases ([#879](https://github.com/go-task/task/pull/879)).
- Looping over tasks ([#1220](https://github.com/go-task/task/pull/1200)).
- A series of refactors to the core codebase to make it more maintainable and extensible.
- Loads of bug fixes and improvements.
- An integration with [Crowdin][crowdin]. Work is in progress on making our docs available in **7 new languages** (Special thanks to all our translators for the huge help with this!).
- And much, much more! :sparkles:
We're also working on adding some really exciting and highly requested features to Task such as having the ability to run remote Taskfiles ([#1317](https://github.com/go-task/task/issues/1317)).
None of this would have been possible without the [150 or so (and growing) contributors][contributors] to the project, numerous sponsors and a passionate community of users. Together we have more than doubled the number of GitHub stars to over 8400 :star: since the beginning of 2022 and this continues to accelerate. We can't thank you all enough for your help and support! :rocket:
[![Star History Chart](https://api.star-history.com/svg?repos=go-task/task&type=Date)](https://star-history.com/#go-task/task&Date)
## What's next? :thinking_face:
It's extremely motivating to see so many people using and loving Task. However, in this time we've also seen an increase in the number of issues and feature requests. In particular, issues that require some kind of breaking change to Task. This isn't a bad thing, but as we grow we need to be more responsible about how we address these changes in a way that ensures stability and compatibility for existing users and their Taskfiles.
At this point you're probably thinking something like:
> "But you use [semantic versioning][semver] - Just release a new major version with your breaking changes."
And you'd be right... sort of. In theory, this sounds great, but the reality is that we don't have the time to commit to a major overhaul of Task in one big bang release. This would require a colossal amount of time and coordination and with full time jobs and personal lives to tend to, this is a difficult commitment to make. Smaller, more frequent major releases are also a significant inconvenience for users as they have to constantly keep up-to-date with our breaking changes. Fortunately, there is a better way.
## What's going to change? :face_with_monocle:
Going forwards, breaking changes will be allowed into _minor_ versions of Task as "experimental features". To access these features users will need opt-in by enabling feature flags. This will allow us to release new features slowly and gather feedback from the community before making them the default behavior in a future major release.
To prepare users for the next major release, we will maintain a list of [deprecated features][deprecations] and [experiments][experiments] on our docs website and publish information on how to migrate to the new behavior.
You can read the [full breaking change proposal][breaking-change-proposal] and view all the [current experiments and their status][experiments-project] on GitHub including the [Gentle Force][gentle-force-experiment] and [Remote Taskfiles][remote-taskfiles-experiment] experiments.
## What will happen to v2/v3 features?
v2 has been [officially deprecated][deprecate-version-2-schema]. If you're still using a Taskfile with `version: "2"` at the top we _strongly recommend_ that you upgrade as soon as possible. Removing v2 will allow us to tidy up the codebase and focus on new functionality instead.
When v4 is released, we will continue to support v3 for a period of time (bug fixes etc). However, since we are moving from a backward-compatibility model to a forwards-compatibility model, **v4 itself will not be backwards compatible with v3**.
## v4 When? :eyes:
:shrug: When it's ready.
In all seriousness, we don't have a timeline for this yet. We'll be working on the most serious deficiencies of the v3 API first and regularly evaluating the state of the project. When we feel its in a good, stable place and we have a clear upgrade path for users and a number of stable experiments, we'll start to think about v4.
## :wave: Final thoughts
Task is growing fast and we're excited to see where it goes next. We hope that the steps we're taking to improve the project and our process will help us to continue to grow. As always, if you have any questions or feedback, we encourage you to comment on or open [issues][issues] and [discussions][discussions] on GitHub. Alternatively, you can join us on [Discord][discord].
I plan to write more of these blog posts in the future on a variety of Task-related topics, so make sure to check in occasionally and see what we're up to!
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[vscode-task]: https://github.com/go-task/vscode-task
[crowdin]: https://crowdin.com
[contributors]: https://github.com/go-task/task/graphs/contributors
[semver]: https://semver.org
[breaking-change-proposal]: https://github.com/go-task/task/discussions/1191
[@andreynering]: https://github.com/andreynering
[@pd93]: https://github.com/pd93
[experiments]: https://taskfile.dev/experiments
[deprecations]: https://taskfile.dev/deprecations
[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
[issues]: https://github.com/go-task/task/issues
[discussions]: https://github.com/go-task/task/discussions
[discord]: https://discord.gg/6TY36E39UK
[experiments-project]: https://github.com/orgs/go-task/projects/1
[gentle-force-experiment]: https://github.com/go-task/task/issues/1200
[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317

View File

@@ -3,3 +3,8 @@ andreynering:
title: Maintainer of Task
url: https://github.com/andreynering
image_url: https://github.com/andreynering.png
pd93:
name: Pete Davison
title: Maintainer of Task
url: https://github.com/pd93
image_url: https://github.com/pd93.png

View File

@@ -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
If `--` is given, all remaining arguments will be assigned to a special `CLI_ARGS` variable
:::
@@ -74,6 +74,7 @@ A full list of the exit codes and their descriptions can be found below:
| 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 |
| 206 | A task was not executed due to missing required variables |
These codes can also be found in the repository in [`errors/errors.go`](https://github.com/go-task/task/blob/main/errors/errors.go).
@@ -119,12 +120,13 @@ There are some special variables that is available on the templating system:
| `TASKFILE_DIR` | The absolute path of the included Taskfile. |
| `USER_WORKING_DIR` | The absolute path of the directory `task` was called from. |
| `CHECKSUM` | The checksum of the files listed in `sources`. Only available within the `status` prop and if method is set to `checksum`. |
| `TIMESTAMP` | The date object of the greatest timestamp of the files listes in `sources`. Only available within the `status` prop and if method is set to `timestamp`. |
| `TIMESTAMP` | The date object of the greatest timestamp of the files listed in `sources`. Only available within the `status` prop and if method is set to `timestamp`. |
| `TASK_VERSION` | The current version of task. |
| `ITEM` | The value of the current iteration when using the `for` property. Can be changed to a different variable name using `as:`. |
## ENV
Some environment variables can be overriden to adjust Task behavior.
Some environment variables can be overridden to adjust Task behavior.
| ENV | Default | Description |
| -------------------- | ------- | ----------------------------------------------------------------------------------------------------------------- |
@@ -144,12 +146,12 @@ Some environment variables can be overriden to adjust Task behavior.
| ---------- | ---------------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `version` | `string` | | Version of the Taskfile. The current version is `3`. |
| `output` | `string` | `interleaved` | Output mode. Available options: `interleaved`, `group` and `prefixed`. |
| `method` | `string` | `checksum` | Default method in this Taskfile. Can be overriden in a task by task basis. Available options: `checksum`, `timestamp` and `none`. |
| `method` | `string` | `checksum` | Default method in this Taskfile. Can be overridden in a task by task basis. Available options: `checksum`, `timestamp` and `none`. |
| `includes` | [`map[string]Include`](#include) | | Additional Taskfiles to be included. |
| `vars` | [`map[string]Variable`](#variable) | | A set of global variables. |
| `env` | [`map[string]Variable`](#variable) | | A set of global environment variables. |
| `tasks` | [`map[string]Task`](#task) | | A set of task definitions. |
| `silent` | `bool` | `false` | Default 'silent' options for this Taskfile. If `false`, can be overidden with `true` in a task by task basis. |
| `silent` | `bool` | `false` | Default 'silent' options for this Taskfile. If `false`, can be overridden with `true` in a task by task basis. |
| `dotenv` | `[]string` | | A list of `.env` file paths to be parsed. |
| `run` | `string` | `always` | Default 'run' option for this Taskfile. Available options: `always`, `once` and `when_changed`. |
| `interval` | `string` | `5s` | Sets a different watch interval when using `--watch`, the default being 5 seconds. This string should be a valid [Go Duration](https://pkg.go.dev/time#ParseDuration). |
@@ -212,7 +214,9 @@ vars:
| `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. |
| `generates` | `[]string` | | A list of files meant to be generated by this task. Relevant for `timestamp` method. Can be file paths or star globs. |
| `status` | `[]string` | | A list of commands to check if this task should run. The task is skipped otherwise. This overrides `method`, `sources` and `generates`. |
| `requires` | `[]string` | | A list of variables which should be set if this task is to run, if any of these variables are unset the task will error and not run. |
| `preconditions` | [`[]Precondition`](#precondition) | | A list of commands to check if this task should run. If a condition is not met, the task will error. |
| `requires` | [`Requires`](#requires) | | A list of required variables which should be set if this task is to run, if any variables listed are unset the task will error and not run. |
| `dir` | `string` | | The directory in which this task should run. Defaults to the current working directory. |
| `vars` | [`map[string]Variable`](#variable) | | A set of variables that can be used in the task. |
| `env` | [`map[string]Variable`](#variable) | | A set of environment variables that will be made available to shell commands. |
@@ -251,8 +255,9 @@ tasks:
| Attribute | Type | Default | Description |
| -------------- | ---------------------------------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `cmd` | `string` | | The shell command to be executed. |
| `silent` | `bool` | `false` | Skips some output for this command. Note that STDOUT and STDERR of the commands will still be redirected. |
| `task` | `string` | | Set this to trigger execution of another task instead of running a command. This cannot be set together with `cmd`. |
| `for` | [`For`](#for) | | Runs the command once for each given value. |
| `silent` | `bool` | `false` | Skips some output for this command. Note that STDOUT and STDERR of the commands will still be redirected. |
| `vars` | [`map[string]Variable`](#variable) | | Optional additional variables to be passed to the referenced task. Only relevant when setting `task` instead of `cmd`. |
| `ignore_error` | `bool` | `false` | Continue execution if errors happen while executing the command. |
| `defer` | `string` | | Alternative to `cmd`, but schedules the command to be executed at the end of this task instead of immediately. This cannot be used together with `cmd`. |
@@ -294,6 +299,22 @@ tasks:
:::
#### For
The `for` parameter can be defined as a string, a list of strings or a map. If it is defined as a string, you can give it any of the following values:
- `source` - Will run the command for each source file defined on the task. (Glob patterns will be resolved, so `*.go` will run for every Go file that matches).
If it is defined as a list of strings, the command will be run for each value.
Finally, the `for` parameter can be defined as a map when you want to use a variable to define the values to loop over:
| Attribute | Type | Default | Description |
| --------- | -------- | ---------------- | -------------------------------------------- |
| `var` | `string` | | The name of the variable to use as an input. |
| `split` | `string` | (any whitespace) | What string the variable should be split on. |
| `as` | `string` | `ITEM` | The name of the iterator variable. |
#### Precondition
| Attribute | Type | Default | Description |
@@ -312,3 +333,9 @@ tasks:
```
:::
#### Requires
| Attribute | Type | Default | Description |
| --------- | ---------- | ------- | -------------------------------------------------------------------------------------------------- |
| `vars` | `[]string` | | List of variable or environment variable names that must be set if this task is to execute and run |

View File

@@ -1,10 +1,38 @@
---
slug: /changelog/
sidebar_position: 9
sidebar_position: 14
---
# Changelog
## v3.29.1 - 2023-08-26
- Update to Go 1.21 (bump minimum version to 1.20) ([#1302](https://github.com/go-task/task/issues/1302) by [@pd93](https://github.com/pd93))
- Fix a missing a line break on log when using `--watch` mode ([#1285](https://github.com/go-task/task/issues/1285), [#1297](https://github.com/go-task/task/issues/1297) by [@FilipSolich](https://github.com/FilipSolich)).
- Fix `defer` on JSON Schema ([#1288](https://github.com/go-task/task/issues/1288) by [@calvinmclean](https://github.com/calvinmclean) and [@andreynering](https://github.com/andreynering)).
- Fix bug in usage of special variables like `{{.USER_WORKING_DIR}}` in combination with `includes` ([#1046](https://github.com/go-task/task/issues/1046), [#1205](https://github.com/go-task/task/issues/1205), [#1250](https://github.com/go-task/task/issues/1250), [#1293](https://github.com/go-task/task/issues/1293), [#1312](https://github.com/go-task/task/issues/1312), [#1274](https://github.com/go-task/task/issues/1274) by [@andarto](https://github.com/andarto), [#1309](https://github.com/go-task/task/issues/1309) by [@andreynering](https://github.com/andreynering)).
- Fix bug on `--status` flag. Running this flag should not have side-effects: it should not update the checksum on `.task`, only report its status ([#1305](https://github.com/go-task/task/issues/1305), [#1307](https://github.com/go-task/task/issues/1307) by [@visciang](https://github.com/visciang), [#1313](https://github.com/go-task/task/issues/1313) by [@andreynering](https://github.com/andreynering)).
## v3.28.0 - 2023-07-24
- Added the ability to [loop over commands and tasks](https://taskfile.dev/usage/#looping-over-values) using `for` ([#82](https://github.com/go-task/task/issues/82), [#1220](https://github.com/go-task/task/issues/1220) by [@pd93](https://github.com/pd93)).
- Fixed variable propagation in multi-level includes ([#778](https://github.com/go-task/task/issues/778), [#996](https://github.com/go-task/task/issues/996), [#1256](https://github.com/go-task/task/issues/1256) by [@hudclark](https://github.com/hudclark)).
- Fixed a bug where the `--exit-code` code flag was not returning the correct exit code when calling commands indirectly ([#1266](https://github.com/go-task/task/issues/1266), [#1270](https://github.com/go-task/task/issues/1270) by [@pd93](https://github.com/pd93)).
- Fixed a `nil` panic when a dependency was commented out or left empty ([#1263](https://github.com/go-task/task/issues/1263) by [@neomantra](https://github.com/neomantra)).
## v3.27.1 - 2023-06-30
- Fix panic when a `.env` directory (not file) is present on current directory ([#1244](https://github.com/go-task/task/issues/1244), [#1245](https://github.com/go-task/task/issues/1245) by [@pd93](https://github.com/pd93)).
## v3.27.0 - 2023-06-29
- Allow Taskfiles starting with lowercase characters ([#947](https://github.com/go-task/task/issues/947), [#1221](https://github.com/go-task/task/issues/1221) by [@pd93](https://github.com/pd93)).
- e.g. `taskfile.yml`, `taskfile.yaml`, `taskfile.dist.yml` & `taskfile.dist.yaml`
- Bug fixes were made to the [npm installation method](https://taskfile.dev/installation/#npm). ([#1190](https://github.com/go-task/task/issues/1190), by [@sounisi5011](https://github.com/sounisi5011)).
- Added the [gentle force experiment](https://taskfile.dev/experiments) as a draft ([#1200](https://github.com/go-task/task/issues/1200), [#1216](https://github.com/go-task/task/issues/1216) by [@pd93](https://github.com/pd93)).
- Added an `--experiments` flag to allow you to see which experiments are enabled ([#1242](https://github.com/go-task/task/issues/1242) by [@pd93](https://github.com/pd93)).
- Added ability to specify which variables are required in a task ([#1203](https://github.com/go-task/task/issues/1203), [#1204](https://github.com/go-task/task/issues/1204) by [@benc](https://github.com/benc)-uk).
## v3.26.0 - 2023-06-10
- Only rewrite checksum files in `.task` if the checksum has changed ([#1185](https://github.com/go-task/task/issues/1185), [#1194](https://github.com/go-task/task/issues/1194) by [@deviantintegral](https://github.com/deviantintegral)).

View File

@@ -1,6 +1,6 @@
---
slug: /community/
sidebar_position: 10
sidebar_position: 9
---
# Community

View File

@@ -0,0 +1,12 @@
---
slug: /deprecations/
sidebar_position: 7
---
# Deprecations
As Task evolves, it occasionally outgrows some of its functionality. This can be because they are no longer useful, because another feature has replaced it or because of a change in the way that Task works internally.
When this happens, we mark the functionality as deprecated. This means that it will be removed in a future version of Task. This functionality will continue to work until that time, but we strongly recommend that you do not implement this functionality in new Taskfiles and make a plan to migrate away from it as soon as possible.
You can view a full list of active deprecations in the "Deprecations" section of the sidebar.

View File

@@ -0,0 +1,17 @@
---
#This is a template for an experiments documentation
#Copy this page and fill in the details as necessary
title: '--- Template ---'
sidebar_position: -1 #Always push to the top
draft: true #Hide in production
---
# {Name of Deprecated Feature}
- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
- Breaks:
- {list any existing functionality that will be broken by this experiment}
{Short description of the feature/behavior and why it is being deprecated}
{Short explanation of any replacement features/behaviors and how users should migrate to it}

View File

@@ -0,0 +1,22 @@
---
slug: /deprecations/version-2-schema/
---
# Version 2 Schema
- Issue: [#1197][deprecate-version-2-schema]
- Breaks:
- Any Taskfiles that use the version 2 schema
- `Taskvar.yml` files
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

View File

@@ -1,6 +1,6 @@
---
slug: /donate/
sidebar_position: 15
sidebar_position: 16
---
# Donate

View File

@@ -1,6 +1,6 @@
---
slug: /experiments/
sidebar_position: 5
sidebar_position: 6
---
# Experiments
@@ -11,7 +11,9 @@ All experimental features are subject to breaking changes and/or removal _at any
:::
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.
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 their status in the [workflow](#workflow).
You can view a full list of active experiments in the "Experiments" section of the sidebar.
You can enable an experimental feature by:
@@ -28,43 +30,49 @@ TASK_X_FEATURE=1
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...
## Workflow
### ![experiment] {Feature} ([#{issue}](https://github.com/go-task/task/issues/{issue})), ...)
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.
- Environment variable: `TASK_X_{feature}`
- Deprecates: {list any existing functionality that will be deprecated by this experiment}
- Breaks: {list any existing functionality that will be broken by this experiment}
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.
{Short description of the feature}
### 1. Proposal
{Short explanation of how users should migrate to the new behavior}
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
### ![deprecated][] Version 2 Schema ([#1197][deprecate-version-2-schema])
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.
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.
:::note
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.
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_.
A list of changes between version 2 and version 3 are available in the [Task v3 Release Notes][version-3-release-notes].
:::
### ![experiment][] Gentle Force ([#1200](https://github.com/go-task/task/issues/1200))
### 3. Candidate
- Environment variable: `TASK_X_FORCE=1`
- Breaks: `--force` flag
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.
The `--force` flag currently forces _all_ tasks to run regardless of the status checks. This can be useful, but we have found that most of the time users only expect the direct task they are calling to be forced and _not_ all of its dependant tasks.
### 4. Stable
This experiment changes the `--force` flag to only force the directly called task. All dependant tasks will have their statuses checked as normal and will only run if Task considers them to be out of date. A new `--force-all` flag will also be added to maintain the current behavior for users that need this functionality.
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.
If you want to migrate, but continue to force all dependant tasks to run, you should replace all uses of the `--force` flag with `--force-all`. Alternatively, if you want to adopt the new behavior, you can continue to use the `--force` flag as you do now!
### 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 -->
[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
[experiment]: https://img.shields.io/badge/experiment-yellow
[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

View File

@@ -0,0 +1,21 @@
---
slug: /experiments/gentle-force/
---
# Gentle Force
- Issue: [#1200][gentle-force-experiment]
- Environment variable: `TASK_X_FORCE=1`
- Breaks:
- `--force` flag
The `--force` flag currently forces _all_ tasks to run regardless of the status checks. This can be useful, but we have found that most of the time users only expect the direct task they are calling to be forced and _not_ all of its dependant tasks.
This experiment changes the `--force` flag to only force the directly called task. All dependant tasks will have their statuses checked as normal and will only run if Task considers them to be out of date. A new `--force-all` flag will also be added to maintain the current behavior for users that need this functionality.
If you want to migrate, but continue to force all dependant tasks to run, you should replace all uses of the `--force` flag with `--force-all`. Alternatively, if you want to adopt the new behavior, you can continue to use the `--force` flag as you do now!
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[gentle-force-experiment]: https://github.com/go-task/task/issues/1200

View File

@@ -0,0 +1,54 @@
---
slug: /experiments/remote-taskfiles/
---
# Remote Taskfiles
- Issue: [#1317][remote-taskfiles-experiment]
- Environment variable: `TASK_X_REMOTE_TASKFILES=1`
This experiment allows you to specify a remote Taskfile URL when including a Taskfile. For example:
```yaml
version: '3'
include:
my-remote-namespace: https://raw.githubusercontent.com/my-org/my-repo/main/Taskfile.yml
```
This works exactly the same way that including a local file does. Any tasks in the remote Taskfile will be available to run from your main Taskfile via the namespace `my-remote-namespace`. For example, if the remote file contains the following:
```yaml
version: '3'
tasks:
hello:
silent: true
cmds:
- echo "Hello from the remote Taskfile!"
```
and you run `task my-remote-namespace:hello`, it will print the text: "Hello from the remote Taskfile!" to your console.
## Security
Running commands from sources that you do not control is always a potential security risk. For this reason, we have added some checks when using remote Taskfiles:
1. When running a task from a remote Taskfile for the first time, Task will print a warning to the console asking you to check that you are sure that you trust the source of the Taskfile. If you do not accept the prompt, then Task will exit with code `104` (not trusted) and nothing will run. If you accept the prompt, the remote Taskfile will run and further calls to the remote Taskfile will not prompt you again.
2. Whenever you run a remote Taskfile, Task will create and store a checksum of the file that you are running. If the checksum changes, then Task will print another warning to the console to inform you that the contents of the remote file has changed. If you do not accept the prompt, then Task will exit with code `104` (not trusted) and nothing will run. If you accept the prompt, the checksum will be updated and the remote Taskfile will run.
Task currently supports both `http` and `https` URLs. However, the `http` requests will not execute by default unless you run the task with the `--insecure` flag. This is to protect you from accidentally running a remote Taskfile that is hosted on and unencrypted connection. Sources that are not protected by TLS are vulnerable to [man-in-the-middle attacks][man-in-the-middle-attacks] and should be avoided unless you know what you are doing.
## Caching & Running Offline
If for whatever reason, you don't have access to the internet, but you still need to be able to run your tasks, you are able to use the `--download` flag to store a cached copy of the remote Taskfile.
<!-- TODO: The following behavior may change -->
If Task detects that you have a local copy of the remote Taskfile, it will use your local copy instead of downloading the remote file. You can force Task to work offline by using the `--offline` flag. This will prevent Task from making any calls to remote sources.
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317
[man-in-the-middle-attacks]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack

View File

@@ -0,0 +1,20 @@
---
#This is a template for an experiments documentation
#Copy this page and fill in the details as necessary
title: '--- Template ---'
sidebar_position: -1 #Always push to the top
draft: true #Hide in production
---
# {Name of Experiment}
- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
- Environment variable: `TASK_X_{feature}`
- Breaks:
- {list any existing functionality that will be broken by this experiment}
- Deprecations:
- {link to any deprecation pages related to this experiment}
{Short description of the feature}
{Short explanation of how users should migrate to the new behavior}

View File

@@ -1,6 +1,6 @@
---
slug: /faq/
sidebar_position: 7
sidebar_position: 15
---
# FAQ

View File

@@ -25,6 +25,21 @@ Recently, Task was also made available [on the official Homebrew repository](htt
brew install go-task
```
### Tea
If you're on macOS or Linux and have [tea][tea] installed, getting Task is as simple as running:
```bash
tea task
```
or, if you have teas magic enabled:
```bash
task
```
This installation method is community owned. After a new release of Task, they are automatically released by tea in a minimum of time.
### Snap
Task is available in [Snapcraft][snapcraft], but keep in mind that your Linux distribution should allow classic confinement for Snaps to Task work right:
@@ -248,3 +263,4 @@ Invoke-Expression -Command path/to/task.ps1
[godownloader]: https://github.com/goreleaser/godownloader
[choco]: https://chocolatey.org/
[scoop]: https://scoop.sh/
[tea]: https://tea.xyz/

View File

@@ -1,6 +1,6 @@
---
slug: /integrations/
sidebar_position: 6
sidebar_position: 8
---
# Integrations
@@ -9,7 +9,7 @@ sidebar_position: 6
Task has an [official extension for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=task.vscode-task). El código de ese proyecto puede ser encontrado [aquí](https://github.com/go-task/vscode-task). Para usar la extensión es necesario tener instalada la versión v3.23.0+ de Task.
This extension provides the following features (and more):
La extensión proporciona las siguientes funcionalidades (y más...):
- View tasks in the sidebar.
- Ejecuta tareas desde la barra lateral y la paleta de comandos.

View File

@@ -26,6 +26,10 @@ The [snap package][snappackage] requires to manual steps to release a new versio
- Updating the current version on [snapcraft.yaml][snapcraftyaml].
- Moving both `amd64`, `armhf` and `arm64` new artifacts to the stable channel on the [Snapcraft dashboard][snapcraftdashboard].
# winget
winget also requires manual steps to be completed. By running `task test-release` locally, manifest files will be generated on `dist/winget/manifests/t/Task/Task/v{version}`. [Upload the manifest directory into this fork](https://github.com/go-task/winget-pkgs/tree/master/manifests/t/Task/Task) and open a pull request into [this repository](https://github.com/microsoft/winget-pkgs).
# Scoop
Scoop is a command-line package manager for the Windows operating system. Scoop package manifests are maintained by the community. Scoop owners usually take care of updating versions there by editing [this file](https://github.com/ScoopInstaller/Main/blob/master/bucket/task.json). If you think its Task version is outdated, open an issue to let us know.

View File

@@ -1,6 +1,6 @@
---
slug: /styleguide/
sidebar_position: 8
sidebar_position: 10
---
# Styleguide

View File

@@ -1,6 +1,6 @@
---
slug: /taskfile-versions/
sidebar_position: 14
sidebar_position: 5
---
# Taskfile Versions
@@ -21,7 +21,7 @@ These are some major changes done on `v3`:
- 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:`
- Two magic variables were added when using `status:`: `CHECKSUM` and `TIMESTAMP` which contains, respectively, the XXH3 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:

View File

@@ -753,6 +753,42 @@ tasks:
- sleep 5 # long operation like installing packages
```
### Ensuring required variables are set
If you want to check that certain variables are set before running a task then you can use `requires`. This is useful when might not be clear to users which variables are needed, or if you want clear message about what is required. Also some tasks could have dangerous side effects if run with un-set variables.
Using `requires` you specify an array of strings in the `vars` sub-section under `requires`, these strings are variable names which are checked prior to running the task. If any variables are un-set the the task will error and not run.
Environmental variables are also checked.
Syntax:
```yaml
requires:
vars: [] # Array of strings
```
:::note
Variables set to empty zero length strings, will pass the `requires` check.
:::
Example of using `requires`:
```yaml
version: '3'
tasks:
docker-build:
cmds:
- 'docker build . -t {{.IMAGE_NAME}}:{{.IMAGE_TAG}}'
# Make sure these variables are set before running
requires:
vars: [IMAGE_NAME, IMAGE_TAG]
```
## Variables
When doing interpolation of variables, Task will look for the below. They are listed below in order of importance (i.e. most important first):
@@ -827,6 +863,162 @@ tasks:
This works for all types of variables.
## Looping over values
As of v3.28.0, Task allows you to loop over certain values and execute a command for each. There are a number of ways to do this depending on the type of value you want to loop over.
### Looping over a static list
The simplest kind of loop is an explicit one. This is useful when you want to loop over a set of values that are known ahead of time.
```yaml
version: '3'
tasks:
default:
cmds:
- for: ['foo.txt', 'bar.txt']
cmd: cat {{ .ITEM }}
```
### Looping over your task's sources
You are also able to loop over the sources of your task:
```yaml
version: '3'
tasks:
default:
sources:
- foo.txt
- bar.txt
cmds:
- for: sources
cmd: cat {{ .ITEM }}
```
This will also work if you use globbing syntax in your sources. For example, if you specify a source for `*.txt`, the loop will iterate over all files that match that glob.
Source paths will always be returned as paths relative to the task directory. If you need to convert this to an absolute path, you can use the built-in `joinPath` function. There are some [special variables](/api/#special-variables) that you may find useful for this.
```yaml
version: '3'
tasks:
default:
vars:
MY_DIR: /path/to/dir
dir: '{{.MY_DIR}}'
sources:
- foo.txt
- bar.txt
cmds:
- for: sources
cmd: cat {{joinPath .MY_DIR .ITEM}}
```
### Looping over variables
To loop over the contents of a variable, you simply need to specify the variable you want to loop over. By default, variables will be split on any whitespace characters.
```yaml
version: '3'
tasks:
default:
vars:
MY_VAR: foo.txt bar.txt
cmds:
- for: { var: MY_VAR }
cmd: cat {{.ITEM}}
```
If you need to split on a different character, you can do this by specifying the `split` property:
```yaml
version: '3'
tasks:
default:
vars:
MY_VAR: foo.txt,bar.txt
cmds:
- for: { var: MY_VAR, split: ',' }
cmd: cat {{.ITEM}}
```
All of this also works with dynamic variables!
```yaml
version: '3'
tasks:
default:
vars:
MY_VAR:
sh: find -type f -name '*.txt'
cmds:
- for: { var: MY_VAR }
cmd: cat {{.ITEM}}
```
### Renaming variables
If you want to rename the iterator variable to make it clearer what the value contains, you can do so by specifying the `as` property:
```yaml
version: '3'
tasks:
default:
vars:
MY_VAR: foo.txt bar.txt
cmds:
- for: { var: MY_VAR, as: FILE }
cmd: cat {{.FILE}}
```
### Looping over tasks
Because the `for` property is defined at the `cmds` level, you can also use it alongside the `task` keyword to run tasks multiple times with different variables.
```yaml
version: '3'
tasks:
default:
cmds:
- for: [foo, bar]
task: my-task
vars:
FILE: '{{.ITEM}}'
my-task:
cmds:
- echo '{{.FILE}}'
```
Or if you want to run different tasks depending on the value of the loop:
```yaml
version: '3'
tasks:
default:
cmds:
- for: [foo, bar]
task: task-{{.ITEM}}
task-foo:
cmds:
- echo 'foo'
task-bar:
cmds:
- echo 'bar'
```
## Forwarding CLI arguments to commands
If `--` is given in the CLI, all following parameters are added to a special `.CLI_ARGS` variable. This is useful to forward arguments to another command.
@@ -901,10 +1093,10 @@ tasks:
Task also adds the following functions:
- `OS`: Returns the operating system. Possible values are "windows", "linux", "darwin" (macOS) and "freebsd".
- `ARCH`: return the architecture Task was compiled to: "386", "amd64", "arm" or "s390x".
- `splitLines`: Splits Unix (\n) and Windows (\r\n) styled newlines.
- `catLines`: Replaces Unix (\n) and Windows (\r\n) styled newlines with a space.
- `OS`: Returns the operating system. Possible values are `windows`, `linux`, `darwin` (macOS) and `freebsd`.
- `ARCH`: return the architecture Task was compiled to: `386`, `amd64`, `arm` or `s390x`.
- `splitLines`: Splits Unix (`\n`) and Windows (`\r\n`) styled newlines.
- `catLines`: Replaces Unix (`\n`) and Windows (`\r\n`) styled newlines with a space.
- `toSlash`: Does nothing on Unix, but on Windows converts a string from `\` path format to `/`.
- `fromSlash`: Opposite of `toSlash`. Does nothing on Unix, but on Windows converts a string from `/` path format to `\`.
- `exeExt`: Returns the right executable extension for the current OS (`".exe"` for Windows, `""` for others).
@@ -1059,7 +1251,7 @@ tasks:
## Warning Prompts
Warning Prompts to prompt a user for confirmation before a task is executed.
Warning Prompts are used 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:
@@ -1107,7 +1299,7 @@ To skip warning prompts automatically, you can use the `--yes` (alias `-y`) opti
:::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.
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 those cases, use `--yes` (`-y`) to force all tasks with a prompt to run.
:::

View File

@@ -0,0 +1,93 @@
---
title: Introducing Experiments
description: A look at where task is, where it's going and how we're going to get there.
slug: task-in-2023
authors:
- pd93
tags:
- experiments
- breaking-changes
- roadmap
- v4
image: https://i.imgur.com/mErPwqL.png
hide_table_of_contents: false
---
Lately, Task has been growing extremely quickly and I've found myself thinking a lot about the future of the project and how we continue to evolve and grow. I'm not much of a writer, but I think one of the things we could do better is to communicate these kinds of thoughts to the community. So, with that in mind, this is the first (hopefully of many) blog posts talking about Task and what we're up to.
<!--truncate-->
## :calendar: So, what have we been up to?
Over the past 12 months or so, [@andreynering][] (Author and maintainer of the project) and I ([@pd93][]) have been working in our spare time to maintain and improve v3 of Task and we've made some amazing progress. Here are just some of the things we've released in that time:
- An official [extension for VS Code][vscode-task].
- Internal Tasks ([#818](https://github.com/go-task/task/pull/818)).
- Task aliases ([#879](https://github.com/go-task/task/pull/879)).
- Looping over tasks ([#1220](https://github.com/go-task/task/pull/1200)).
- A series of refactors to the core codebase to make it more maintainable and extensible.
- Loads of bug fixes and improvements.
- An integration with [Crowdin][crowdin]. Work is in progress on making our docs available in **7 new languages** (Special thanks to all our translators for the huge help with this!).
- And much, much more! :sparkles:
We're also working on adding some really exciting and highly requested features to Task such as having the ability to run remote Taskfiles ([#1317](https://github.com/go-task/task/issues/1317)).
None of this would have been possible without the [150 or so (and growing) contributors][contributors] to the project, numerous sponsors and a passionate community of users. Together we have more than doubled the number of GitHub stars to over 8400 :star: since the beginning of 2022 and this continues to accelerate. We can't thank you all enough for your help and support! :rocket:
[![Star History Chart](https://api.star-history.com/svg?repos=go-task/task&type=Date)](https://star-history.com/#go-task/task&Date)
## What's next? :thinking_face:
It's extremely motivating to see so many people using and loving Task. However, in this time we've also seen an increase in the number of issues and feature requests. In particular, issues that require some kind of breaking change to Task. This isn't a bad thing, but as we grow we need to be more responsible about how we address these changes in a way that ensures stability and compatibility for existing users and their Taskfiles.
At this point you're probably thinking something like:
> "But you use [semantic versioning][semver] - Just release a new major version with your breaking changes."
And you'd be right... sort of. In theory, this sounds great, but the reality is that we don't have the time to commit to a major overhaul of Task in one big bang release. This would require a colossal amount of time and coordination and with full time jobs and personal lives to tend to, this is a difficult commitment to make. Smaller, more frequent major releases are also a significant inconvenience for users as they have to constantly keep up-to-date with our breaking changes. Fortunately, there is a better way.
## What's going to change? :face_with_monocle:
Going forwards, breaking changes will be allowed into _minor_ versions of Task as "experimental features". To access these features users will need opt-in by enabling feature flags. This will allow us to release new features slowly and gather feedback from the community before making them the default behavior in a future major release.
To prepare users for the next major release, we will maintain a list of [deprecated features][deprecations] and [experiments][experiments] on our docs website and publish information on how to migrate to the new behavior.
You can read the [full breaking change proposal][breaking-change-proposal] and view all the [current experiments and their status][experiments-project] on GitHub including the [Gentle Force][gentle-force-experiment] and [Remote Taskfiles][remote-taskfiles-experiment] experiments.
## What will happen to v2/v3 features?
v2 has been [officially deprecated][deprecate-version-2-schema]. If you're still using a Taskfile with `version: "2"` at the top we _strongly recommend_ that you upgrade as soon as possible. Removing v2 will allow us to tidy up the codebase and focus on new functionality instead.
When v4 is released, we will continue to support v3 for a period of time (bug fixes etc). However, since we are moving from a backward-compatibility model to a forwards-compatibility model, **v4 itself will not be backwards compatible with v3**.
## v4 When? :eyes:
:shrug: When it's ready.
In all seriousness, we don't have a timeline for this yet. We'll be working on the most serious deficiencies of the v3 API first and regularly evaluating the state of the project. When we feel its in a good, stable place and we have a clear upgrade path for users and a number of stable experiments, we'll start to think about v4.
## :wave: Final thoughts
Task is growing fast and we're excited to see where it goes next. We hope that the steps we're taking to improve the project and our process will help us to continue to grow. As always, if you have any questions or feedback, we encourage you to comment on or open [issues][issues] and [discussions][discussions] on GitHub. Alternatively, you can join us on [Discord][discord].
I plan to write more of these blog posts in the future on a variety of Task-related topics, so make sure to check in occasionally and see what we're up to!
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[vscode-task]: https://github.com/go-task/vscode-task
[crowdin]: https://crowdin.com
[contributors]: https://github.com/go-task/task/graphs/contributors
[semver]: https://semver.org
[breaking-change-proposal]: https://github.com/go-task/task/discussions/1191
[@andreynering]: https://github.com/andreynering
[@pd93]: https://github.com/pd93
[experiments]: https://taskfile.dev/experiments
[deprecations]: https://taskfile.dev/deprecations
[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
[issues]: https://github.com/go-task/task/issues
[discussions]: https://github.com/go-task/task/discussions
[discord]: https://discord.gg/6TY36E39UK
[experiments-project]: https://github.com/orgs/go-task/projects/1
[gentle-force-experiment]: https://github.com/go-task/task/issues/1200
[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317

View File

@@ -3,3 +3,8 @@ andreynering:
title: Mainteneur de Task
url: https://github.com/andreynering
image_url: https://github.com/andreynering.png
pd93:
name: Pete Davison
title: Maintainer of Task
url: https://github.com/pd93
image_url: https://github.com/pd93.png

View File

@@ -17,7 +17,7 @@ task [--flags] [tasks...] [-- CLI_ARGS...]
:::tip
Si `--` est renseigné, tous les arguments suivants seront assigné à la variable spéciale `CLI_ARGS`
If `--` is given, all remaining arguments will be assigned to a special `CLI_ARGS` variable
:::
@@ -74,6 +74,7 @@ A full list of the exit codes and their descriptions can be found below:
| 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 |
| 206 | A task was not executed due to missing required variables |
These codes can also be found in the repository in [`errors/errors.go`](https://github.com/go-task/task/blob/main/errors/errors.go).
@@ -119,12 +120,13 @@ There are some special variables that is available on the templating system:
| `TASKFILE_DIR` | The absolute path of the included Taskfile. |
| `USER_WORKING_DIR` | The absolute path of the directory `task` was called from. |
| `CHECKSUM` | The checksum of the files listed in `sources`. Only available within the `status` prop and if method is set to `checksum`. |
| `TIMESTAMP` | The date object of the greatest timestamp of the files listes in `sources`. Only available within the `status` prop and if method is set to `timestamp`. |
| `TIMESTAMP` | The date object of the greatest timestamp of the files listed in `sources`. Only available within the `status` prop and if method is set to `timestamp`. |
| `TASK_VERSION` | The current version of task. |
| `ITEM` | The value of the current iteration when using the `for` property. Can be changed to a different variable name using `as:`. |
## ENV
Some environment variables can be overriden to adjust Task behavior.
Some environment variables can be overridden to adjust Task behavior.
| ENV | Default | Description |
| -------------------- | ------- | ----------------------------------------------------------------------------------------------------------------- |
@@ -144,12 +146,12 @@ Some environment variables can be overriden to adjust Task behavior.
| ---------- | ---------------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `version` | `string` | | Version of the Taskfile. The current version is `3`. |
| `output` | `string` | `interleaved` | Output mode. Available options: `interleaved`, `group` and `prefixed`. |
| `method` | `string` | `checksum` | Default method in this Taskfile. Can be overriden in a task by task basis. Available options: `checksum`, `timestamp` and `none`. |
| `method` | `string` | `checksum` | Default method in this Taskfile. Can be overridden in a task by task basis. Available options: `checksum`, `timestamp` and `none`. |
| `includes` | [`map[string]Include`](#include) | | Additional Taskfiles to be included. |
| `vars` | [`map[string]Variable`](#variable) | | A set of global variables. |
| `env` | [`map[string]Variable`](#variable) | | A set of global environment variables. |
| `tasks` | [`map[string]Task`](#task) | | A set of task definitions. |
| `silent` | `bool` | `false` | Default 'silent' options for this Taskfile. If `false`, can be overidden with `true` in a task by task basis. |
| `silent` | `bool` | `false` | Default 'silent' options for this Taskfile. If `false`, can be overridden with `true` in a task by task basis. |
| `dotenv` | `[]string` | | A list of `.env` file paths to be parsed. |
| `run` | `string` | `always` | Default 'run' option for this Taskfile. Available options: `always`, `once` and `when_changed`. |
| `interval` | `string` | `5s` | Sets a different watch interval when using `--watch`, the default being 5 seconds. This string should be a valid [Go Duration](https://pkg.go.dev/time#ParseDuration). |
@@ -212,7 +214,9 @@ vars:
| `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. |
| `generates` | `[]string` | | A list of files meant to be generated by this task. Relevant for `timestamp` method. Can be file paths or star globs. |
| `status` | `[]string` | | A list of commands to check if this task should run. The task is skipped otherwise. This overrides `method`, `sources` and `generates`. |
| `requires` | `[]string` | | A list of variables which should be set if this task is to run, if any of these variables are unset the task will error and not run. |
| `preconditions` | [`[]Precondition`](#precondition) | | A list of commands to check if this task should run. If a condition is not met, the task will error. |
| `requires` | [`Requires`](#requires) | | A list of required variables which should be set if this task is to run, if any variables listed are unset the task will error and not run. |
| `dir` | `string` | | The directory in which this task should run. Defaults to the current working directory. |
| `vars` | [`map[string]Variable`](#variable) | | A set of variables that can be used in the task. |
| `env` | [`map[string]Variable`](#variable) | | A set of environment variables that will be made available to shell commands. |
@@ -251,8 +255,9 @@ tasks:
| Attribute | Type | Default | Description |
| -------------- | ---------------------------------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `cmd` | `string` | | The shell command to be executed. |
| `silent` | `bool` | `false` | Skips some output for this command. Note that STDOUT and STDERR of the commands will still be redirected. |
| `task` | `string` | | Set this to trigger execution of another task instead of running a command. This cannot be set together with `cmd`. |
| `for` | [`For`](#for) | | Runs the command once for each given value. |
| `silent` | `bool` | `false` | Skips some output for this command. Note that STDOUT and STDERR of the commands will still be redirected. |
| `vars` | [`map[string]Variable`](#variable) | | Optional additional variables to be passed to the referenced task. Only relevant when setting `task` instead of `cmd`. |
| `ignore_error` | `bool` | `false` | Continue execution if errors happen while executing the command. |
| `defer` | `string` | | Alternative to `cmd`, but schedules the command to be executed at the end of this task instead of immediately. This cannot be used together with `cmd`. |
@@ -294,6 +299,22 @@ tasks:
:::
#### For
The `for` parameter can be defined as a string, a list of strings or a map. If it is defined as a string, you can give it any of the following values:
- `source` - Will run the command for each source file defined on the task. (Glob patterns will be resolved, so `*.go` will run for every Go file that matches).
If it is defined as a list of strings, the command will be run for each value.
Finally, the `for` parameter can be defined as a map when you want to use a variable to define the values to loop over:
| Attribute | Type | Default | Description |
| --------- | -------- | ---------------- | -------------------------------------------- |
| `var` | `string` | | The name of the variable to use as an input. |
| `split` | `string` | (any whitespace) | What string the variable should be split on. |
| `as` | `string` | `ITEM` | The name of the iterator variable. |
#### Precondition
| Attribute | Type | Default | Description |
@@ -312,3 +333,9 @@ tasks:
```
:::
#### Requires
| Attribute | Type | Default | Description |
| --------- | ---------- | ------- | -------------------------------------------------------------------------------------------------- |
| `vars` | `[]string` | | List of variable or environment variable names that must be set if this task is to execute and run |

View File

@@ -1,10 +1,38 @@
---
slug: /changelog/
sidebar_position: 9
sidebar_position: 14
---
# Changelog
## v3.29.1 - 2023-08-26
- Update to Go 1.21 (bump minimum version to 1.20) ([#1302](https://github.com/go-task/task/issues/1302) by [@pd93](https://github.com/pd93))
- Fix a missing a line break on log when using `--watch` mode ([#1285](https://github.com/go-task/task/issues/1285), [#1297](https://github.com/go-task/task/issues/1297) by [@FilipSolich](https://github.com/FilipSolich)).
- Fix `defer` on JSON Schema ([#1288](https://github.com/go-task/task/issues/1288) by [@calvinmclean](https://github.com/calvinmclean) and [@andreynering](https://github.com/andreynering)).
- Fix bug in usage of special variables like `{{.USER_WORKING_DIR}}` in combination with `includes` ([#1046](https://github.com/go-task/task/issues/1046), [#1205](https://github.com/go-task/task/issues/1205), [#1250](https://github.com/go-task/task/issues/1250), [#1293](https://github.com/go-task/task/issues/1293), [#1312](https://github.com/go-task/task/issues/1312), [#1274](https://github.com/go-task/task/issues/1274) by [@andarto](https://github.com/andarto), [#1309](https://github.com/go-task/task/issues/1309) by [@andreynering](https://github.com/andreynering)).
- Fix bug on `--status` flag. Running this flag should not have side-effects: it should not update the checksum on `.task`, only report its status ([#1305](https://github.com/go-task/task/issues/1305), [#1307](https://github.com/go-task/task/issues/1307) by [@visciang](https://github.com/visciang), [#1313](https://github.com/go-task/task/issues/1313) by [@andreynering](https://github.com/andreynering)).
## v3.28.0 - 2023-07-24
- Added the ability to [loop over commands and tasks](https://taskfile.dev/usage/#looping-over-values) using `for` ([#82](https://github.com/go-task/task/issues/82), [#1220](https://github.com/go-task/task/issues/1220) by [@pd93](https://github.com/pd93)).
- Fixed variable propagation in multi-level includes ([#778](https://github.com/go-task/task/issues/778), [#996](https://github.com/go-task/task/issues/996), [#1256](https://github.com/go-task/task/issues/1256) by [@hudclark](https://github.com/hudclark)).
- Fixed a bug where the `--exit-code` code flag was not returning the correct exit code when calling commands indirectly ([#1266](https://github.com/go-task/task/issues/1266), [#1270](https://github.com/go-task/task/issues/1270) by [@pd93](https://github.com/pd93)).
- Fixed a `nil` panic when a dependency was commented out or left empty ([#1263](https://github.com/go-task/task/issues/1263) by [@neomantra](https://github.com/neomantra)).
## v3.27.1 - 2023-06-30
- Fix panic when a `.env` directory (not file) is present on current directory ([#1244](https://github.com/go-task/task/issues/1244), [#1245](https://github.com/go-task/task/issues/1245) by [@pd93](https://github.com/pd93)).
## v3.27.0 - 2023-06-29
- Allow Taskfiles starting with lowercase characters ([#947](https://github.com/go-task/task/issues/947), [#1221](https://github.com/go-task/task/issues/1221) by [@pd93](https://github.com/pd93)).
- e.g. `taskfile.yml`, `taskfile.yaml`, `taskfile.dist.yml` & `taskfile.dist.yaml`
- Bug fixes were made to the [npm installation method](https://taskfile.dev/installation/#npm). ([#1190](https://github.com/go-task/task/issues/1190), by [@sounisi5011](https://github.com/sounisi5011)).
- Added the [gentle force experiment](https://taskfile.dev/experiments) as a draft ([#1200](https://github.com/go-task/task/issues/1200), [#1216](https://github.com/go-task/task/issues/1216) by [@pd93](https://github.com/pd93)).
- Added an `--experiments` flag to allow you to see which experiments are enabled ([#1242](https://github.com/go-task/task/issues/1242) by [@pd93](https://github.com/pd93)).
- Added ability to specify which variables are required in a task ([#1203](https://github.com/go-task/task/issues/1203), [#1204](https://github.com/go-task/task/issues/1204) by [@benc](https://github.com/benc)-uk).
## v3.26.0 - 2023-06-10
- Only rewrite checksum files in `.task` if the checksum has changed ([#1185](https://github.com/go-task/task/issues/1185), [#1194](https://github.com/go-task/task/issues/1194) by [@deviantintegral](https://github.com/deviantintegral)).

View File

@@ -1,6 +1,6 @@
---
slug: /community/
sidebar_position: 10
sidebar_position: 9
---
# Communauté

View File

@@ -0,0 +1,12 @@
---
slug: /deprecations/
sidebar_position: 7
---
# Deprecations
As Task evolves, it occasionally outgrows some of its functionality. This can be because they are no longer useful, because another feature has replaced it or because of a change in the way that Task works internally.
When this happens, we mark the functionality as deprecated. This means that it will be removed in a future version of Task. This functionality will continue to work until that time, but we strongly recommend that you do not implement this functionality in new Taskfiles and make a plan to migrate away from it as soon as possible.
You can view a full list of active deprecations in the "Deprecations" section of the sidebar.

View File

@@ -0,0 +1,17 @@
---
#This is a template for an experiments documentation
#Copy this page and fill in the details as necessary
title: '--- Template ---'
sidebar_position: -1 #Always push to the top
draft: true #Hide in production
---
# {Name of Deprecated Feature}
- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
- Breaks:
- {list any existing functionality that will be broken by this experiment}
{Short description of the feature/behavior and why it is being deprecated}
{Short explanation of any replacement features/behaviors and how users should migrate to it}

View File

@@ -0,0 +1,22 @@
---
slug: /deprecations/version-2-schema/
---
# Version 2 Schema
- Issue: [#1197][deprecate-version-2-schema]
- Breaks:
- Any Taskfiles that use the version 2 schema
- `Taskvar.yml` files
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

View File

@@ -1,6 +1,6 @@
---
slug: /donate/
sidebar_position: 15
sidebar_position: 16
---
# Faire un don

View File

@@ -1,6 +1,6 @@
---
slug: /experiments/
sidebar_position: 5
sidebar_position: 6
---
# Experiments
@@ -11,7 +11,9 @@ All experimental features are subject to breaking changes and/or removal _at any
:::
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.
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 their status in the [workflow](#workflow).
You can view a full list of active experiments in the "Experiments" section of the sidebar.
You can enable an experimental feature by:
@@ -28,43 +30,49 @@ TASK_X_FEATURE=1
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...
## Workflow
### ![experiment] {Feature} ([#{issue}](https://github.com/go-task/task/issues/{issue})), ...)
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.
- Environment variable: `TASK_X_{feature}`
- Deprecates: {list any existing functionality that will be deprecated by this experiment}
- Breaks: {list any existing functionality that will be broken by this experiment}
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.
{Short description of the feature}
### 1. Proposal
{Short explanation of how users should migrate to the new behavior}
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
### ![deprecated][] Version 2 Schema ([#1197][deprecate-version-2-schema])
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.
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.
:::note
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.
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_.
A list of changes between version 2 and version 3 are available in the [Task v3 Release Notes][version-3-release-notes].
:::
### ![experiment][] Gentle Force ([#1200](https://github.com/go-task/task/issues/1200))
### 3. Candidate
- Environment variable: `TASK_X_FORCE=1`
- Breaks: `--force` flag
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.
The `--force` flag currently forces _all_ tasks to run regardless of the status checks. This can be useful, but we have found that most of the time users only expect the direct task they are calling to be forced and _not_ all of its dependant tasks.
### 4. Stable
This experiment changes the `--force` flag to only force the directly called task. All dependant tasks will have their statuses checked as normal and will only run if Task considers them to be out of date. A new `--force-all` flag will also be added to maintain the current behavior for users that need this functionality.
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.
If you want to migrate, but continue to force all dependant tasks to run, you should replace all uses of the `--force` flag with `--force-all`. Alternatively, if you want to adopt the new behavior, you can continue to use the `--force` flag as you do now!
### 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 -->
[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
[experiment]: https://img.shields.io/badge/experiment-yellow
[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

View File

@@ -0,0 +1,21 @@
---
slug: /experiments/gentle-force/
---
# Gentle Force
- Issue: [#1200][gentle-force-experiment]
- Environment variable: `TASK_X_FORCE=1`
- Breaks:
- `--force` flag
The `--force` flag currently forces _all_ tasks to run regardless of the status checks. This can be useful, but we have found that most of the time users only expect the direct task they are calling to be forced and _not_ all of its dependant tasks.
This experiment changes the `--force` flag to only force the directly called task. All dependant tasks will have their statuses checked as normal and will only run if Task considers them to be out of date. A new `--force-all` flag will also be added to maintain the current behavior for users that need this functionality.
If you want to migrate, but continue to force all dependant tasks to run, you should replace all uses of the `--force` flag with `--force-all`. Alternatively, if you want to adopt the new behavior, you can continue to use the `--force` flag as you do now!
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[gentle-force-experiment]: https://github.com/go-task/task/issues/1200

View File

@@ -0,0 +1,54 @@
---
slug: /experiments/remote-taskfiles/
---
# Remote Taskfiles
- Issue: [#1317][remote-taskfiles-experiment]
- Environment variable: `TASK_X_REMOTE_TASKFILES=1`
This experiment allows you to specify a remote Taskfile URL when including a Taskfile. For example:
```yaml
version: '3'
include:
my-remote-namespace: https://raw.githubusercontent.com/my-org/my-repo/main/Taskfile.yml
```
This works exactly the same way that including a local file does. Any tasks in the remote Taskfile will be available to run from your main Taskfile via the namespace `my-remote-namespace`. For example, if the remote file contains the following:
```yaml
version: '3'
tasks:
hello:
silent: true
cmds:
- echo "Hello from the remote Taskfile!"
```
and you run `task my-remote-namespace:hello`, it will print the text: "Hello from the remote Taskfile!" to your console.
## Security
Running commands from sources that you do not control is always a potential security risk. For this reason, we have added some checks when using remote Taskfiles:
1. When running a task from a remote Taskfile for the first time, Task will print a warning to the console asking you to check that you are sure that you trust the source of the Taskfile. If you do not accept the prompt, then Task will exit with code `104` (not trusted) and nothing will run. If you accept the prompt, the remote Taskfile will run and further calls to the remote Taskfile will not prompt you again.
2. Whenever you run a remote Taskfile, Task will create and store a checksum of the file that you are running. If the checksum changes, then Task will print another warning to the console to inform you that the contents of the remote file has changed. If you do not accept the prompt, then Task will exit with code `104` (not trusted) and nothing will run. If you accept the prompt, the checksum will be updated and the remote Taskfile will run.
Task currently supports both `http` and `https` URLs. However, the `http` requests will not execute by default unless you run the task with the `--insecure` flag. This is to protect you from accidentally running a remote Taskfile that is hosted on and unencrypted connection. Sources that are not protected by TLS are vulnerable to [man-in-the-middle attacks][man-in-the-middle-attacks] and should be avoided unless you know what you are doing.
## Caching & Running Offline
If for whatever reason, you don't have access to the internet, but you still need to be able to run your tasks, you are able to use the `--download` flag to store a cached copy of the remote Taskfile.
<!-- TODO: The following behavior may change -->
If Task detects that you have a local copy of the remote Taskfile, it will use your local copy instead of downloading the remote file. You can force Task to work offline by using the `--offline` flag. This will prevent Task from making any calls to remote sources.
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317
[man-in-the-middle-attacks]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack

View File

@@ -0,0 +1,20 @@
---
#This is a template for an experiments documentation
#Copy this page and fill in the details as necessary
title: '--- Template ---'
sidebar_position: -1 #Always push to the top
draft: true #Hide in production
---
# {Name of Experiment}
- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
- Environment variable: `TASK_X_{feature}`
- Breaks:
- {list any existing functionality that will be broken by this experiment}
- Deprecations:
- {link to any deprecation pages related to this experiment}
{Short description of the feature}
{Short explanation of how users should migrate to the new behavior}

View File

@@ -1,6 +1,6 @@
---
slug: /faq/
sidebar_position: 7
sidebar_position: 15
---
# FAQ

View File

@@ -25,6 +25,21 @@ Recently, Task was also made available [on the official Homebrew repository](htt
brew install go-task
```
### Tea
If you're on macOS or Linux and have [tea][tea] installed, getting Task is as simple as running:
```bash
tea task
```
or, if you have teas magic enabled:
```bash
task
```
This installation method is community owned. After a new release of Task, they are automatically released by tea in a minimum of time.
### Snap
Task is available in [Snapcraft][snapcraft], but keep in mind that your Linux distribution should allow classic confinement for Snaps to Task work right:
@@ -248,3 +263,4 @@ Invoke-Expression -Command path/to/task.ps1
[godownloader]: https://github.com/goreleaser/godownloader
[choco]: https://chocolatey.org/
[scoop]: https://scoop.sh/
[tea]: https://tea.xyz/

View File

@@ -1,6 +1,6 @@
---
slug: /integrations/
sidebar_position: 6
sidebar_position: 8
---
# Integrations

View File

@@ -26,6 +26,10 @@ The [snap package][snappackage] requires to manual steps to release a new versio
- Updating the current version on [snapcraft.yaml][snapcraftyaml].
- Moving both `amd64`, `armhf` and `arm64` new artifacts to the stable channel on the [Snapcraft dashboard][snapcraftdashboard].
# winget
winget also requires manual steps to be completed. By running `task test-release` locally, manifest files will be generated on `dist/winget/manifests/t/Task/Task/v{version}`. [Upload the manifest directory into this fork](https://github.com/go-task/winget-pkgs/tree/master/manifests/t/Task/Task) and open a pull request into [this repository](https://github.com/microsoft/winget-pkgs).
# Scoop
Scoop is a command-line package manager for the Windows operating system. Scoop package manifests are maintained by the community. Scoop owners usually take care of updating versions there by editing [this file](https://github.com/ScoopInstaller/Main/blob/master/bucket/task.json). If you think its Task version is outdated, open an issue to let us know.

View File

@@ -1,6 +1,6 @@
---
slug: /styleguide/
sidebar_position: 8
sidebar_position: 10
---
# Guide de style

View File

@@ -1,6 +1,6 @@
---
slug: /taskfile-versions/
sidebar_position: 14
sidebar_position: 5
---
# Taskfile Versions
@@ -21,7 +21,7 @@ These are some major changes done on `v3`:
- 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:`
- Two magic variables were added when using `status:`: `CHECKSUM` and `TIMESTAMP` which contains, respectively, the XXH3 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:

View File

@@ -753,6 +753,42 @@ tasks:
- sleep 5 # long operation like installing packages
```
### Ensuring required variables are set
If you want to check that certain variables are set before running a task then you can use `requires`. This is useful when might not be clear to users which variables are needed, or if you want clear message about what is required. Also some tasks could have dangerous side effects if run with un-set variables.
Using `requires` you specify an array of strings in the `vars` sub-section under `requires`, these strings are variable names which are checked prior to running the task. If any variables are un-set the the task will error and not run.
Environmental variables are also checked.
Syntax:
```yaml
requires:
vars: [] # Array of strings
```
:::note
Variables set to empty zero length strings, will pass the `requires` check.
:::
Example of using `requires`:
```yaml
version: '3'
tasks:
docker-build:
cmds:
- 'docker build . -t {{.IMAGE_NAME}}:{{.IMAGE_TAG}}'
# Make sure these variables are set before running
requires:
vars: [IMAGE_NAME, IMAGE_TAG]
```
## Variables
When doing interpolation of variables, Task will look for the below. They are listed below in order of importance (i.e. most important first):
@@ -827,6 +863,162 @@ tasks:
This works for all types of variables.
## Looping over values
As of v3.28.0, Task allows you to loop over certain values and execute a command for each. There are a number of ways to do this depending on the type of value you want to loop over.
### Looping over a static list
The simplest kind of loop is an explicit one. This is useful when you want to loop over a set of values that are known ahead of time.
```yaml
version: '3'
tasks:
default:
cmds:
- for: ['foo.txt', 'bar.txt']
cmd: cat {{ .ITEM }}
```
### Looping over your task's sources
You are also able to loop over the sources of your task:
```yaml
version: '3'
tasks:
default:
sources:
- foo.txt
- bar.txt
cmds:
- for: sources
cmd: cat {{ .ITEM }}
```
This will also work if you use globbing syntax in your sources. For example, if you specify a source for `*.txt`, the loop will iterate over all files that match that glob.
Source paths will always be returned as paths relative to the task directory. If you need to convert this to an absolute path, you can use the built-in `joinPath` function. There are some [special variables](/api/#special-variables) that you may find useful for this.
```yaml
version: '3'
tasks:
default:
vars:
MY_DIR: /path/to/dir
dir: '{{.MY_DIR}}'
sources:
- foo.txt
- bar.txt
cmds:
- for: sources
cmd: cat {{joinPath .MY_DIR .ITEM}}
```
### Looping over variables
To loop over the contents of a variable, you simply need to specify the variable you want to loop over. By default, variables will be split on any whitespace characters.
```yaml
version: '3'
tasks:
default:
vars:
MY_VAR: foo.txt bar.txt
cmds:
- for: { var: MY_VAR }
cmd: cat {{.ITEM}}
```
If you need to split on a different character, you can do this by specifying the `split` property:
```yaml
version: '3'
tasks:
default:
vars:
MY_VAR: foo.txt,bar.txt
cmds:
- for: { var: MY_VAR, split: ',' }
cmd: cat {{.ITEM}}
```
All of this also works with dynamic variables!
```yaml
version: '3'
tasks:
default:
vars:
MY_VAR:
sh: find -type f -name '*.txt'
cmds:
- for: { var: MY_VAR }
cmd: cat {{.ITEM}}
```
### Renaming variables
If you want to rename the iterator variable to make it clearer what the value contains, you can do so by specifying the `as` property:
```yaml
version: '3'
tasks:
default:
vars:
MY_VAR: foo.txt bar.txt
cmds:
- for: { var: MY_VAR, as: FILE }
cmd: cat {{.FILE}}
```
### Looping over tasks
Because the `for` property is defined at the `cmds` level, you can also use it alongside the `task` keyword to run tasks multiple times with different variables.
```yaml
version: '3'
tasks:
default:
cmds:
- for: [foo, bar]
task: my-task
vars:
FILE: '{{.ITEM}}'
my-task:
cmds:
- echo '{{.FILE}}'
```
Or if you want to run different tasks depending on the value of the loop:
```yaml
version: '3'
tasks:
default:
cmds:
- for: [foo, bar]
task: task-{{.ITEM}}
task-foo:
cmds:
- echo 'foo'
task-bar:
cmds:
- echo 'bar'
```
## Forwarding CLI arguments to commands
If `--` is given in the CLI, all following parameters are added to a special `.CLI_ARGS` variable. This is useful to forward arguments to another command.
@@ -901,10 +1093,10 @@ tasks:
Task also adds the following functions:
- `OS`: Returns the operating system. Possible values are "windows", "linux", "darwin" (macOS) and "freebsd".
- `ARCH`: return the architecture Task was compiled to: "386", "amd64", "arm" or "s390x".
- `splitLines`: Splits Unix (\n) and Windows (\r\n) styled newlines.
- `catLines`: Replaces Unix (\n) and Windows (\r\n) styled newlines with a space.
- `OS`: Returns the operating system. Possible values are `windows`, `linux`, `darwin` (macOS) and `freebsd`.
- `ARCH`: return the architecture Task was compiled to: `386`, `amd64`, `arm` or `s390x`.
- `splitLines`: Splits Unix (`\n`) and Windows (`\r\n`) styled newlines.
- `catLines`: Replaces Unix (`\n`) and Windows (`\r\n`) styled newlines with a space.
- `toSlash`: Does nothing on Unix, but on Windows converts a string from `\` path format to `/`.
- `fromSlash`: Opposite of `toSlash`. Does nothing on Unix, but on Windows converts a string from `/` path format to `\`.
- `exeExt`: Returns the right executable extension for the current OS (`".exe"` for Windows, `""` for others).
@@ -1059,7 +1251,7 @@ tasks:
## Warning Prompts
Warning Prompts to prompt a user for confirmation before a task is executed.
Warning Prompts are used 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:
@@ -1107,7 +1299,7 @@ To skip warning prompts automatically, you can use the `--yes` (alias `-y`) opti
:::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.
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 those cases, use `--yes` (`-y`) to force all tasks with a prompt to run.
:::

396
docs/i18n/ja-JP/code.json Normal file
View File

@@ -0,0 +1,396 @@
{
"theme.ErrorPageContent.title": {
"message": "ページがクラッシュしました。",
"description": "The title of the fallback page when the page crashed"
},
"theme.ErrorPageContent.tryAgain": {
"message": "もう一度お試しください",
"description": "The label of the button to try again when the page crashed"
},
"theme.NotFound.title": {
"message": "ページが見つかりませんでした",
"description": "The title of the 404 page"
},
"theme.NotFound.p1": {
"message": "お探しのページが見つかりませんでした。",
"description": "The first paragraph of the 404 page"
},
"theme.NotFound.p2": {
"message": "アクセスを試みたのURLをリンクしたサイトの管理者に連絡して、そのリンクが壊れていることを知らせてください。",
"description": "The 2nd paragraph of the 404 page"
},
"theme.admonition.note": {
"message": "メモ",
"description": "The default label used for the Note admonition (:::note)"
},
"theme.admonition.tip": {
"message": "ヒント",
"description": "The default label used for the Tip admonition (:::tip)"
},
"theme.admonition.danger": {
"message": "危険",
"description": "The default label used for the Danger admonition (:::danger)"
},
"theme.admonition.info": {
"message": "お知らせ",
"description": "The default label used for the Info admonition (:::info)"
},
"theme.admonition.caution": {
"message": "注意",
"description": "The default label used for the Caution admonition (:::caution)"
},
"theme.BackToTopButton.buttonAriaLabel": {
"message": "ページ上部へ戻る",
"description": "The ARIA label for the back to top button"
},
"theme.blog.archive.title": {
"message": "アーカイブ",
"description": "The page & hero title of the blog archive page"
},
"theme.blog.archive.description": {
"message": "アーカイブ",
"description": "The page & hero description of the blog archive page"
},
"theme.blog.paginator.navAriaLabel": {
"message": "Blog list page navigation",
"description": "The ARIA label for the blog pagination"
},
"theme.blog.paginator.newerEntries": {
"message": "Newer Entries",
"description": "The label used to navigate to the newer blog posts page (previous page)"
},
"theme.blog.paginator.olderEntries": {
"message": "Older Entries",
"description": "The label used to navigate to the older blog posts page (next page)"
},
"theme.blog.post.paginator.navAriaLabel": {
"message": "Blog post page navigation",
"description": "The ARIA label for the blog posts pagination"
},
"theme.blog.post.paginator.newerPost": {
"message": "Newer Post",
"description": "The blog post button label to navigate to the newer/previous post"
},
"theme.blog.post.paginator.olderPost": {
"message": "Older Post",
"description": "The blog post button label to navigate to the older/next post"
},
"theme.blog.post.plurals": {
"message": "One post|{count} posts",
"description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
},
"theme.blog.tagTitle": {
"message": "{nPosts} tagged with \"{tagName}\"",
"description": "The title of the page for a blog tag"
},
"theme.tags.tagsPageLink": {
"message": "View All Tags",
"description": "The label of the link targeting the tag list page"
},
"theme.colorToggle.ariaLabel": {
"message": "Switch between dark and light mode (currently {mode})",
"description": "The ARIA label for the navbar color mode toggle"
},
"theme.colorToggle.ariaLabel.mode.dark": {
"message": "dark mode",
"description": "The name for the dark color mode"
},
"theme.colorToggle.ariaLabel.mode.light": {
"message": "light mode",
"description": "The name for the light color mode"
},
"theme.docs.breadcrumbs.home": {
"message": "Home page",
"description": "The ARIA label for the home page in the breadcrumbs"
},
"theme.docs.breadcrumbs.navAriaLabel": {
"message": "Breadcrumbs",
"description": "The ARIA label for the breadcrumbs"
},
"theme.docs.DocCard.categoryDescription": {
"message": "{count} items",
"description": "The default description for a category card in the generated index about how many items this category includes"
},
"theme.docs.paginator.navAriaLabel": {
"message": "Docs pages navigation",
"description": "The ARIA label for the docs pagination"
},
"theme.docs.paginator.previous": {
"message": "Previous",
"description": "The label used to navigate to the previous doc"
},
"theme.docs.paginator.next": {
"message": "Next",
"description": "The label used to navigate to the next doc"
},
"theme.docs.tagDocListPageTitle.nDocsTagged": {
"message": "One doc tagged|{count} docs tagged",
"description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
},
"theme.docs.tagDocListPageTitle": {
"message": "{nDocsTagged} with \"{tagName}\"",
"description": "The title of the page for a docs tag"
},
"theme.docs.versionBadge.label": {
"message": "Version: {versionLabel}"
},
"theme.docs.versions.unreleasedVersionLabel": {
"message": "This is unreleased documentation for {siteTitle} {versionLabel} version.",
"description": "The label used to tell the user that he's browsing an unreleased doc version"
},
"theme.docs.versions.unmaintainedVersionLabel": {
"message": "This is documentation for {siteTitle} {versionLabel}, which is no longer actively maintained.",
"description": "The label used to tell the user that he's browsing an unmaintained doc version"
},
"theme.docs.versions.latestVersionSuggestionLabel": {
"message": "For up-to-date documentation, see the {latestVersionLink} ({versionLabel}).",
"description": "The label used to tell the user to check the latest version"
},
"theme.docs.versions.latestVersionLinkLabel": {
"message": "latest version",
"description": "The label used for the latest version suggestion link label"
},
"theme.common.editThisPage": {
"message": "Edit this page",
"description": "The link label to edit the current page"
},
"theme.common.headingLinkTitle": {
"message": "Direct link to heading",
"description": "Title for link to heading"
},
"theme.lastUpdated.atDate": {
"message": " on {date}",
"description": "The words used to describe on which date a page has been last updated"
},
"theme.lastUpdated.byUser": {
"message": " by {user}",
"description": "The words used to describe by who the page has been last updated"
},
"theme.lastUpdated.lastUpdatedAtBy": {
"message": "Last updated{atDate}{byUser}",
"description": "The sentence used to display when a page has been last updated, and by who"
},
"theme.navbar.mobileVersionsDropdown.label": {
"message": "Versions",
"description": "The label for the navbar versions dropdown on mobile view"
},
"theme.tags.tagsListLabel": {
"message": "Tags:",
"description": "The label alongside a tag list"
},
"theme.AnnouncementBar.closeButtonAriaLabel": {
"message": "Close",
"description": "The ARIA label for close button of announcement bar"
},
"theme.blog.sidebar.navAriaLabel": {
"message": "Blog recent posts navigation",
"description": "The ARIA label for recent posts in the blog sidebar"
},
"theme.CodeBlock.copied": {
"message": "Copied",
"description": "The copied button label on code blocks"
},
"theme.CodeBlock.copyButtonAriaLabel": {
"message": "Copy code to clipboard",
"description": "The ARIA label for copy code blocks button"
},
"theme.CodeBlock.copy": {
"message": "コピー",
"description": "The copy button label on code blocks"
},
"theme.CodeBlock.wordWrapToggle": {
"message": "Toggle word wrap",
"description": "The title attribute for toggle word wrapping button of code block lines"
},
"theme.DocSidebarItem.toggleCollapsedCategoryAriaLabel": {
"message": "Toggle the collapsible sidebar category '{label}'",
"description": "The ARIA label to toggle the collapsible sidebar category"
},
"theme.navbar.mobileLanguageDropdown.label": {
"message": "Languages",
"description": "The label for the mobile language switcher dropdown"
},
"theme.TOCCollapsible.toggleButtonLabel": {
"message": "On this page",
"description": "The label used by the button on the collapsible TOC component"
},
"theme.blog.post.readMore": {
"message": "Read More",
"description": "The label used in blog post item excerpts to link to full blog posts"
},
"theme.blog.post.readMoreLabel": {
"message": "Read more about {title}",
"description": "The ARIA label for the link to full blog posts from excerpts"
},
"theme.blog.post.readingTime.plurals": {
"message": "One min read|{readingTime} min read",
"description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
},
"theme.docs.sidebar.collapseButtonTitle": {
"message": "Collapse sidebar",
"description": "The title attribute for collapse button of doc sidebar"
},
"theme.docs.sidebar.collapseButtonAriaLabel": {
"message": "Collapse sidebar",
"description": "The title attribute for collapse button of doc sidebar"
},
"theme.docs.sidebar.closeSidebarButtonAriaLabel": {
"message": "Close navigation bar",
"description": "The ARIA label for close button of mobile sidebar"
},
"theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": {
"message": "← Back to main menu",
"description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)"
},
"theme.docs.sidebar.toggleSidebarButtonAriaLabel": {
"message": "Toggle navigation bar",
"description": "The ARIA label for hamburger menu button of mobile navigation"
},
"theme.docs.sidebar.expandButtonTitle": {
"message": "Expand sidebar",
"description": "The ARIA label and title attribute for expand button of doc sidebar"
},
"theme.docs.sidebar.expandButtonAriaLabel": {
"message": "Expand sidebar",
"description": "The ARIA label and title attribute for expand button of doc sidebar"
},
"theme.SearchBar.seeAll": {
"message": "See all {count} results"
},
"theme.SearchPage.documentsFound.plurals": {
"message": "One document found|{count} documents found",
"description": "Pluralized label for \"{count} documents found\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
},
"theme.SearchPage.existingResultsTitle": {
"message": "Search results for \"{query}\"",
"description": "The search page title for non-empty query"
},
"theme.SearchPage.emptyResultsTitle": {
"message": "Search the documentation",
"description": "The search page title for empty query"
},
"theme.SearchPage.inputPlaceholder": {
"message": "Type your search here",
"description": "The placeholder for search page input"
},
"theme.SearchPage.inputLabel": {
"message": "Search",
"description": "The ARIA label for search page input"
},
"theme.SearchPage.algoliaLabel": {
"message": "Search by Algolia",
"description": "The ARIA label for Algolia mention"
},
"theme.SearchPage.noResultsText": {
"message": "No results were found",
"description": "The paragraph for empty search result"
},
"theme.SearchPage.fetchingNewResults": {
"message": "Fetching new results...",
"description": "The paragraph for fetching new search results"
},
"theme.SearchBar.label": {
"message": "Search",
"description": "The ARIA label and placeholder for search button"
},
"theme.SearchModal.searchBox.resetButtonTitle": {
"message": "Clear the query",
"description": "The label and ARIA label for search box reset button"
},
"theme.SearchModal.searchBox.cancelButtonText": {
"message": "Cancel",
"description": "The label and ARIA label for search box cancel button"
},
"theme.SearchModal.startScreen.recentSearchesTitle": {
"message": "Recent",
"description": "The title for recent searches"
},
"theme.SearchModal.startScreen.noRecentSearchesText": {
"message": "No recent searches",
"description": "The text when no recent searches"
},
"theme.SearchModal.startScreen.saveRecentSearchButtonTitle": {
"message": "Save this search",
"description": "The label for save recent search button"
},
"theme.SearchModal.startScreen.removeRecentSearchButtonTitle": {
"message": "Remove this search from history",
"description": "The label for remove recent search button"
},
"theme.SearchModal.startScreen.favoriteSearchesTitle": {
"message": "Favorite",
"description": "The title for favorite searches"
},
"theme.SearchModal.startScreen.removeFavoriteSearchButtonTitle": {
"message": "Remove this search from favorites",
"description": "The label for remove favorite search button"
},
"theme.SearchModal.errorScreen.titleText": {
"message": "Unable to fetch results",
"description": "The title for error screen of search modal"
},
"theme.SearchModal.errorScreen.helpText": {
"message": "You might want to check your network connection.",
"description": "The help text for error screen of search modal"
},
"theme.SearchModal.footer.selectText": {
"message": "to select",
"description": "The explanatory text of the action for the enter key"
},
"theme.SearchModal.footer.selectKeyAriaLabel": {
"message": "Enter key",
"description": "The ARIA label for the Enter key button that makes the selection"
},
"theme.SearchModal.footer.navigateText": {
"message": "to navigate",
"description": "The explanatory text of the action for the Arrow up and Arrow down key"
},
"theme.SearchModal.footer.navigateUpKeyAriaLabel": {
"message": "Arrow up",
"description": "The ARIA label for the Arrow up key button that makes the navigation"
},
"theme.SearchModal.footer.navigateDownKeyAriaLabel": {
"message": "Arrow down",
"description": "The ARIA label for the Arrow down key button that makes the navigation"
},
"theme.SearchModal.footer.closeText": {
"message": "to close",
"description": "The explanatory text of the action for Escape key"
},
"theme.SearchModal.footer.closeKeyAriaLabel": {
"message": "Escape key",
"description": "The ARIA label for the Escape key button that close the modal"
},
"theme.SearchModal.footer.searchByText": {
"message": "Search by",
"description": "The text explain that the search is making by Algolia"
},
"theme.SearchModal.noResultsScreen.noResultsText": {
"message": "No results for",
"description": "The text explains that there are no results for the following search"
},
"theme.SearchModal.noResultsScreen.suggestedQueryText": {
"message": "Try searching for",
"description": "The text for the suggested query when no results are found for the following search"
},
"theme.SearchModal.noResultsScreen.reportMissingResultsText": {
"message": "Believe this query should return results?",
"description": "The text for the question where the user thinks there are missing results"
},
"theme.SearchModal.noResultsScreen.reportMissingResultsLinkText": {
"message": "Let us know.",
"description": "The text for the link to report missing results"
},
"theme.SearchModal.placeholder": {
"message": "Search docs",
"description": "The placeholder of the input of the DocSearch pop-up modal"
},
"theme.common.skipToMainContent": {
"message": "Skip to main content",
"description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation"
},
"theme.tags.tagsPageTitle": {
"message": "Tags",
"description": "The title of the tag list page"
}
}

View File

@@ -0,0 +1,93 @@
---
title: Introducing Experiments
description: A look at where task is, where it's going and how we're going to get there.
slug: task-in-2023
authors:
- pd93
tags:
- experiments
- breaking-changes
- roadmap
- v4
image: https://i.imgur.com/mErPwqL.png
hide_table_of_contents: false
---
Lately, Task has been growing extremely quickly and I've found myself thinking a lot about the future of the project and how we continue to evolve and grow. I'm not much of a writer, but I think one of the things we could do better is to communicate these kinds of thoughts to the community. So, with that in mind, this is the first (hopefully of many) blog posts talking about Task and what we're up to.
<!--truncate-->
## :calendar: So, what have we been up to?
Over the past 12 months or so, [@andreynering][] (Author and maintainer of the project) and I ([@pd93][]) have been working in our spare time to maintain and improve v3 of Task and we've made some amazing progress. Here are just some of the things we've released in that time:
- An official [extension for VS Code][vscode-task].
- Internal Tasks ([#818](https://github.com/go-task/task/pull/818)).
- Task aliases ([#879](https://github.com/go-task/task/pull/879)).
- Looping over tasks ([#1220](https://github.com/go-task/task/pull/1200)).
- A series of refactors to the core codebase to make it more maintainable and extensible.
- Loads of bug fixes and improvements.
- An integration with [Crowdin][crowdin]. Work is in progress on making our docs available in **7 new languages** (Special thanks to all our translators for the huge help with this!).
- And much, much more! :sparkles:
We're also working on adding some really exciting and highly requested features to Task such as having the ability to run remote Taskfiles ([#1317](https://github.com/go-task/task/issues/1317)).
None of this would have been possible without the [150 or so (and growing) contributors][contributors] to the project, numerous sponsors and a passionate community of users. Together we have more than doubled the number of GitHub stars to over 8400 :star: since the beginning of 2022 and this continues to accelerate. We can't thank you all enough for your help and support! :rocket:
[![Star History Chart](https://api.star-history.com/svg?repos=go-task/task&type=Date)](https://star-history.com/#go-task/task&Date)
## What's next? :thinking_face:
It's extremely motivating to see so many people using and loving Task. However, in this time we've also seen an increase in the number of issues and feature requests. In particular, issues that require some kind of breaking change to Task. This isn't a bad thing, but as we grow we need to be more responsible about how we address these changes in a way that ensures stability and compatibility for existing users and their Taskfiles.
At this point you're probably thinking something like:
> "But you use [semantic versioning][semver] - Just release a new major version with your breaking changes."
And you'd be right... sort of. In theory, this sounds great, but the reality is that we don't have the time to commit to a major overhaul of Task in one big bang release. This would require a colossal amount of time and coordination and with full time jobs and personal lives to tend to, this is a difficult commitment to make. Smaller, more frequent major releases are also a significant inconvenience for users as they have to constantly keep up-to-date with our breaking changes. Fortunately, there is a better way.
## What's going to change? :face_with_monocle:
Going forwards, breaking changes will be allowed into _minor_ versions of Task as "experimental features". To access these features users will need opt-in by enabling feature flags. This will allow us to release new features slowly and gather feedback from the community before making them the default behavior in a future major release.
To prepare users for the next major release, we will maintain a list of [deprecated features][deprecations] and [experiments][experiments] on our docs website and publish information on how to migrate to the new behavior.
You can read the [full breaking change proposal][breaking-change-proposal] and view all the [current experiments and their status][experiments-project] on GitHub including the [Gentle Force][gentle-force-experiment] and [Remote Taskfiles][remote-taskfiles-experiment] experiments.
## What will happen to v2/v3 features?
v2 has been [officially deprecated][deprecate-version-2-schema]. If you're still using a Taskfile with `version: "2"` at the top we _strongly recommend_ that you upgrade as soon as possible. Removing v2 will allow us to tidy up the codebase and focus on new functionality instead.
When v4 is released, we will continue to support v3 for a period of time (bug fixes etc). However, since we are moving from a backward-compatibility model to a forwards-compatibility model, **v4 itself will not be backwards compatible with v3**.
## v4 When? :eyes:
:shrug: When it's ready.
In all seriousness, we don't have a timeline for this yet. We'll be working on the most serious deficiencies of the v3 API first and regularly evaluating the state of the project. When we feel its in a good, stable place and we have a clear upgrade path for users and a number of stable experiments, we'll start to think about v4.
## :wave: Final thoughts
Task is growing fast and we're excited to see where it goes next. We hope that the steps we're taking to improve the project and our process will help us to continue to grow. As always, if you have any questions or feedback, we encourage you to comment on or open [issues][issues] and [discussions][discussions] on GitHub. Alternatively, you can join us on [Discord][discord].
I plan to write more of these blog posts in the future on a variety of Task-related topics, so make sure to check in occasionally and see what we're up to!
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[vscode-task]: https://github.com/go-task/vscode-task
[crowdin]: https://crowdin.com
[contributors]: https://github.com/go-task/task/graphs/contributors
[semver]: https://semver.org
[breaking-change-proposal]: https://github.com/go-task/task/discussions/1191
[@andreynering]: https://github.com/andreynering
[@pd93]: https://github.com/pd93
[experiments]: https://taskfile.dev/experiments
[deprecations]: https://taskfile.dev/deprecations
[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
[issues]: https://github.com/go-task/task/issues
[discussions]: https://github.com/go-task/task/discussions
[discord]: https://discord.gg/6TY36E39UK
[experiments-project]: https://github.com/orgs/go-task/projects/1
[gentle-force-experiment]: https://github.com/go-task/task/issues/1200
[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317

View File

@@ -0,0 +1,10 @@
andreynering:
name: Andrey Nering
title: Taskメンテナー
url: https://github.com/andreynering
image_url: https://github.com/andreynering.png
pd93:
name: Pete Davison
title: Maintainer of Task
url: https://github.com/pd93
image_url: https://github.com/pd93.png

View File

@@ -0,0 +1,6 @@
{
"version.label": {
"message": "次へ",
"description": "The label for version current"
}
}

View File

@@ -0,0 +1,341 @@
---
slug: /api/
sidebar_position: 4
toc_min_heading_level: 2
toc_max_heading_level: 5
---
# APIリファレンス
## CLI
Taskコマンドラインツールは以下のような構文を持っています:
```bash
task [--flags] [tasks...] [-- CLI_ARGS...]
```
:::tip
`--`が渡されると、次に続く全てのパラメータは`CLI_ARGS`という特別な変数に格納されます
:::
| ショート | フラグ | 型 | デフォルト値 | 説明 |
| ---- | --------------------------- | -------- | -------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `-c` | `--color` | `bool` | `true` | Colored output. Enabled by default. Set flag to `false` or use `NO_COLOR=1` to disable. |
| `-C` | `--concurrency` | `int` | `0` | Limit number tasks to run concurrently. Zero means unlimited. |
| `-d` | `--dir` | `string` | ワーキングディレクトリ | Sets directory of execution. |
| `-n` | `--dry` | `bool` | `false` | Compiles and prints tasks in the order that they would be run, without executing them. |
| `-x` | `--exit-code` | `bool` | `false` | Pass-through the exit code of the task command. |
| `-f` | `--force` | `bool` | `false` | Forces execution even when the task is up-to-date. |
| `-g` | `--global` | `bool` | `false` | Runs global Taskfile, from `$HOME/Taskfile.{yml,yaml}`. |
| `-h` | `--help` | `bool` | `false` | Shows Task usage. |
| `-i` | `--init` | `bool` | `false` | Creates a new Taskfile.yml in the current folder. |
| `-I` | `--interval` | `string` | `5s` | Sets a different watch interval when using `--watch`, the default being 5 seconds. This string should be a valid [Go Duration](https://pkg.go.dev/time#ParseDuration). |
| `-l` | `--list` | `bool` | `false` | Lists tasks with description of current Taskfile. |
| `-a` | `--list-all` | `bool` | `false` | Lists tasks with or without a description. |
| | `--sort` | `string` | `default` | Changes the order of the tasks when listed.<br />`default` - Alphanumeric with root tasks first<br />`alphanumeric` - Alphanumeric<br />`none` - No sorting (As they appear in the Taskfile) |
| | `--json` | `bool` | `false` | See [JSON Output](#json-output) |
| `-o` | `--output` | `string` | Default set in the Taskfile or `intervealed` | Sets output style: [`interleaved`/`group`/`prefixed`]. |
| | `--output-group-begin` | `string` | | Message template to print before a task's grouped output. |
| | `--output-group-end` | `string` | | Message template to print after a task's grouped output. |
| | `--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`または`Taskfile.yaml` | |
| `-v` | `--verbose` | `bool` | `false` | Enables verbose mode. |
| | `--version` | `bool` | `false` | Show Task version. |
| `-w` | `--watch` | `bool` | `false` | Enables watch of the given task. |
## 終了コード
Task will sometimes exit with specific exit codes. These codes are split into three groups with the following ranges:
- General errors (0-99)
- Taskfile errors (100-199)
- Task errors (200-299)
A full list of the exit codes and their descriptions can be found below:
| コード | 説明 |
| --- | ------------------------------------------------------------ |
| 0 | Success |
| 1 | An unknown error occurred |
| 100 | No Taskfile was found |
| 101 | A Taskfile already exists when trying to initialize one |
| 102 | The Taskfile is invalid or cannot be parsed |
| 200 | The specified task could not be found |
| 201 | An error occurred while executing a command inside of a task |
| 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 |
| 206 | A task was not executed due to missing required variables |
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出力
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:
```json
{
"tasks": [
{
"name": "",
"desc": "",
"summary": "",
"up_to_date": false,
"location": {
"line": 54,
"column": 3,
"taskfile": "/path/to/Taskfile.yml"
}
}
// ...
],
"location": "/path/to/Taskfile.yml"
}
```
## 特殊な変数
There are some special variables that is available on the templating system:
| Var | Description |
| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `CLI_ARGS` | Contain all extra arguments passed after `--` when calling Task through the CLI. |
| `TASK` | The name of the current task. |
| `ROOT_DIR` | The absolute path of the root Taskfile. |
| `TASKFILE_DIR` | The absolute path of the included Taskfile. |
| `USER_WORKING_DIR` | The absolute path of the directory `task` was called from. |
| `CHECKSUM` | The checksum of the files listed in `sources`. Only available within the `status` prop and if method is set to `checksum`. |
| `TIMESTAMP` | The date object of the greatest timestamp of the files listed in `sources`. Only available within the `status` prop and if method is set to `timestamp`. |
| `TASK_VERSION` | The current version of task. |
| `ITEM` | The value of the current iteration when using the `for` property. Can be changed to a different variable name using `as:`. |
## 環境変数
Some environment variables can be overridden to adjust Task behavior.
| 環境変数 | デフォルト値 | 説明 |
| -------------------- | ------- | ----------------------------------------------------------------------------------------------------------------- |
| `TASK_TEMP_DIR` | `.task` | Location of the temp dir. Can relative to the project like `tmp/task` or absolute like `/tmp/.task` or `~/.task`. |
| `TASK_COLOR_RESET` | `0` | Color used for white. |
| `TASK_COLOR_BLUE` | `34` | Color used for blue. |
| `TASK_COLOR_GREEN` | `32` | Color used for green. |
| `TASK_COLOR_CYAN` | `36` | Color used for cyan. |
| `TASK_COLOR_YELLOW` | `33` | Color used for yellow. |
| `TASK_COLOR_MAGENTA` | `35` | Color used for magenta. |
| `TASK_COLOR_RED` | `31` | Color used for red. |
| `FORCE_COLOR` | | Force color output usage. |
## Taskfileのスキーマ
| 属性 | 型 | デフォルト値 | 説明 |
| ---------- | ---------------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `version` | `string` | | Version of the Taskfile. The current version is `3`. |
| `output` | `string` | `interleaved` | Output mode. Available options: `interleaved`, `group` and `prefixed`. |
| `method` | `string` | `checksum` | Default method in this Taskfile. Can be overridden in a task by task basis. Available options: `checksum`, `timestamp` and `none`. |
| `includes` | [`map[string]Include`](#include) | | Additional Taskfiles to be included. |
| `vars` | [`map[string]Variable`](#variable) | | A set of global variables. |
| `env` | [`map[string]Variable`](#variable) | | A set of global environment variables. |
| `tasks` | [`map[string]Task`](#task) | | A set of task definitions. |
| `silent` | `bool` | `false` | Default 'silent' options for this Taskfile. If `false`, can be overridden with `true` in a task by task basis. |
| `dotenv` | `[]string` | | A list of `.env` file paths to be parsed. |
| `run` | `string` | `always` | Default 'run' option for this Taskfile. Available options: `always`, `once` and `when_changed`. |
| `interval` | `string` | `5s` | Sets a different watch interval when using `--watch`, the default being 5 seconds. This string should be a valid [Go Duration](https://pkg.go.dev/time#ParseDuration). |
| `set` | `[]string` | | Specify options for the [`set` builtin](https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html). |
| `shopt` | `[]string` | | Specify option for the [`shopt` builtin](https://www.gnu.org/software/bash/manual/html_node/The-Shopt-Builtin.html). |
### Include
| Attribute | Type | Default | Description |
| ---------- | --------------------- | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `taskfile` | `string` | | The path for the Taskfile or directory to be included. If a directory, Task will look for files named `Taskfile.yml` or `Taskfile.yaml` inside that directory. If a relative path, resolved relative to the directory containing the including Taskfile. |
| `dir` | `string` | The parent Taskfile directory | The working directory of the included tasks when run. |
| `optional` | `bool` | `false` | If `true`, no errors will be thrown if the specified file does not exist. |
| `internal` | `bool` | `false` | Stops any task in the included Taskfile from being callable on the command line. These commands will also be omitted from the output when used with `--list`. |
| `aliases` | `[]string` | | Alternative names for the namespace of the included Taskfile. |
| `vars` | `map[string]Variable` | | A set of variables to apply to the included Taskfile. |
:::info
Informing only a string like below is equivalent to setting that value to the `taskfile` attribute.
```yaml
includes:
foo: ./path
```
:::
### Variable
| 属性 | 型 | デフォルト値 | 説明 |
| -------- | -------- | ------ | ------------------------------------------------------------------------ |
| _itself_ | `string` | | A static value that will be set to the variable. |
| `sh` | `string` | | A shell command. The output (`STDOUT`) will be assigned to the variable. |
:::info
Static and dynamic variables have different syntaxes, like below:
```yaml
vars:
STATIC: static
DYNAMIC:
sh: echo "dynamic"
```
:::
### Task
| 属性 | 型 | デフォルト値 | 説明 |
| --------------- | ---------------------------------- | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `cmds` | [`[]Command`](#command) | | A list of shell commands to be executed. |
| `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. |
| `generates` | `[]string` | | A list of files meant to be generated by this task. Relevant for `timestamp` method. Can be file paths or star globs. |
| `status` | `[]string` | | A list of commands to check if this task should run. The task is skipped otherwise. This overrides `method`, `sources` and `generates`. |
| `requires` | `[]string` | | A list of variables which should be set if this task is to run, if any of these variables are unset the task will error and not run. |
| `preconditions` | [`[]Precondition`](#precondition) | | A list of commands to check if this task should run. If a condition is not met, the task will error. |
| `requires` | [`Requires`](#requires) | | A list of required variables which should be set if this task is to run, if any variables listed are unset the task will error and not run. |
| `dir` | `string` | | The directory in which this task should run. Defaults to the current working directory. |
| `vars` | [`map[string]Variable`](#variable) | | A set of variables that can be used in the task. |
| `env` | [`map[string]Variable`](#variable) | | A set of environment variables that will be made available to shell commands. |
| `dotenv` | `[]string` | | A list of `.env` file paths to be parsed. |
| `silent` | `bool` | `false` | Hides task name and command from output. The command's output will still be redirected to `STDOUT` and `STDERR`. When combined with the `--list` flag, task descriptions will be hidden. |
| `interactive` | `bool` | `false` | Tells task that the command is interactive. |
| `internal` | `bool` | `false` | Stops a task from being callable on the command line. It will also be omitted from the output when used with `--list`. |
| `method` | `string` | `checksum` | Defines which method is used to check the task is up-to-date. `timestamp` will compare the timestamp of the sources and generates files. `checksum` will check the checksum (You probably want to ignore the .task folder in your .gitignore file). `none` skips any validation and always run the task. |
| `prefix` | `string` | | Defines a string to prefix the output of tasks running in parallel. Only used when the output mode is `prefixed`. |
| `ignore_error` | `bool` | `false` | Continue execution if errors happen while executing commands. |
| `run` | `string` | The one declared globally in the Taskfile or `always` | Specifies whether the task should run again or not if called more than once. Available options: `always`, `once` and `when_changed`. |
| `platforms` | `[]string` | All platforms | Specifies which platforms the task should be run on. [Valid GOOS and GOARCH values allowed](https://github.com/golang/go/blob/main/src/go/build/syslist.go). Task will be skipped otherwise. |
| `set` | `[]string` | | Specify options for the [`set` builtin](https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html). |
| `shopt` | `[]string` | | Specify option for the [`shopt` builtin](https://www.gnu.org/software/bash/manual/html_node/The-Shopt-Builtin.html). |
:::info
These alternative syntaxes are available. They will set the given values to `cmds` and everything else will be set to their default values:
```yaml
tasks:
foo: echo "foo"
foobar:
- echo "foo"
- echo "bar"
baz:
cmd: echo "baz"
```
:::
#### Command
| Attribute | Type | Default | Description |
| -------------- | ---------------------------------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `cmd` | `string` | | The shell command to be executed. |
| `task` | `string` | | Set this to trigger execution of another task instead of running a command. This cannot be set together with `cmd`. |
| `for` | [`For`](#for) | | Runs the command once for each given value. |
| `silent` | `bool` | `false` | Skips some output for this command. Note that STDOUT and STDERR of the commands will still be redirected. |
| `vars` | [`map[string]Variable`](#variable) | | Optional additional variables to be passed to the referenced task. Only relevant when setting `task` instead of `cmd`. |
| `ignore_error` | `bool` | `false` | Continue execution if errors happen while executing the command. |
| `defer` | `string` | | Alternative to `cmd`, but schedules the command to be executed at the end of this task instead of immediately. This cannot be used together with `cmd`. |
| `platforms` | `[]string` | All platforms | Specifies which platforms the command should be run on. [Valid GOOS and GOARCH values allowed](https://github.com/golang/go/blob/main/src/go/build/syslist.go). Command will be skipped otherwise. |
| `set` | `[]string` | | Specify options for the [`set` builtin](https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html). |
| `shopt` | `[]string` | | Specify option for the [`shopt` builtin](https://www.gnu.org/software/bash/manual/html_node/The-Shopt-Builtin.html). |
:::info
If given as a a string, the value will be assigned to `cmd`:
```yaml
tasks:
foo:
cmds:
- echo "foo"
- echo "bar"
```
:::
#### Dependency
| Attribute | Type | Default | Description |
| --------- | ---------------------------------- | ------- | ---------------------------------------------------------------------------------------------------------------- |
| `task` | `string` | | The task to be execute as a dependency. |
| `vars` | [`map[string]Variable`](#variable) | | Optional additional variables to be passed to this task. |
| `silent` | `bool` | `false` | Hides task name and command from output. The command's output will still be redirected to `STDOUT` and `STDERR`. |
:::tip
If you don't want to set additional variables, it's enough to declare the dependency as a list of strings (they will be assigned to `task`):
```yaml
tasks:
foo:
deps: [foo, bar]
```
:::
#### For
The `for` parameter can be defined as a string, a list of strings or a map. If it is defined as a string, you can give it any of the following values:
- `source` - Will run the command for each source file defined on the task. (Glob patterns will be resolved, so `*.go` will run for every Go file that matches).
If it is defined as a list of strings, the command will be run for each value.
Finally, the `for` parameter can be defined as a map when you want to use a variable to define the values to loop over:
| Attribute | Type | Default | Description |
| --------- | -------- | ---------------- | -------------------------------------------- |
| `var` | `string` | | The name of the variable to use as an input. |
| `split` | `string` | (any whitespace) | What string the variable should be split on. |
| `as` | `string` | `ITEM` | The name of the iterator variable. |
#### Precondition
| Attribute | Type | Default | Description |
| --------- | -------- | ------- | ------------------------------------------------------------------------------------------------------------ |
| `sh` | `string` | | Command to be executed. If a non-zero exit code is returned, the task errors without executing its commands. |
| `msg` | `string` | | Optional message to print if the precondition isn't met. |
:::tip
If you don't want to set a different message, you can declare a precondition like this and the value will be assigned to `sh`:
```yaml
tasks:
foo:
precondition: test -f Taskfile.yml
```
:::
#### Requires
| Attribute | Type | Default | Description |
| --------- | ---------- | ------- | -------------------------------------------------------------------------------------------------- |
| `vars` | `[]string` | | List of variable or environment variable names that must be set if this task is to execute and run |

View File

@@ -0,0 +1,509 @@
---
slug: /changelog/
sidebar_position: 14
---
# Changelog
## v3.29.1 - 2023-08-26
- Update to Go 1.21 (bump minimum version to 1.20) ([#1302](https://github.com/go-task/task/issues/1302) by [@pd93](https://github.com/pd93))
- Fix a missing a line break on log when using `--watch` mode ([#1285](https://github.com/go-task/task/issues/1285), [#1297](https://github.com/go-task/task/issues/1297) by [@FilipSolich](https://github.com/FilipSolich)).
- Fix `defer` on JSON Schema ([#1288](https://github.com/go-task/task/issues/1288) by [@calvinmclean](https://github.com/calvinmclean) and [@andreynering](https://github.com/andreynering)).
- Fix bug in usage of special variables like `{{.USER_WORKING_DIR}}` in combination with `includes` ([#1046](https://github.com/go-task/task/issues/1046), [#1205](https://github.com/go-task/task/issues/1205), [#1250](https://github.com/go-task/task/issues/1250), [#1293](https://github.com/go-task/task/issues/1293), [#1312](https://github.com/go-task/task/issues/1312), [#1274](https://github.com/go-task/task/issues/1274) by [@andarto](https://github.com/andarto), [#1309](https://github.com/go-task/task/issues/1309) by [@andreynering](https://github.com/andreynering)).
- Fix bug on `--status` flag. Running this flag should not have side-effects: it should not update the checksum on `.task`, only report its status ([#1305](https://github.com/go-task/task/issues/1305), [#1307](https://github.com/go-task/task/issues/1307) by [@visciang](https://github.com/visciang), [#1313](https://github.com/go-task/task/issues/1313) by [@andreynering](https://github.com/andreynering)).
## v3.28.0 - 2023-07-24
- Added the ability to [loop over commands and tasks](https://taskfile.dev/usage/#looping-over-values) using `for` ([#82](https://github.com/go-task/task/issues/82), [#1220](https://github.com/go-task/task/issues/1220) by [@pd93](https://github.com/pd93)).
- Fixed variable propagation in multi-level includes ([#778](https://github.com/go-task/task/issues/778), [#996](https://github.com/go-task/task/issues/996), [#1256](https://github.com/go-task/task/issues/1256) by [@hudclark](https://github.com/hudclark)).
- Fixed a bug where the `--exit-code` code flag was not returning the correct exit code when calling commands indirectly ([#1266](https://github.com/go-task/task/issues/1266), [#1270](https://github.com/go-task/task/issues/1270) by [@pd93](https://github.com/pd93)).
- Fixed a `nil` panic when a dependency was commented out or left empty ([#1263](https://github.com/go-task/task/issues/1263) by [@neomantra](https://github.com/neomantra)).
## v3.27.1 - 2023-06-30
- Fix panic when a `.env` directory (not file) is present on current directory ([#1244](https://github.com/go-task/task/issues/1244), [#1245](https://github.com/go-task/task/issues/1245) by [@pd93](https://github.com/pd93)).
## v3.27.0 - 2023-06-29
- Allow Taskfiles starting with lowercase characters ([#947](https://github.com/go-task/task/issues/947), [#1221](https://github.com/go-task/task/issues/1221) by [@pd93](https://github.com/pd93)).
- e.g. `taskfile.yml`, `taskfile.yaml`, `taskfile.dist.yml` & `taskfile.dist.yaml`
- Bug fixes were made to the [npm installation method](https://taskfile.dev/installation/#npm). ([#1190](https://github.com/go-task/task/issues/1190), by [@sounisi5011](https://github.com/sounisi5011)).
- Added the [gentle force experiment](https://taskfile.dev/experiments) as a draft ([#1200](https://github.com/go-task/task/issues/1200), [#1216](https://github.com/go-task/task/issues/1216) by [@pd93](https://github.com/pd93)).
- Added an `--experiments` flag to allow you to see which experiments are enabled ([#1242](https://github.com/go-task/task/issues/1242) by [@pd93](https://github.com/pd93)).
- Added ability to specify which variables are required in a task ([#1203](https://github.com/go-task/task/issues/1203), [#1204](https://github.com/go-task/task/issues/1204) by [@benc](https://github.com/benc)-uk).
## v3.26.0 - 2023-06-10
- Only rewrite checksum files in `.task` if the checksum has changed ([#1185](https://github.com/go-task/task/issues/1185), [#1194](https://github.com/go-task/task/issues/1194) by [@deviantintegral](https://github.com/deviantintegral)).
- Added [experiments documentation](https://taskfile.dev/experiments) to the website ([#1198](https://github.com/go-task/task/issues/1198) by [@pd93](https://github.com/pd93)).
- Deprecated `version: 2` schema. This will be removed in the next major release ([#1197](https://github.com/go-task/task/issues/1197), [#1198](https://github.com/go-task/task/issues/1198), [#1199](https://github.com/go-task/task/issues/1199) by [@pd93](https://github.com/pd93)).
- Added a new `prompt:` prop to set a warning prompt to be shown before running a potential dangurous task ([#100](https://github.com/go-task/task/issues/100), [#1163](https://github.com/go-task/task/issues/1163) by [@MaxCheetham](https://github.com/MaxCheetham), [Documentation](https://taskfile.dev/usage/#warning-prompts)).
- Added support for single command task syntax. With this change, it's now possible to declare just `cmd:` in a task, avoiding the more complex `cmds: []` when you have only a single command for that task ([#1130](https://github.com/go-task/task/issues/1130), [#1131](https://github.com/go-task/task/issues/1131) by [@timdp](https://github.com/timdp)).
## v3.25.0 - 2023-05-22
- Support `silent:` when calling another tasks ([#680](https://github.com/go-task/task/issues/680), [#1142](https://github.com/go-task/task/issues/1142) by [@danquah](https://github.com/danquah)).
- Improve PowerShell completion script ([#1168](https://github.com/go-task/task/issues/1168) by [@trim21](https://github.com/trim21)).
- Add more languages to the website menu and show translation progress percentage ([#1173](https://github.com/go-task/task/issues/1173) by [@misitebao](https://github.com/misitebao)).
- Starting on this release, official binaries for FreeBSD will be available to download ([#1068](https://github.com/go-task/task/issues/1068) by [@andreynering](https://github.com/andreynering)).
- Fix some errors being unintendedly supressed ([#1134](https://github.com/go-task/task/issues/1134) by [@clintmod](https://github.com/clintmod)).
- Fix a nil pointer error when `version` is omitted from a Taskfile ([#1148](https://github.com/go-task/task/issues/1148), [#1149](https://github.com/go-task/task/issues/1149) by [@pd93](https://github.com/pd93)).
- Fix duplicate error message when a task does not exists ([#1141](https://github.com/go-task/task/issues/1141), [#1144](https://github.com/go-task/task/issues/1144) by [@pd93](https://github.com/pd93)).
## v3.24.0 - 2023-04-15
- Fix Fish shell completion for tasks with aliases ([#1113](https://github.com/go-task/task/issues/1113) by [@patricksjackson](https://github.com/patricksjackson)).
- The default branch was renamed from `master` to `main` ([#1049](https://github.com/go-task/task/issues/1049), [#1048](https://github.com/go-task/task/issues/1048) by [@pd93](https://github.com/pd93)).
- Fix bug where "up-to-date" logs were not being omitted for silent tasks ([#546](https://github.com/go-task/task/issues/546), [#1107](https://github.com/go-task/task/issues/1107) by [@danquah](https://github.com/danquah)).
- Add `.hg` (Mercurial) to the list of ignored directories when using `--watch` ([#1098](https://github.com/go-task/task/issues/1098) by [@misery](https://github.com/misery)).
- More improvements to the release tool ([#1096](https://github.com/go-task/task/issues/1096) by [@pd93](https://github.com/pd93)).
- Enforce [gofumpt](https://github.com/mvdan/gofumpt) linter ([#1099](https://github.com/go-task/task/issues/1099) by [@pd93](https://github.com/pd93))
- Add `--sort` flag for use with `--list` and `--list-all` ([#946](https://github.com/go-task/task/issues/946), [#1105](https://github.com/go-task/task/issues/1105) by [@pd93](https://github.com/pd93)).
- Task now has [custom exit codes](https://taskfile.dev/api/#exit-codes) depending on the error ([#1114](https://github.com/go-task/task/issues/1114) by [@pd93](https://github.com/pd93)).
## v3.23.0 - 2023-03-26
Task now has an [official extension for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=task.vscode-task) contributed by [@pd93](https://github.com/pd93)! :tada: The extension is maintained in a [new repository](https://github.com/go-task/vscode-task) under the `go-task` organization. We're looking to gather feedback from the community so please give it a go and let us know what you think via a [discussion](https://github.com/go-task/vscode-task/discussions), [issue](https://github.com/go-task/vscode-task/issues) or on our [Discord](https://discord.gg/6TY36E39UK)!
> **NOTE:** The extension _requires_ v3.23.0 to be installed in order to work.
- The website was integrated with [Crowdin](https://crowdin.com/project/taskfile) to allow the community to contribute with translations! [Chinese](https://taskfile.dev/zh-Hans/) is the first language available ([#1057](https://github.com/go-task/task/issues/1057), [#1058](https://github.com/go-task/task/issues/1058) by [@misitebao](https://github.com/misitebao)).
- Added task location data to the `--json` flag output ([#1056](https://github.com/go-task/task/issues/1056) by [@pd93](https://github.com/pd93))
- Change the name of the file generated by `task --init` from `Taskfile.yaml` to `Taskfile.yml` ([#1062](https://github.com/go-task/task/issues/1062) by [@misitebao](https://github.com/misitebao)).
- Added new `splitArgs` template function (`{{splitArgs "foo bar 'foo bar baz'"}}`) to ensure string is split as arguments ([#1040](https://github.com/go-task/task/issues/1040), [#1059](https://github.com/go-task/task/issues/1059) by [@dhanusaputra](https://github.com/dhanusaputra)).
- Fix the value of `{{.CHECKSUM}}` variable in status ([#1076](https://github.com/go-task/task/issues/1076), [#1080](https://github.com/go-task/task/issues/1080) by [@pd93](https://github.com/pd93)).
- Fixed deep copy implementation ([#1072](https://github.com/go-task/task/issues/1072) by [@pd93](https://github.com/pd93))
- Created a tool to assist with releases ([#1086](https://github.com/go-task/task/issues/1086) by [@pd93](https://github.com/pd93)).
## v3.22.0 - 2023-03-10
- Add a brand new `--global` (`-g`) flag that will run a Taskfile from your `$HOME` directory. This is useful to have automation that you can run from anywhere in your system! ([Documentation](https://taskfile.dev/usage/#running-a-global-taskfile), [#1029](https://github.com/go-task/task/issues/1029) by [@andreynering](https://github.com/andreynering)).
- Add ability to set `error_only: true` on the `group` output mode. This will instruct Task to only print a command output if it returned with a non-zero exit code ([#664](https://github.com/go-task/task/issues/664), [#1022](https://github.com/go-task/task/issues/1022) by [@jaedle](https://github.com/jaedle)).
- Fixed bug where `.task/checksum` file was sometimes not being created when task also declares a `status:` ([#840](https://github.com/go-task/task/issues/840), [#1035](https://github.com/go-task/task/issues/1035) by [@harelwa](https://github.com/harelwa), [#1037](https://github.com/go-task/task/issues/1037) by [@pd93](https://github.com/pd93)).
- Refactored and decoupled fingerprinting from the main Task executor ([#1039](https://github.com/go-task/task/issues/1039) by [@pd93](https://github.com/pd93)).
- Fixed deadlock issue when using `run: once` ([#715](https://github.com/go-task/task/issues/715), [#1025](https://github.com/go-task/task/issues/1025) by [@theunrepentantgeek](https://github.com/theunrepentantgeek)).
## v3.21.0 - 2023-02-22
- Added new `TASK_VERSION` special variable ([#990](https://github.com/go-task/task/issues/990), [#1014](https://github.com/go-task/task/issues/1014) by [@ja1code](https://github.com/ja1code)).
- Fixed a bug where tasks were sometimes incorrectly marked as internal ([#1007](https://github.com/go-task/task/issues/1007) by [@pd93](https://github.com/pd93)).
- Update to Go 1.20 (bump minimum version to 1.19) ([#1010](https://github.com/go-task/task/issues/1010) by [@pd93](https://github.com/pd93))
- Added environment variable `FORCE_COLOR` support to force color output. Usefull for environments without TTY ([#1003](https://github.com/go-task/task/issues/1003) by [@automation](https://github.com/automation)-stack)
## v3.20.0 - 2023-01-14
- Improve behavior and performance of status checking when using the `timestamp` mode ([#976](https://github.com/go-task/task/issues/976), [#977](https://github.com/go-task/task/issues/977) by [@aminya](https://github.com/aminya)).
- Performance optimizations were made for large Taskfiles ([#982](https://github.com/go-task/task/issues/982) by [@pd93](https://github.com/pd93)).
- Add ability to configure options for the [`set`](https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html) and [`shopt`](https://www.gnu.org/software/bash/manual/html_node/The-Shopt-Builtin.html) builtins ([#908](https://github.com/go-task/task/issues/908), [#929](https://github.com/go-task/task/issues/929) by [@pd93](https://github.com/pd93), [Documentation](http://taskfile.dev/usage/#set-and-shopt)).
- Add new `platforms:` attribute to `task` and `cmd`, so it's now possible to choose in which platforms that given task or command will be run on. Possible values are operating system (GOOS), architecture (GOARCH) or a combination of the two. Example: `platforms: [linux]`, `platforms: [amd64]` or `platforms: [linux/amd64]`. Other platforms will be skipped ([#978](https://github.com/go-task/task/issues/978), [#980](https://github.com/go-task/task/issues/980) by [@leaanthony](https://github.com/leaanthony)).
## v3.19.1 - 2022-12-31
- Small bug fix: closing `Taskfile.yml` once we're done reading it ([#963](https://github.com/go-task/task/issues/963), [#964](https://github.com/go-task/task/issues/964) by [@HeCorr](https://github.com/HeCorr)).
- Fixes a bug in v2 that caused a panic when using a `Taskfile_{{OS}}.yml` file ([#961](https://github.com/go-task/task/issues/961), [#971](https://github.com/go-task/task/issues/971) by [@pd93](https://github.com/pd93)).
- Fixed a bug where watch intervals set in the Taskfile were not being respected ([#969](https://github.com/go-task/task/issues/969), [#970](https://github.com/go-task/task/issues/970) by [@pd93](https://github.com/pd93))
- Add `--json` flag (alias `-j`) with the intent to improve support for code editors and add room to other possible integrations. This is basic for now, but we plan to add more info in the near future ([#936](https://github.com/go-task/task/issues/936) by [@davidalpert](https://github.com/davidalpert), [#764](https://github.com/go-task/task/issues/764)).
## v3.19.0 - 2022-12-05
- Installation via npm now supports [pnpm](https://pnpm.io/) as well ([go-task/go-npm\[#2\](https://github.com/go-task/task/issues/2)](https://github.com/go-task/go-npm/issues/2), [go-task/go-npm\[#3\](https://github.com/go-task/task/issues/3)](https://github.com/go-task/go-npm/pull/3)).
- It's now possible to run Taskfiles from subdirectories! A new `USER_WORKING_DIR` special variable was added to add even more flexibility for monorepos ([#289](https://github.com/go-task/task/issues/289), [#920](https://github.com/go-task/task/issues/920)).
- Add task-level `dotenv` support ([#389](https://github.com/go-task/task/issues/389), [#904](https://github.com/go-task/task/issues/904)).
- It's now possible to use global level variables on `includes` ([#942](https://github.com/go-task/task/issues/942), [#943](https://github.com/go-task/task/issues/943)).
- The website got a brand new [translation to Chinese](https://task-zh.readthedocs.io/zh_CN/latest/) by [\[@DeronW\](https://github.com/DeronW)](https://github.com/DeronW). Thanks!
## v3.18.0 - 2022-11-12
- Show aliases on `task --list --silent` (`task --ls`). This means that aliases will be completed by the completion scripts ([#919](https://github.com/go-task/task/issues/919)).
- Tasks in the root Taskfile will now be displayed first in `--list`/`--list-all` output ([#806](https://github.com/go-task/task/issues/806), [#890](https://github.com/go-task/task/issues/890)).
- It's now possible to call a `default` task in an included Taskfile by using just the namespace. For example: `docs:default` is now automatically aliased to `docs` ([#661](https://github.com/go-task/task/issues/661), [#815](https://github.com/go-task/task/issues/815)).
## v3.17.0 - 2022-10-14
- Add a "Did you mean ...?" suggestion when a task does not exits another one with a similar name is found ([#867](https://github.com/go-task/task/issues/867), [#880](https://github.com/go-task/task/issues/880)).
- Now YAML parse errors will print which Taskfile failed to parse ([#885](https://github.com/go-task/task/issues/885), [#887](https://github.com/go-task/task/issues/887)).
- Add ability to set `aliases` for tasks and namespaces ([#268](https://github.com/go-task/task/issues/268), [#340](https://github.com/go-task/task/issues/340), [#879](https://github.com/go-task/task/issues/879)).
- Improvements to Fish shell completion ([#897](https://github.com/go-task/task/issues/897)).
- Added ability to set a different watch interval by setting `interval: '500ms'` or using the `--interval=500ms` flag ([#813](https://github.com/go-task/task/issues/813), [#865](https://github.com/go-task/task/issues/865)).
- Add colored output to `--list`, `--list-all` and `--summary` flags ([#845](https://github.com/go-task/task/issues/845), [#874](https://github.com/go-task/task/issues/874)).
- Fix unexpected behavior where `label:` was being shown instead of the task name on `--list` ([#603](https://github.com/go-task/task/issues/603), [#877](https://github.com/go-task/task/issues/877)).
## v3.16.0 - 2022-09-29
- Add `npm` as new installation method: `npm i -g [@go](https://github.com/go)-task/cli` ([#870](https://github.com/go-task/task/issues/870), [#871](https://github.com/go-task/task/issues/871), [npm package](https://www.npmjs.com/package/[@go](https://github.com/go)-task/cli)).
- Add support to marking tasks and includes as internal, which will hide them from `--list` and `--list-all` ([#818](https://github.com/go-task/task/issues/818)).
## v3.15.2 - 2022-09-08
- Fix error when using variable in `env:` introduced in the previous release ([#858](https://github.com/go-task/task/issues/858), [#866](https://github.com/go-task/task/issues/866)).
- Fix handling of `CLI_ARGS` (`--`) in Bash completion ([#863](https://github.com/go-task/task/issues/863)).
- On zsh completion, add ability to replace `--list-all` with `--list` as already possible on the Bash completion ([#861](https://github.com/go-task/task/issues/861)).
## v3.15.0 - 2022-09-03
- Add new special variables `ROOT_DIR` and `TASKFILE_DIR`. This was a highly requested feature ([#215](https://github.com/go-task/task/issues/215), [#857](https://github.com/go-task/task/issues/857), [Documentation](https://taskfile.dev/api/#special-variables)).
- Follow symlinks on `sources` ([#826](https://github.com/go-task/task/issues/826), [#831](https://github.com/go-task/task/issues/831)).
- Improvements and fixes to Bash completion ([#835](https://github.com/go-task/task/issues/835), [#844](https://github.com/go-task/task/issues/844)).
## v3.14.1 - 2022-08-03
- Always resolve relative include paths relative to the including Taskfile ([#822](https://github.com/go-task/task/issues/822), [#823](https://github.com/go-task/task/issues/823)).
- Fix ZSH and PowerShell completions to consider all tasks instead of just the public ones (those with descriptions) ([#803](https://github.com/go-task/task/issues/803)).
## v3.14.0 - 2022-07-08
- Add ability to override the `.task` directory location with the `TASK_TEMP_DIR` environment variable.
- Allow to override Task colors using environment variables: `TASK_COLOR_RESET`, `TASK_COLOR_BLUE`, `TASK_COLOR_GREEN`, `TASK_COLOR_CYAN`, `TASK_COLOR_YELLOW`, `TASK_COLOR_MAGENTA` and `TASK_COLOR_RED` ([#568](https://github.com/go-task/task/issues/568), [#792](https://github.com/go-task/task/issues/792)).
- Fixed bug when using the `output: group` mode where STDOUT and STDERR were being print in separated blocks instead of in the right order ([#779](https://github.com/go-task/task/issues/779)).
- Starting on this release, ARM architecture binaries are been released to Snap as well ([#795](https://github.com/go-task/task/issues/795)).
- i386 binaries won't be available anymore on Snap because Ubuntu removed the support for this architecture.
- Upgrade mvdan.cc/sh, which fixes a bug with associative arrays ([#785](https://github.com/go-task/task/issues/785), [mvdan/sh\[#884\](https://github.com/go-task/task/issues/884)](https://github.com/mvdan/sh/issues/884), [mvdan/sh\[#893\](https://github.com/go-task/task/issues/893)](https://github.com/mvdan/sh/pull/893)).
## v3.13.0 - 2022-06-13
- Added `-n` as an alias to `--dry` ([#776](https://github.com/go-task/task/issues/776), [#777](https://github.com/go-task/task/issues/777)).
- Fix behavior of interrupt (SIGINT, SIGTERM) signals. Task will now give time for the processes running to do cleanup work ([#458](https://github.com/go-task/task/issues/458), [#479](https://github.com/go-task/task/issues/479), [#728](https://github.com/go-task/task/issues/728), [#769](https://github.com/go-task/task/issues/769)).
- Add new `--exit-code` (`-x`) flag that will pass-through the exit form the command being ran ([#755](https://github.com/go-task/task/issues/755)).
## v3.12.1 - 2022-05-10
- Fixed bug where, on Windows, variables were ending with `\r` because we were only removing the final `\n` but not `\r\n` ([#717](https://github.com/go-task/task/issues/717)).
## v3.12.0 - 2022-03-31
- The `--list` and `--list-all` flags can now be combined with the `--silent` flag to print the task names only, without their description ([#691](https://github.com/go-task/task/issues/691)).
- Added support for multi-level inclusion of Taskfiles. This means that included Taskfiles can also include other Taskfiles. Before this was limited to one level ([#390](https://github.com/go-task/task/issues/390), [#623](https://github.com/go-task/task/issues/623), [#656](https://github.com/go-task/task/issues/656)).
- Add ability to specify vars when including a Taskfile. [Check out the documentation](https://taskfile.dev/#/usage?id=vars-of-included-taskfiles) for more information ([#677](https://github.com/go-task/task/issues/677)).
## v3.11.0 - 2022-02-19
- Task now supports printing begin and end messages when using the `group` output mode, useful for grouping tasks in CI systems. [Check out the documentation](http://taskfile.dev/#/usage?id=output-syntax) for more information ([#647](https://github.com/go-task/task/issues/647), [#651](https://github.com/go-task/task/issues/651)).
- Add `Taskfile.dist.yml` and `Taskfile.dist.yaml` to the supported file name list. [Check out the documentation](https://taskfile.dev/#/usage?id=supported-file-names) for more information ([#498](https://github.com/go-task/task/issues/498), [#666](https://github.com/go-task/task/issues/666)).
## v3.10.0 - 2022-01-04
- A new `--list-all` (alias `-a`) flag is now available. It's similar to the exiting `--list` (`-l`) but prints all tasks, even those without a description ([#383](https://github.com/go-task/task/issues/383), [#401](https://github.com/go-task/task/issues/401)).
- It's now possible to schedule cleanup commands to run once a task finishes with the `defer:` keyword ([Documentation](https://taskfile.dev/#/usage?id=doing-task-cleanup-with-defer), [#475](https://github.com/go-task/task/issues/475), [#626](https://github.com/go-task/task/issues/626)).
- Remove long deprecated and undocumented `$` variable prefix and `^` command prefix ([#642](https://github.com/go-task/task/issues/642), [#644](https://github.com/go-task/task/issues/644), [#645](https://github.com/go-task/task/issues/645)).
- Add support for `.yaml` extension (as an alternative to `.yml`). This was requested multiple times throughout the years. Enjoy! ([#183](https://github.com/go-task/task/issues/183), [#184](https://github.com/go-task/task/issues/184), [#369](https://github.com/go-task/task/issues/369), [#584](https://github.com/go-task/task/issues/584), [#621](https://github.com/go-task/task/issues/621)).
- Fixed error when computing a variable when the task directory do not exist yet ([#481](https://github.com/go-task/task/issues/481), [#579](https://github.com/go-task/task/issues/579)).
## v3.9.2 - 2021-12-02
- Upgrade [mvdan/sh](https://github.com/mvdan/sh) which contains a fix a for a important regression on Windows ([#619](https://github.com/go-task/task/issues/619), [mvdan/sh\[#768\](https://github.com/go-task/task/issues/768)](https://github.com/mvdan/sh/issues/768), [mvdan/sh\[#769\](https://github.com/go-task/task/issues/769)](https://github.com/mvdan/sh/pull/769)).
## v3.9.1 - 2021-11-28
- Add logging in verbose mode for when a task starts and finishes ([#533](https://github.com/go-task/task/issues/533), [#588](https://github.com/go-task/task/issues/588)).
- Fix an issue with preconditions and context errors ([#597](https://github.com/go-task/task/issues/597), [#598](https://github.com/go-task/task/issues/598)).
- Quote each `{{.CLI_ARGS}}` argument to prevent one with spaces to become many ([#613](https://github.com/go-task/task/issues/613)).
- Fix nil pointer when `cmd:` was left empty ([#612](https://github.com/go-task/task/issues/612), [#614](https://github.com/go-task/task/issues/614)).
- Upgrade [mvdan/sh](https://github.com/mvdan/sh) which contains two relevant fixes:
- Fix quote of empty strings in `shellQuote` ([#609](https://github.com/go-task/task/issues/609), [mvdan/sh\[#763\](https://github.com/go-task/task/issues/763)](https://github.com/mvdan/sh/issues/763)).
- Fix issue of wrong environment variable being picked when there's another very similar one ([#586](https://github.com/go-task/task/issues/586), [mvdan/sh\[#745\](https://github.com/go-task/task/issues/745)](https://github.com/mvdan/sh/pull/745)).
- Install shell completions automatically when installing via Homebrew ([#264](https://github.com/go-task/task/issues/264), [#592](https://github.com/go-task/task/issues/592), [go-task/homebrew-tap\[#2\](https://github.com/go-task/task/issues/2)](https://github.com/go-task/homebrew-tap/pull/2)).
## v3.9.0 - 2021-10-02
- A new `shellQuote` function was added to the template system (`{{shellQuote "a string"}}`) to ensure a string is safe for use in shell ([mvdan/sh\[#727\](https://github.com/go-task/task/issues/727)](https://github.com/mvdan/sh/pull/727), [mvdan/sh\[#737\](https://github.com/go-task/task/issues/737)](https://github.com/mvdan/sh/pull/737), [Documentation](https://pkg.go.dev/mvdan.cc/sh/v3[@v3](https://github.com/v3).4.0/syntax#Quote))
- In this version [mvdan.cc/sh](https://github.com/mvdan/sh) was upgraded with some small fixes and features
- The `read -p` flag is now supported ([#314](https://github.com/go-task/task/issues/314), [mvdan/sh\[#551\](https://github.com/go-task/task/issues/551)](https://github.com/mvdan/sh/issues/551), [mvdan/sh\[#772\](https://github.com/go-task/task/issues/772)](https://github.com/mvdan/sh/pull/722))
- The `pwd -P` and `pwd -L` flags are now supported ([#553](https://github.com/go-task/task/issues/553), [mvdan/sh\[#724\](https://github.com/go-task/task/issues/724)](https://github.com/mvdan/sh/issues/724), [mvdan/sh\[#728\](https://github.com/go-task/task/issues/728)](https://github.com/mvdan/sh/pull/728))
- The `$GID` environment variable is now correctly being set ([#561](https://github.com/go-task/task/issues/561), [mvdan/sh\[#723\](https://github.com/go-task/task/issues/723)](https://github.com/mvdan/sh/pull/723))
## v3.8.0 - 2021-09-26
- Add `interactive: true` setting to improve support for interactive CLI apps ([#217](https://github.com/go-task/task/issues/217), [#563](https://github.com/go-task/task/issues/563)).
- Fix some `nil` errors ([#534](https://github.com/go-task/task/issues/534), [#573](https://github.com/go-task/task/issues/573)).
- Add ability to declare an included Taskfile as optional ([#519](https://github.com/go-task/task/issues/519), [#552](https://github.com/go-task/task/issues/552)).
- Add support for including Taskfiles in the home directory by using `~` ([#539](https://github.com/go-task/task/issues/539), [#557](https://github.com/go-task/task/issues/557)).
## v3.7.3 - 2021-09-04
- Add official support to Apple M1 ([#564](https://github.com/go-task/task/issues/564), [#567](https://github.com/go-task/task/issues/567)).
- Our [official Homebrew tap](https://github.com/go-task/homebrew-tap) will support more platforms, including Apple M1
## v3.7.0 - 2021-07-31
- Add `run:` setting to control if tasks should run multiple times or not. Available options are `always` (the default), `when_changed` (if a variable modified the task) and `once` (run only once no matter what). This is a long time requested feature. Enjoy! ([#53](https://github.com/go-task/task/issues/53), [#359](https://github.com/go-task/task/issues/359)).
## v3.6.0 - 2021-07-10
- Allow using both `sources:` and `status:` in the same task ([#411](https://github.com/go-task/task/issues/411), [#427](https://github.com/go-task/task/issues/427), [#477](https://github.com/go-task/task/issues/477)).
- Small optimization and bug fix: don't compute variables if not needed for `dotenv:` ([#517](https://github.com/go-task/task/issues/517)).
## v3.5.0 - 2021-07-04
- Add support for interpolation in `dotenv:` ([#433](https://github.com/go-task/task/issues/433), [#434](https://github.com/go-task/task/issues/434), [#453](https://github.com/go-task/task/issues/453)).
## v3.4.3 - 2021-05-30
- Add support for the `NO_COLOR` environment variable. ([#459](https://github.com/go-task/task/issues/459), [fatih/color\[#137\](https://github.com/go-task/task/issues/137)](https://github.com/fatih/color/pull/137)).
- Fix bug where sources were not considering the right directory in `--watch` mode ([#484](https://github.com/go-task/task/issues/484), [#485](https://github.com/go-task/task/issues/485)).
## v3.4.2 - 2021-04-23
- On watch, report which file failed to read ([#472](https://github.com/go-task/task/issues/472)).
- Do not try to catch SIGKILL signal, which are not actually possible ([#476](https://github.com/go-task/task/issues/476)).
- Improve version reporting when building Task from source using Go Modules ([#462](https://github.com/go-task/task/issues/462), [#473](https://github.com/go-task/task/issues/473)).
## v3.4.1 - 2021-04-17
- Improve error reporting when parsing YAML: in some situations where you would just see an generic error, you'll now see the actual error with more detail: the YAML line the failed to parse, for example ([#467](https://github.com/go-task/task/issues/467)).
- A JSON Schema was published [here](https://json.schemastore.org/taskfile.json) and is automatically being used by some editors like Visual Studio Code ([#135](https://github.com/go-task/task/issues/135)).
- Print task name before the command in the log output ([#398](https://github.com/go-task/task/issues/398)).
## v3.3.0 - 2021-03-20
- Add support for delegating CLI arguments to commands with `--` and a special `CLI_ARGS` variable ([#327](https://github.com/go-task/task/issues/327)).
- Add a `--concurrency` (alias `-C`) flag, to limit the number of tasks that run concurrently. This is useful for heavy workloads. ([#345](https://github.com/go-task/task/issues/345)).
## v3.2.2 - 2021-01-12
- Improve performance of `--list` and `--summary` by skipping running shell variables for these flags ([#332](https://github.com/go-task/task/issues/332)).
- Fixed a bug where an environment in a Taskfile was not always overridable by the system environment ([#425](https://github.com/go-task/task/issues/425)).
- Fixed environment from .env files not being available as variables ([#379](https://github.com/go-task/task/issues/379)).
- The install script is now working for ARM platforms ([#428](https://github.com/go-task/task/issues/428)).
## v3.2.1 - 2021-01-09
- Fixed some bugs and regressions regarding dynamic variables and directories ([#426](https://github.com/go-task/task/issues/426)).
- The [slim-sprig](https://github.com/go-task/slim-sprig) package was updated with the upstream [sprig](https://github.com/Masterminds/sprig).
## v3.2.0 - 2021-01-07
- Fix the `.task` directory being created in the task directory instead of the Taskfile directory ([#247](https://github.com/go-task/task/issues/247)).
- Fix a bug where dynamic variables (those declared with `sh:`) were not running in the task directory when the task has a custom dir or it was in an included Taskfile ([#384](https://github.com/go-task/task/issues/384)).
- The watch feature (via the `--watch` flag) got a few different bug fixes and should be more stable now ([#423](https://github.com/go-task/task/issues/423), [#365](https://github.com/go-task/task/issues/365)).
## v3.1.0 - 2021-01-03
- Fix a bug when the checksum up-to-date resolution is used by a task with a custom `label:` attribute ([#412](https://github.com/go-task/task/issues/412)).
- Starting from this release, we're releasing official ARMv6 and ARM64 binaries for Linux ([#375](https://github.com/go-task/task/issues/375), [#418](https://github.com/go-task/task/issues/418)).
- Task now respects the order of declaration of included Taskfiles when evaluating variables declaring by them ([#393](https://github.com/go-task/task/issues/393)).
- `set -e` is now automatically set on every command. This was done to fix an issue where multiline string commands wouldn't really fail unless the sentence was in the last line ([#403](https://github.com/go-task/task/issues/403)).
## v3.0.1 - 2020-12-26
- Allow use as a library by moving the required packages out of the `internal` directory ([#358](https://github.com/go-task/task/issues/358)).
- Do not error if a specified dotenv file does not exist ([#378](https://github.com/go-task/task/issues/378), [#385](https://github.com/go-task/task/issues/385)).
- Fix panic when you have empty tasks in your Taskfile ([#338](https://github.com/go-task/task/issues/338), [#362](https://github.com/go-task/task/issues/362)).
## v3.0.0 - 2020-08-16
- On `v3`, all CLI variables will be considered global variables ([#336](https://github.com/go-task/task/issues/336), [#341](https://github.com/go-task/task/issues/341))
- Add support to `.env` like files ([#324](https://github.com/go-task/task/issues/324), [#356](https://github.com/go-task/task/issues/356)).
- Add `label:` to task so you can override the task name in the logs ([\[#321\](https://github.com/go-task/task/issues/321)](https://github.com/go-task/task/issues/321]), [#337](https://github.com/go-task/task/issues/337)).
- Refactor how variables work on version 3 ([#311](https://github.com/go-task/task/issues/311)).
- Disallow `expansions` on v3 since it has no effect.
- `Taskvars.yml` is not automatically included anymore.
- `Taskfile_{{OS}}.yml` is not automatically included anymore.
- Allow interpolation on `includes`, so you can manually include a Taskfile based on operation system, for example.
- Expose `.TASK` variable in templates with the task name ([#252](https://github.com/go-task/task/issues/252)).
- Implement short task syntax ([#194](https://github.com/go-task/task/issues/194), [#240](https://github.com/go-task/task/issues/240)).
- Added option to make included Taskfile run commands on its own directory ([#260](https://github.com/go-task/task/issues/260), [#144](https://github.com/go-task/task/issues/144))
- Taskfiles in version 1 are not supported anymore ([#237](https://github.com/go-task/task/issues/237)).
- Added global `method:` option. With this option, you can set a default method to all tasks in a Taskfile ([#246](https://github.com/go-task/task/issues/246)).
- Changed default method from `timestamp` to `checksum` ([#246](https://github.com/go-task/task/issues/246)).
- New magic variables are now available when using `status:`: `.TIMESTAMP` which contains the greatest modification date from the files listed in `sources:`, and `.CHECKSUM`, which contains a checksum of all files listed in `status:`. This is useful for manual checking when using external, or even remote, artifacts when using `status:` ([#216](https://github.com/go-task/task/issues/216)).
- We're now using [slim-sprig](https://github.com/go-task/slim-sprig) instead of [sprig](https://github.com/Masterminds/sprig), which allowed a file size reduction of about 22% ([#219](https://github.com/go-task/task/issues/219)).
- We now use some colors on Task output to better distinguish message types - commands are green, errors are red, etc ([#207](https://github.com/go-task/task/issues/207)).
## v2.8.1 - 2020-05-20
- Fix error code for the `--help` flag ([#300](https://github.com/go-task/task/issues/300), [#330](https://github.com/go-task/task/issues/330)).
- Print version to stdout instead of stderr ([#299](https://github.com/go-task/task/issues/299), [#329](https://github.com/go-task/task/issues/329)).
- Supress `context` errors when using the `--watch` flag ([#313](https://github.com/go-task/task/issues/313), [#317](https://github.com/go-task/task/issues/317)).
- Support templating on description ([#276](https://github.com/go-task/task/issues/276), [#283](https://github.com/go-task/task/issues/283)).
## v2.8.0 - 2019-12-07
- Add `--parallel` flag (alias `-p`) to run tasks given by the command line in parallel ([#266](https://github.com/go-task/task/issues/266)).
- Fixed bug where calling the `task` CLI only informing global vars would not execute the `default` task.
- Add hability to silent all tasks by adding `silent: true` a the root of the Taskfile.
## v2.7.1 - 2019-11-10
- Fix error being raised when `exit 0` was called ([#251](https://github.com/go-task/task/issues/251)).
## v2.7.0 - 2019-09-22
- Fixed panic bug when assigning a global variable ([#229](https://github.com/go-task/task/issues/229), [#243](https://github.com/go-task/task/issues/243)).
- A task with `method: checksum` will now re-run if generated files are deleted ([#228](https://github.com/go-task/task/issues/228), [#238](https://github.com/go-task/task/issues/238)).
## v2.6.0 - 2019-07-21
- Fixed some bugs regarding minor version checks on `version:`.
- Add `preconditions:` to task ([#205](https://github.com/go-task/task/issues/205)).
- Create directory informed on `dir:` if it doesn't exist ([#209](https://github.com/go-task/task/issues/209), [#211](https://github.com/go-task/task/issues/211)).
- We now have a `--taskfile` flag (alias `-t`), which can be used to run another Taskfile (other than the default `Taskfile.yml`) ([#221](https://github.com/go-task/task/issues/221)).
- It's now possible to install Task using Homebrew on Linux ([go-task/homebrew-tap\[#1\](https://github.com/go-task/task/issues/1)](https://github.com/go-task/homebrew-tap/pull/1)).
## v2.5.2 - 2019-05-11
- Reverted YAML upgrade due issues with CRLF on Windows ([#201](https://github.com/go-task/task/issues/201), [go-yaml/yaml\[#450\](https://github.com/go-task/task/issues/450)](https://github.com/go-yaml/yaml/issues/450)).
- Allow setting global variables through the CLI ([#192](https://github.com/go-task/task/issues/192)).
## 2.5.1 - 2019-04-27
- Fixed some issues with interactive command line tools, where sometimes the output were not being shown, and similar issues ([#114](https://github.com/go-task/task/issues/114), [#190](https://github.com/go-task/task/issues/190), [#200](https://github.com/go-task/task/issues/200)).
- Upgraded [go-yaml/yaml](https://github.com/go-yaml/yaml) from v2 to v3.
## v2.5.0 - 2019-03-16
- We moved from the taskfile.org domain to the new fancy taskfile.dev domain. While stuff is being redirected, we strongly recommend to everyone that use [this install script](https://taskfile.dev/#/installation?id=install-script) to use the new taskfile.dev domain on scripts from now on.
- Fixed to the ZSH completion ([#182](https://github.com/go-task/task/issues/182)).
- Add [`--summary` flag along with `summary:` task attribute](https://taskfile.org/#/usage?id=display-summary-of-task) ([#180](https://github.com/go-task/task/issues/180)).
## v2.4.0 - 2019-02-21
- Allow calling a task of the root Taskfile from an included Taskfile by prefixing it with `:` ([#161](https://github.com/go-task/task/issues/161), [#172](https://github.com/go-task/task/issues/172)).
- Add flag to override the `output` option ([#173](https://github.com/go-task/task/issues/173)).
- Fix bug where Task was persisting the new checksum on the disk when the Dry Mode is enabled ([#166](https://github.com/go-task/task/issues/166)).
- Fix file timestamp issue when the file name has spaces ([#176](https://github.com/go-task/task/issues/176)).
- Mitigating path expanding issues on Windows ([#170](https://github.com/go-task/task/issues/170)).
## v2.3.0 - 2019-01-02
- On Windows, Task can now be installed using [Scoop](https://scoop.sh/) ([#152](https://github.com/go-task/task/issues/152)).
- Fixed issue with file/directory globing ([#153](https://github.com/go-task/task/issues/153)).
- Added ability to globally set environment variables ([#138](https://github.com/go-task/task/issues/138), [#159](https://github.com/go-task/task/issues/159)).
## v2.2.1 - 2018-12-09
- This repository now uses Go Modules ([#143](https://github.com/go-task/task/issues/143)). We'll still keep the `vendor` directory in sync for some time, though;
- Fixing a bug when the Taskfile has no tasks but includes another Taskfile ([#150](https://github.com/go-task/task/issues/150));
- Fix a bug when calling another task or a dependency in an included Taskfile ([#151](https://github.com/go-task/task/issues/151)).
## v2.2.0 - 2018-10-25
- Added support for [including other Taskfiles](https://taskfile.org/#/usage?id=including-other-taskfiles) ([#98](https://github.com/go-task/task/issues/98))
- This should be considered experimental. For now, only including local files is supported, but support for including remote Taskfiles is being discussed. If you have any feedback, please comment on [#98](https://github.com/go-task/task/issues/98).
- Task now have a dedicated documentation site: https://taskfile.org
- Thanks to [Docsify](https://docsify.js.org/) for making this pretty easy. To check the source code, just take a look at the [docs](https://github.com/go-task/task/tree/main/docs) directory of this repository. Contributions to the documentation is really appreciated.
## v2.1.1 - 2018-09-17
- Fix suggestion to use `task --init` not being shown anymore (when a `Taskfile.yml` is not found)
- Fix error when using checksum method and no file exists for a source glob ([#131](https://github.com/go-task/task/issues/131))
- Fix signal handling when the `--watch` flag is given ([#132](https://github.com/go-task/task/issues/132))
## v2.1.0 - 2018-08-19
- Add a `ignore_error` option to task and command ([#123](https://github.com/go-task/task/issues/123))
- Add a dry run mode (`--dry` flag) ([#126](https://github.com/go-task/task/issues/126))
## v2.0.3 - 2018-06-24
- Expand environment variables on "dir", "sources" and "generates" ([#116](https://github.com/go-task/task/issues/116))
- Fix YAML merging syntax ([#112](https://github.com/go-task/task/issues/112))
- Add ZSH completion ([#111](https://github.com/go-task/task/issues/111))
- Implement new `output` option. Please check out the [documentation](https://github.com/go-task/task#output-syntax)
## v2.0.2 - 2018-05-01
- Fix merging of YAML anchors ([#112](https://github.com/go-task/task/issues/112))
## v2.0.1 - 2018-03-11
- Fixes panic on `task --list`
## v2.0.0 - 2018-03-08
Version 2.0.0 is here, with a new Taskfile format.
Please, make sure to read the [Taskfile versions](https://github.com/go-task/task/blob/main/TASKFILE_VERSIONS.md) document, since it describes in depth what changed for this version.
- New Taskfile version 2 ([#77](https://github.com/go-task/task/issues/77))
- Possibility to have global variables in the `Taskfile.yml` instead of `Taskvars.yml` ([#66](https://github.com/go-task/task/issues/66))
- Small improvements and fixes
## v1.4.4 - 2017-11-19
- Handle SIGINT and SIGTERM ([#75](https://github.com/go-task/task/issues/75));
- List: print message with there's no task with description;
- Expand home dir ("~" symbol) on paths ([#74](https://github.com/go-task/task/issues/74));
- Add Snap as an installation method;
- Move examples to its own repo;
- Watch: also walk on tasks called on on "cmds", and not only on "deps";
- Print logs to stderr instead of stdout ([#68](https://github.com/go-task/task/issues/68));
- Remove deprecated `set` keyword;
- Add checksum based status check, alternative to timestamp based.
## v1.4.3 - 2017-09-07
- Allow assigning variables to tasks at run time via CLI ([#33](https://github.com/go-task/task/issues/33))
- Added suport for multiline variables from sh ([#64](https://github.com/go-task/task/issues/64))
- Fixes env: remove square braces and evaluate shell ([#62](https://github.com/go-task/task/issues/62))
- Watch: change watch library and few fixes and improvements
- When use watching, cancel and restart long running process on file change ([#59](https://github.com/go-task/task/issues/59) and [#60](https://github.com/go-task/task/issues/60))
## v1.4.2 - 2017-07-30
- Flag to set directory of execution
- Always echo command if is verbose mode
- Add silent mode to disable echoing of commands
- Fixes and improvements of variables ([#56](https://github.com/go-task/task/issues/56))
## v1.4.1 - 2017-07-15
- Allow use of YAML for dynamic variables instead of $ prefix
- `VAR: {sh: echo Hello}` instead of `VAR: $echo Hello`
- Add `--list` (or `-l`) flag to print existing tasks
- OS specific Taskvars file (e.g. `Taskvars_windows.yml`, `Taskvars_linux.yml`, etc)
- Consider task up-to-date on equal timestamps ([#49](https://github.com/go-task/task/issues/49))
- Allow absolute path in generates section ([#48](https://github.com/go-task/task/issues/48))
- Bugfix: allow templating when calling deps ([#42](https://github.com/go-task/task/issues/42))
- Fix panic for invalid task in cyclic dep detection
- Better error output for dynamic variables in Taskvars.yml ([#41](https://github.com/go-task/task/issues/41))
- Allow template evaluation in parameters
## v1.4.0 - 2017-07-06
- Cache dynamic variables
- Add verbose mode (`-v` flag)
- Support to task parameters (overriding vars) ([#31](https://github.com/go-task/task/issues/31)) ([#32](https://github.com/go-task/task/issues/32))
- Print command, also when "set:" is specified ([#35](https://github.com/go-task/task/issues/35))
- Improve task command help text ([#35](https://github.com/go-task/task/issues/35))
## v1.3.1 - 2017-06-14
- Fix glob not working on commands ([#28](https://github.com/go-task/task/issues/28))
- Add ExeExt template function
- Add `--init` flag to create a new Taskfile
- Add status option to prevent task from running ([#27](https://github.com/go-task/task/issues/27))
- Allow interpolation on `generates` and `sources` attributes ([#26](https://github.com/go-task/task/issues/26))
## v1.3.0 - 2017-04-24
- Migrate from os/exec.Cmd to a native Go sh/bash interpreter
- This is a potentially breaking change if you use Windows.
- Now, `cmd` is not used anymore on Windows. Always use Bash-like syntax for your commands, even on Windows.
- Add "ToSlash" and "FromSlash" to template functions
- Use functions defined on github.com/Masterminds/sprig
- Do not redirect stdin while running variables commands
- Using `context` and `errgroup` packages (this will make other tasks to be cancelled, if one returned an error)
## v1.2.0 - 2017-04-02
- More tests and Travis integration
- Watch a task (experimental)
- Possibility to call another task
- Fix "=" not being reconized in variables/environment variables
- Tasks can now have a description, and help will print them ([#10](https://github.com/go-task/task/issues/10))
- Task dependencies now run concurrently
- Support for a default task ([#16](https://github.com/go-task/task/issues/16))
## v1.1.0 - 2017-03-08
- Support for YAML, TOML and JSON ([#1](https://github.com/go-task/task/issues/1))
- Support running command in another directory ([#4](https://github.com/go-task/task/issues/4))
- `--force` or `-f` flag to force execution of task even when it's up-to-date
- Detection of cyclic dependencies ([#5](https://github.com/go-task/task/issues/5))
- Support for variables ([#6](https://github.com/go-task/task/issues/6), [#9](https://github.com/go-task/task/issues/9), [#14](https://github.com/go-task/task/issues/14))
- Operation System specific commands and variables ([#13](https://github.com/go-task/task/issues/13))
## v1.0.0 - 2017-02-28
- Add LICENSE file

View File

@@ -0,0 +1,33 @@
---
slug: /community/
sidebar_position: 9
---
# Community
Some of the work to improve the Task ecosystem is done by the community, be it installation methods or integrations with code editor. I (the author) am thankful for everyone that helps me to improve the overall experience.
## Translations
We use [Crowdin](https://crowdin.com/project/taskfile) to translate our document.
## Integrations
Many of our integrations are contributed and maintained by the community. You can view the full list of community integrations [here](/integrations#community-integrations).
## Installation methods
Some installation methods are maintained by third party:
- [GitHub Actions](https://github.com/arduino/setup-task) by [@arduino](https://github.com/arduino)
- [AUR](https://aur.archlinux.org/packages/go-task-bin) by [@carlsmedstad](https://github.com/carlsmedstad)
- [Scoop](https://github.com/ScoopInstaller/Main/blob/master/bucket/task.json)
- [Fedora](https://packages.fedoraproject.org/pkgs/golang-github-task/go-task/)
- [NixOS](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/go-task/default.nix)
- [Conda](https://github.com/conda-forge/go-task-feedstock/)
## More
Also, thanks for all the [code contributors](https://github.com/go-task/task/graphs/contributors), [financial contributors](https://opencollective.com/task), all those who [reported bugs](https://github.com/go-task/task/issues?q=is%3Aissue) and [answered questions](https://github.com/go-task/task/discussions).
If you know something that is missing in this document, please submit a pull request.

View File

@@ -0,0 +1,101 @@
---
slug: /contributing/
sidebar_position: 11
---
# コントリビュート
Contributions to Task are very welcome, but we ask that you read this document before submitting a PR.
:::note
This document applies to the core [Task][task] repository _and_ [Task for Visual Studio Code][vscode-task].
:::
## 始める前に
- **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. セットアップ
- **Go** - Taskは[Go][go]で書かれています。 We always support the latest two major Go versions, so make sure your version is recent enough.
- **Node.js** - [Node.js][nodejs] is used to host Task's documentation server and is required if you want to run this server locally. It is also required if you want to contribute to the Visual Studio Code extension.
- **Yarn** - [Yarn][yarn] is the Node.js package manager used by Task.
## 2. 変更を加える
- **Code style** - Try to maintain the existing code style where possible. Go code should be formatted by [`gofumpt`][gofumpt] and linted using [`golangci-lint`][golangci-lint]. Any Markdown or TypeScript files should be formatted and linted by [Prettier][prettier]. This style is enforced by our CI to ensure that we have a consistent style across the project. You can use the `task lint` command to lint the code locally and the `task lint:fix` command to automatically fix any issues that are found.
- **Documentation** - Ensure that you add/update any relevant documentation. See the [updating documentation](#updating-documentation) section below.
- **Tests** - Ensure that you add/update any relevant tests and that all tests are passing before submitting the PR. See the [writing tests](#writing-tests) section below.
### Running your changes
To run Task with working changes, you can use `go run ./cmd/task`. To run a development build of task against a test Taskfile in `testdata`, you can use `go run ./cmd/task --dir ./testdata/<my_test_dir> <task_name>`.
To run Task for Visual Studio Code, you can open the project in VSCode and hit F5 (or whatever you debug keybind is set to). This will open a new VSCode window with the extension running. Debugging this way is recommended as it will allow you to set breakpoints and step through the code. Otherwise, you can run `task package` which will generate a `.vsix` file that can be used to manually install the extension.
### ドキュメントの更新
Task uses [Docusaurus][docusaurus] to host a documentation server. The code for this is located in the core Task repository. This can be setup and run locally by using `task docs` (requires `nodejs` & `yarn`). All content is written in Markdown and is located in the `docs/docs` directory. All Markdown documents should have an 80 character line wrap limit (enforced by Prettier).
When making a change, consider whether a change to the [Usage Guide](./usage.md) is necessary. This document contains descriptions and examples of how to use Task features. If you're adding a new feature, try to find an appropriate place to add a new section. If you're updating an existing feature, ensure that the documentation and any examples are up-to-date. Ensure that any examples follow the [Taskfile Styleguide](./styleguide.md).
If you added a new field, command or flag, ensure that you add it to the [API Reference](./api_reference.md). New fields also need to be added to the [JSON Schema][json-schema]. The descriptions for fields in the API reference and the schema should match.
### Writing tests
A lot of Task's tests are held in the `task_test.go` file in the project root and this is where you'll most likely want to add new ones too. Most of these tests also have a subdirectory in the `testdata` directory where any Taskfiles/data required to run the tests are stored.
When making a changes, consider whether new tests are required. These tests should ensure that the functionality you are adding will continue to work in the future. Existing tests may also need updating if you have changed Task's behavior.
You may also consider adding unit tests for any new functions you have added. The unit tests should follow the Go convention of being location in a file named `*_test.go` in the same package as the code being tested.
## 3. Committing your code
Try to write meaningful commit messages and avoid having too many commits on the PR. Most PRs should likely have a single commit (although for bigger PRs it may be reasonable to split it in a few). Git squash and rebase is your friend!
If you're not sure how to format your commit message, check out [Conventional Commits][conventional-commits]. This style is not enforced, but it is a good way to make your commit messages more readable and consistent.
## 4. Submitting a PR
- **Describe your changes** - Ensure that you provide a comprehensive description of your changes.
- **Issue/PR links** - Link any previous work such as related issues or PRs. Please describe how your changes differ to/extend this work.
- **Examples** - Add any examples or screenshots that you think are useful to demonstrate the effect of your changes.
- **Draft PRs** - If your changes are incomplete, but you would like to discuss them, open the PR as a draft and add a comment to start a discussion. Using comments rather than the PR description allows the description to be updated later while preserving any discussions.
## FAQ
> コントリビュートしたいのですが、どうすればいいですか?
Take a look at the list of [open issues for Task][task-open-issues] or [Task for Visual Studio Code][vscode-task-open-issues]. We have a [good first issue][good-first-issue] label for simpler issues that are ideal for first time contributions.
All kinds of contributions are welcome, whether its a typo fix or a shiny new feature. You can also contribute by upvoting/commenting on issues, helping to answer questions or contributing to other [community projects](./community.md).
> I'm stuck, where can I get help?
If you have questions, feel free to ask them in the `#help` forum channel on our [Discord server][discord-server] or open a [Discussion][discussion] on GitHub.
---
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[task]: https://github.com/go-task/task
[vscode-task]: https://github.com/go-task/vscode-task
[go]: https://go.dev
[gofumpt]: https://github.com/mvdan/gofumpt
[golangci-lint]: https://golangci-lint.run
[prettier]: https://prettier.io
[nodejs]: https://nodejs.org/en/
[yarn]: https://yarnpkg.com/
[docusaurus]: https://docusaurus.io
[json-schema]: https://github.com/go-task/task/blob/main/docs/static/schema.json
[task-open-issues]: https://github.com/go-task/task/issues
[vscode-task-open-issues]: https://github.com/go-task/vscode-task/issues
[good-first-issue]: https://github.com/go-task/task/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22
[discord-server]: https://discord.gg/6TY36E39UK
[discussion]: https://github.com/go-task/task/discussions
[conventional-commits]: https://www.conventionalcommits.org

View File

@@ -0,0 +1,12 @@
---
slug: /deprecations/
sidebar_position: 7
---
# Deprecations
As Task evolves, it occasionally outgrows some of its functionality. This can be because they are no longer useful, because another feature has replaced it or because of a change in the way that Task works internally.
When this happens, we mark the functionality as deprecated. This means that it will be removed in a future version of Task. This functionality will continue to work until that time, but we strongly recommend that you do not implement this functionality in new Taskfiles and make a plan to migrate away from it as soon as possible.
You can view a full list of active deprecations in the "Deprecations" section of the sidebar.

View File

@@ -0,0 +1,17 @@
---
#This is a template for an experiments documentation
#Copy this page and fill in the details as necessary
title: '--- Template ---'
sidebar_position: -1 #Always push to the top
draft: true #Hide in production
---
# {Name of Deprecated Feature}
- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
- Breaks:
- {list any existing functionality that will be broken by this experiment}
{Short description of the feature/behavior and why it is being deprecated}
{Short explanation of any replacement features/behaviors and how users should migrate to it}

View File

@@ -0,0 +1,22 @@
---
slug: /deprecations/version-2-schema/
---
# Version 2 Schema
- Issue: [#1197][deprecate-version-2-schema]
- Breaks:
- Any Taskfiles that use the version 2 schema
- `Taskvar.yml` files
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

View File

@@ -0,0 +1,44 @@
---
slug: /donate/
sidebar_position: 16
---
# 寄付
If you find this project useful, you can consider donating by using one of the channels listed below.
This is just a way of saying "thank you", it won't give you any benefits like higher priority on issues or something similar.
Companies who donate at least $50/month will be featured as a "Gold Sponsor" in the website homepage and on the GitHub repository README. Make contact with [@andreynering][] with the logo you want to be shown. Suspect businesses (gambling, casinos, etc) won't be allowed, though.
## GitHub Sponsors
The preferred way to donate to the maintainers is via GitHub Sponsors. Just use the following links to do your donation:
- [@andreynering](https://github.com/sponsors/andreynering)
- [@pd93](https://github.com/sponsors/pd93)
## Open Collective
If you prefer [Open Collective](https://opencollective.com/task) you can donate by using these links:
- [$2 per month](https://opencollective.com/task/contribute/backer-4034/checkout)
- [$5 per month](https://opencollective.com/task/contribute/supporter-8404/checkout)
- [$20 per month](https://opencollective.com/task/contribute/sponsor-4035/checkout)
- [$50 per month](https://opencollective.com/task/contribute/sponsor-28775/checkout)
- [Custom value - One-time donation option supported](https://opencollective.com/task/donate)
## PayPal
You can donate to [@andreynering][] via PayPal as well:
- [Any value - One-time donation](https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=GSVDU63RKG45A&currency_code=USD&source=url)
## PIX (ブラジルのみ)
And if you're Brazilian, you can also donate to [@andreynering][] via PIX by [using this QR Code](/img/pix.png).
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[@andreynering]: https://github.com/andreynering

View File

@@ -0,0 +1,78 @@
---
slug: /experiments/
sidebar_position: 6
---
# 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 their status in the [workflow](#workflow).
You can view a full list of active experiments in the "Experiments" section of the sidebar.
You can enable an experimental feature by:
1. Using the relevant environment variable in front of a task command. For example, `TASK_X_{FEATURE}=1 task {my-task}`. This is intended for one-off invocations of Task to test out experimental features.
1. Using the relevant environment variable in your "dotfiles" (e.g. `.bashrc`, `.zshrc` etc.). This is intended for permanently enabling experimental features in your environment.
1. Creating a `.env` file in the same directory as your root Taskfile that contains the relevant environment variables. e.g.
```shell
# .env
TASK_X_FEATURE=1
```
## 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.
## 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

View File

@@ -0,0 +1,21 @@
---
slug: /experiments/gentle-force/
---
# Gentle Force
- Issue: [#1200][gentle-force-experiment]
- Environment variable: `TASK_X_FORCE=1`
- Breaks:
- `--force` flag
The `--force` flag currently forces _all_ tasks to run regardless of the status checks. This can be useful, but we have found that most of the time users only expect the direct task they are calling to be forced and _not_ all of its dependant tasks.
This experiment changes the `--force` flag to only force the directly called task. All dependant tasks will have their statuses checked as normal and will only run if Task considers them to be out of date. A new `--force-all` flag will also be added to maintain the current behavior for users that need this functionality.
If you want to migrate, but continue to force all dependant tasks to run, you should replace all uses of the `--force` flag with `--force-all`. Alternatively, if you want to adopt the new behavior, you can continue to use the `--force` flag as you do now!
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[gentle-force-experiment]: https://github.com/go-task/task/issues/1200

View File

@@ -0,0 +1,54 @@
---
slug: /experiments/remote-taskfiles/
---
# Remote Taskfiles
- Issue: [#1317][remote-taskfiles-experiment]
- Environment variable: `TASK_X_REMOTE_TASKFILES=1`
This experiment allows you to specify a remote Taskfile URL when including a Taskfile. For example:
```yaml
version: '3'
include:
my-remote-namespace: https://raw.githubusercontent.com/my-org/my-repo/main/Taskfile.yml
```
This works exactly the same way that including a local file does. Any tasks in the remote Taskfile will be available to run from your main Taskfile via the namespace `my-remote-namespace`. For example, if the remote file contains the following:
```yaml
version: '3'
tasks:
hello:
silent: true
cmds:
- echo "Hello from the remote Taskfile!"
```
and you run `task my-remote-namespace:hello`, it will print the text: "Hello from the remote Taskfile!" to your console.
## Security
Running commands from sources that you do not control is always a potential security risk. For this reason, we have added some checks when using remote Taskfiles:
1. When running a task from a remote Taskfile for the first time, Task will print a warning to the console asking you to check that you are sure that you trust the source of the Taskfile. If you do not accept the prompt, then Task will exit with code `104` (not trusted) and nothing will run. If you accept the prompt, the remote Taskfile will run and further calls to the remote Taskfile will not prompt you again.
2. Whenever you run a remote Taskfile, Task will create and store a checksum of the file that you are running. If the checksum changes, then Task will print another warning to the console to inform you that the contents of the remote file has changed. If you do not accept the prompt, then Task will exit with code `104` (not trusted) and nothing will run. If you accept the prompt, the checksum will be updated and the remote Taskfile will run.
Task currently supports both `http` and `https` URLs. However, the `http` requests will not execute by default unless you run the task with the `--insecure` flag. This is to protect you from accidentally running a remote Taskfile that is hosted on and unencrypted connection. Sources that are not protected by TLS are vulnerable to [man-in-the-middle attacks][man-in-the-middle-attacks] and should be avoided unless you know what you are doing.
## Caching & Running Offline
If for whatever reason, you don't have access to the internet, but you still need to be able to run your tasks, you are able to use the `--download` flag to store a cached copy of the remote Taskfile.
<!-- TODO: The following behavior may change -->
If Task detects that you have a local copy of the remote Taskfile, it will use your local copy instead of downloading the remote file. You can force Task to work offline by using the `--offline` flag. This will prevent Task from making any calls to remote sources.
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317
[man-in-the-middle-attacks]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack

View File

@@ -0,0 +1,20 @@
---
#This is a template for an experiments documentation
#Copy this page and fill in the details as necessary
title: '--- Template ---'
sidebar_position: -1 #Always push to the top
draft: true #Hide in production
---
# {Name of Experiment}
- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
- Environment variable: `TASK_X_{feature}`
- Breaks:
- {list any existing functionality that will be broken by this experiment}
- Deprecations:
- {link to any deprecation pages related to this experiment}
{Short description of the feature}
{Short explanation of how users should migrate to the new behavior}

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

View File

@@ -0,0 +1,89 @@
---
slug: /faq/
sidebar_position: 15
---
# FAQ
このページはTaskに関するよくある質問についてまとめたものです。
## タスクがシェル環境を更新しないのはなぜですか?
これはシェルの仕組みの制限です。 Taskは現在のシェルのサブプロセスとして実行されるため、それを起動したシェルの環境を変更することができません。 この制限は他のタスクランナーやビルドツールでも同様です。
これを回避する一般的な方法は、シェルが解析できる出力を生成するタスクを作成することです。 例えば、シェルの環境変数を設定するには以下のようなタスクを書くことができます:
```yaml
my-shell-env:
cmds:
- echo "export FOO=foo"
- echo "export BAR=bar"
```
そして、`eval $(task my-shell-env)`を実行することで、変数`$FOO``$BAR`がシェルで使用可能になります。
## タスクのコマンドでシェルを再利用できません
Taskはそれぞれのコマンドを異なるシェルプロセスとして実行するため、一つのコマンドが他のコマンドには影響されることはありません。 例えば、以下は上手く動きません:
```yaml
version: '3'
tasks:
foo:
cmds:
- a=foo
- echo $a
# outputs ""
```
これを上手く動かすためには複数行コマンドを利用します:
```yaml
version: '3'
tasks:
foo:
cmds:
- |
a=foo
echo $a
# outputs "foo"
```
もっと複雑なコマンドの場合は、ファイルを用意してそれを呼び出すようにすることを推奨します:
```yaml
version: '3'
tasks:
foo:
cmds:
- ./foo-printer.bash
```
```bash
#!/bin/bash
a=foo
echo $a
```
## 'x'組み込みコマンドがWindowsで動作しません
Windowsのデフォルトシェル(`cmd``powershell`)は、組み込みシェルとして`rm``cp`がありません。 つまり、これらのコマンドは動作しません。 Taskfileをクロスプラットフォームにしたい場合は、次のいずれかの方法で制限を回避する必要があります:
- `{{OS}}`関数を使用して、OS固有のスクリプトを実行する。
- `{{if eq OS "windows"}}powershell {{end}}<my_cmd>`のようにWindowsかを判別して、Powershellを実行する。
- Windowsでこれらのコマンドを組み込みでサポートするシェルを使ってください。例えば[Git Bash][git-bash]または[WSL][wsl]などがあります。
私たちはTaskのこの部分に改善したいと思っており、以下のIssueがそれを追跡するものです。 建設的なコメントやコントリビュートは大歓迎です!
- [#197](https://github.com/go-task/task/issues/197)
- [mvdan/sh#93](https://github.com/mvdan/sh/issues/93)
- [mvdan/sh#97](https://github.com/mvdan/sh/issues/97)
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[git-bash]: https://gitforwindows.org/
[wsl]: https://learn.microsoft.com/en-us/windows/wsl/install

View File

@@ -0,0 +1,266 @@
---
slug: /installation/
sidebar_position: 2
---
# インストール方法
Taskは多くのインストール方法を提供します。 以下にある利用可能な方法を確認してください。
## パッケージマネージャー
### Homebrew
macOSやLinuxを使っていて、[Homebrew][homebrew]をインストールしている場合は、以下を実行することで簡単にTaskをインストールできます:
```bash
brew install go-task/tap/go-task
```
上記のFormulaは[私たちが管理しています](https://github.com/go-task/homebrew-tap/blob/master/Formula/go-task.rb)。
最近、Taskは[公式のHomebrewリポジトリ](https://formulae.brew.sh/formula/go-task)でも利用可能になったので、以下の方法でもインストールできます:
```bash
brew install go-task
```
### Tea
macOSやLinuxを使っていて、[tea][tea]をインストールしている場合は、以下を実行することで簡単にTaskをインストールできます:
```bash
tea task
```
teaの魔法が有効になっている場合:
```bash
task
```
このインストール方法はコミュニティが所有しています。 Taskの新しいリリースが出来た後、自動的にteaが最小限の時間でリリースします。
### Snap
Taskは[ Snapcraft][snapcraft]で提供されていますが、Snapを適切に動作させるためには、あなたのLinux distributionがクラシックな制限を許可することを念頭に置いておいてください:
```bash
sudo snap install task --classic
```
### Chocolatey
Windowsを使っていて、[Chocolatey][choco]をインストールしていれば、以下を実行することで簡単にTaskをインストールできます:
```bash
choco install go-task
```
このインストール方法はコミュニティーが所有しています。
### Scoop
Windowsを使っていて、[Scoop][scoop]をインストールしていれば、以下を実行することで簡単にTaskをインストールできます:
```cmd
scoop install task
```
このインストール方法はコミュニティーが所有しています。 Taskの新しいリリースが出来た後、Scoopで利用可能になるには時間がかかるかもしれません。
### AUR
Arch Linuxを使っていれば、あなたの好きなパッケージマネージャ(`yay``pacaur`、または`yaourt`など)を使って[AUR](https://aur.archlinux.org/packages/go-task-bin)からTaskをインストールできます:
```cmd
yay -S go-task-bin
```
あるいは、[リリースページ](https://github.com/go-task/task/releases)からバイナリをダウンロードする代わりに、ソースコードからインストールする[パッケージ](https://aur.archlinux.org/packages/go-task)もあります:
```cmd
yay -S go-task
```
このインストール方法はコミュニティーが所有しています。
### Fedora
Fedora Linuxを使っている場合、`dnf`を使って、公式の[Fedora](https://packages.fedoraproject.org/pkgs/golang-github-task/go-task/)リポジトリからTaskをインストールできます:
```cmd
sudo dnf install go-task
```
このインストール方法はコミュニティーが所有しています。 Taskの新しいリリースが出来た後、[Fedora](https://packages.fedoraproject.org/pkgs/golang-github-task/go-task/)で利用可能になるには時間がかかるかもしれません。
### Nix
NixOSを使っている場合、またはNixをインストールしている場合、[nixpkgs](https://github.com/NixOS/nixpkgs)からTaskをインストールできます。
```cmd
nix-env -iA nixpkgs.go-task
```
このインストール方法はコミュニティーが所有しています。 Taskの新しいリリースが出来た後、[nixpkgs](https://github.com/NixOS/nixpkgs)で利用可能になるには時間がかかるかもしれません。
### npm
Nodeとnpmを使って[このパッケージ](https://www.npmjs.com/package/@go-task/cli)をインストールすることでTaskをインストールすることもできます。
```bash
npm install -g @go-task/cli
```
### Winget
Windowsを使っていて、[winget](https://github.com/microsoft/winget-cli)パッケージマネジメントツールをインストールしていれば、[winget-pkgs](https://github.com/microsoft/winget-pkgs)からTaskをインストールできます。
```bash
winget install Task.Task
```
## バイナリの取得
### バイナリ
[GitHubのリリースページ][releases]からバイナリをダウンロードして`$PATH`に追加することでインストールできます。
DEBとRPMパッケージも利用可能です。
`task_checksums.txt`ファイルには、各バイナリファイルのSHA-256チェックサムが記載されています。
### スクリプトを使ったインストール
[install script][installscript]もあり、CIのような場面で非常に有用です。 [GoDownloader][godownloader]のおかげで、スクリプトを簡単に生成することができました。
デフォルトでは作業ディレクトリに相対的な`./bin`ディレクトリにインストールされます:
```bash
sh -c "$(curl --location https://taskfile.dev/install.sh)" -- -d
```
`-b`パラメータでインストールディレクトリを上書きすることができます。 Linuxでは、現在のユーザー向けには`~/.local/bin``~/bin`、すべてのユーザー向けには`/usr/local/bin`をインストール先として選択することが一般的です:
```bash
sh -c "$(curl --location https://taskfile.dev/install.sh)" -- -d -b ~/.local/bin
```
:::caution
macOSとWindowsでは`~/.local/bin``~/bin`は、`$PATH`にデフォルトで追加されていません。
:::
### GitHub Actions
GitHub ActionsでTaskをインストールしたい場合、Arduinoチームの[action](https://github.com/arduino/setup-task)を使用してみてください:
```yaml
- name: Install Task
uses: arduino/setup-task@v1
with:
version: 3.x
repo-token: ${{ secrets.GITHUB_TOKEN }}
```
このインストール方法はコミュニティーが所有しています。
## ソースコードからビルド
### Goモジュール
[Go][go]のサポート対象のバージョンが適切にインストールおよびセットアップされていることを確認してください。 Goの必要な最小バージョンは[go.mod](https://github.com/go-task/task/blob/main/go.mod#L3)ファイルから確認できます。
以下を実行することで最新のリリースをグローバルにインストールできます:
```bash
go install github.com/go-task/task/v3/cmd/task@latest
```
別のディレクトリにインストールすることもできます:
```bash
env GOBIN=/bin go install github.com/go-task/task/v3/cmd/task@latest
```
:::tip
CI環境では、最新リリースのバイナリを早く、安定して提供する[install script](#install-script)を使うことをおすすめします。
:::
## 補完のセットアップ
使用しているシェルに対応した自動補完ファイルをダウンロードしてください。
[シェルに対応した自動補完ファイルはTaskリポジトリにあります](https://github.com/go-task/task/tree/main/completion)。
### Bash
まず、パッケージマネージャを使用してbash-completionがインストールされていることを確認します。
補完ファイルを実行可能にします:
```
chmod +x path/to/task.bash
```
その後、以下の行を`~/.bash_profile`に追加してください:
```shell
source path/to/task.bash
```
### ZSH
`_task`ファイルを`$FPATH`のどこかに置きます:
```shell
mv path/to/_task /usr/local/share/zsh/site-functions/_task
```
`~/.zshrc`に以下の内容が含まれていることを確認してください:
```shell
autoload -U compinit
compinit -i
```
ZSHバージョンは5.7以降をおすすめします。
### Fish
` task.fish`補完スクリプトを移動させます:
```shell
mv path/to/task.fish ~/.config/fish/completions/task.fish
```
### PowerShell
プロファイルスクリプトを開きます:
```
mkdir -Path (Split-Path -Parent $profile) -ErrorAction SilentlyContinue
notepad $profile
```
以下の行を追加してファイルを保存します:
```shell
Invoke-Expression -Command path/to/task.ps1
```
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[go]: https://golang.org/
[snapcraft]: https://snapcraft.io/task
[homebrew]: https://brew.sh/
[installscript]: https://github.com/go-task/task/blob/main/install-task.sh
[releases]: https://github.com/go-task/task/releases
[godownloader]: https://github.com/goreleaser/godownloader
[choco]: https://chocolatey.org/
[scoop]: https://scoop.sh/
[tea]: https://tea.xyz/

View File

@@ -0,0 +1,62 @@
---
slug: /integrations/
sidebar_position: 8
---
# Integrations
## Visual Studio Code Extension
Task has an [official extension for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=task.vscode-task). The code for this project can be found [here](https://github.com/go-task/vscode-task). To use this extension, you must have Task v3.23.0+ installed on your system.
This extension provides the following features (and more):
- View tasks in the sidebar.
- Run tasks from the sidebar and command palette.
- Go to definition from the sidebar and command palette.
- Run last task command.
- Multi-root workspace support.
- Initialize a Taskfile in the current workspace.
To get autocompletion and validation for your Taskfile, see the [Schema](#schema) section below.
![Task for Visual Studio Code](https://github.com/go-task/vscode-task/blob/main/res/preview.png?raw=true)
## Schema
This was initially created by [@KROSF](https://github.com/KROSF) in [this Gist](https://gist.github.com/KROSF/c5435acf590acd632f71bb720f685895) and is now officially maintained in [this file](https://github.com/go-task/task/blob/main/docs/static/schema.json) and made available at https://taskfile.dev/schema.json. This schema can be used to validate Taskfiles and provide autocompletion in many code editors:
### Visual Studio Code
To integrate the schema into VS Code, you need to install the [YAML extension](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml) by Red Hat. Any `Taskfile.yml` in your project should automatically be detected and validation/autocompletion should work. If this doesn't work or you want to manually configure it for files with a different name, you can add the following to your `settings.json`:
```json
// settings.json
{
"yaml.schemas": {
"https://taskfile.dev/schema.json": [
"**/Taskfile.yml",
"./path/to/any/other/taskfile.yml"
]
}
}
```
You can also configure the schema directly inside of a Taskfile by adding the following comment to the top of the file:
```yaml
# yaml-language-server: $schema=https://taskfile.dev/schema.json
version: '3'
```
You can find more information on this in the [YAML language server project](https://github.com/redhat-developer/yaml-language-server).
## Community Integrations
In addition to our official integrations, there is an amazing community of developers who have created their own integrations for Task:
- [Sublime Text Plugin](https://packagecontrol.io/packages/Taskfile) [[source](https://github.com/biozz/sublime-taskfile)] by [@biozz](https://github.com/biozz)
- [IntelliJ Plugin](https://plugins.jetbrains.com/plugin/17058-taskfile) [[source](https://github.com/lechuckroh/task-intellij-plugin)] by [@lechuckroh](https://github.com/lechuckroh)
- [mk](https://github.com/pycontribs/mk) command line tool recognizes Taskfiles natively.
If you have made something that integrates with Task, please feel free to open a PR to add it to this list.

View File

@@ -0,0 +1,59 @@
---
slug: /
sidebar_position: 1
title: ホーム
---
# Task
<div align="center">
<img id="logo" src="img/logo.svg" height="250px" width="250px" />
</div>
Taskは[GNU Make][make]のようにシンプルで簡単に使えるタスクランナー・ビルドツールです。
[Go][go]で書かれているため、Taskはシングルバイナリで他の依存関係がありません。つまり、複雑なインストールセットアップがありません。
一度[インストール](installation.md)したら、シンプルな[YAML][yaml]スキーマを利用して、`Taskfile.yml`というファイルにビルドタスクを記述するだけでいいです。
```yaml title="Taskfile.yml"
version: '3'
tasks:
hello:
cmds:
- echo 'Hello World from Task!'
silent: true
```
記述後はターミナル上で`task hello`と実行することでそのタスクが実行されます。
上記の例は始まりに過ぎません。 全てのスキーマやTaskの機能については、[usage](/usage)ガイドを確認するといいでしょう。
## 機能紹介
- [簡単なインストール方法](installation.md): シングルバイナリをダウンロードして、`$PATH`に追加するだけで完了です! または[Homebrew][homebrew]、[Snapcraft][snapcraft]、[Scoop][scoop]を使ってインストールすることができます。
- Clで使用可能: [シンプルなコマンド](installation.md#install-script)でCIスクリプトに追加することでCIパイプラインでTaskを使うことができます。
- 真のクロスプラットフォーム: ほとんどのビルドツールはLinuxまたはmacOSだけで使用可能ですが、Taskは[Goのシェルインタープリタ][sh]を使うことでWindowsもサポートしています。
- コード生成に適している: 特定のファイル群が最後に実行されてから変更されていない場合(タイムスタンプや内容に基づき)、簡単に[タスクの実行を防ぐ](/usage#prevent-unnecessary-work)ことができます。
## ゴールドスポンサー
<div class="gold-sponsors">
| [Appwrite](https://appwrite.io/?utm_source=taskfile.dev&utm_medium=website&utm_campaign=task_oss_fund) |
| ---------------------------------------------------------------------------------------------------------------------------- |
| [![Appwrite](/img/appwrite.svg)](https://appwrite.io/?utm_source=taskfile.dev&utm_medium=website&utm_campaign=task_oss_fund) |
</div>
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[make]: https://www.gnu.org/software/make/
[go]: https://go.dev/
[yaml]: http://yaml.org/
[homebrew]: https://brew.sh/
[snapcraft]: https://snapcraft.io/
[scoop]: https://scoop.sh/
[sh]: https://github.com/mvdan/sh

View File

@@ -0,0 +1,50 @@
---
slug: /releasing/
sidebar_position: 13
---
# リリース
Taskのリリースプロセスは[GoReleaser][goreleaser]の助けを借りて行われます。 ローカルでリリースプロセスをテストするには、Taskfileの`test-release`タスクを呼び出します。
[GitHub Actions](https://github.com/go-task/task/actions)は、新しいGitタグが`main`ブランチにプッシュされると、自動的に成果物(実行ファイルおよびDEBとRPMパッケージ)をリリースするはずです。
v3.15.0以降、特定のタグをチェックアウトし、上記のGitHub Actionsで定義されたGoバージョンを使用して`goreleaser build`を呼び出すことで、実行ファイルをローカルでも再現して検証することができます。
# Homebrew
Goreleaserは新しいバージョンをリリースするために、[Homebrew tap][homebrewtap]リポジトリの[Formula/go-task.rb][gotaskrb]に新しいコミットを自動的にプッシュします。
# npm
npmにリリースするには、[`package.json`][packagejson]でバージョンを更新し、`task npm:publish`を実行してプッシュします。
# Snapcraft
[snapパッケージ][snappackage]をリリースするには、マニュアルのステップが必要です:
- [snapcraft.yaml][snapcraftyaml]で現在のバージョンを更新する。
- [Snapcraftダッシュボード][snapcraftdashboard]で、`amd64``armhf``arm64`の新しい成果物を全てstableチャンネルに移動させる。
# winget
wingetもマニュアルのステップが必要です。 `task test-release`をローカルで実行すると、マニフェストファイルが`dist/winget/manifests/t/Task/Task/v{version}`に生成されます。 [マニフェストディレクトリをこのフォーク](https://github.com/go-task/winget-pkgs/tree/master/manifests/t/Task/Task)にアップロードし、[このリポジトリ](https://github.com/microsoft/winget-pkgs)にプルリクエストを作ってください。
# Scoop
ScoopはWindowsオペレーティングシステム用のコマンドラインパッケージマネージャーです。 Scoopパッケージマニフェストはコミュニティによって管理されています。 Scoopの所有者は通常、[このファイル](https://github.com/ScoopInstaller/Main/blob/master/bucket/task.json)を編集することでバージョンを更新します。 Taskのバージョンが古くなっていると思われる場合は、Issueを作成してお知らせください。
# Nix
Nixはコミュニティが所有するインストール方法です。 Nixパッケージのメンテナは通常、[このファイル](https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/development/tools/go-task/default.nix)を編集してバージョンを更新します。 Taskのバージョンが古くなっていると思われる場合は、Issueを作成してお知らせください。
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[goreleaser]: https://goreleaser.com/
[homebrewtap]: https://github.com/go-task/homebrew-tap
[gotaskrb]: https://github.com/go-task/homebrew-tap/blob/master/Formula/go-task.rb
[packagejson]: https://github.com/go-task/task/blob/main/package.json#L3
[snappackage]: https://github.com/go-task/snap
[snapcraftyaml]: https://github.com/go-task/snap/blob/master/snap/snapcraft.yaml#L2
[snapcraftdashboard]: https://snapcraft.io/task/releases

View File

@@ -0,0 +1,233 @@
---
slug: /styleguide/
sidebar_position: 10
---
# スタイルガイド
これは`Taskfile.yml`の公式Taskスタイルガイドです。 このガイドには、Taskfileを整理し、他ユーザーにとっても理解しやすいように保つための基本的な手順が含まれています。
これには一般的なガイドラインが含まれていますが、必ずしも厳密に従う必要はありません。 必要であったり、あるいは違う方法を取りたい場合は自由にしてください。 また、このガイドの改善点について、IssueまたはPull Requestを開くことも自由です。
## `taskfile.yml`ではなく`Taskfile.yml`を使用する
```yaml
# bad
taskfile.yml
# good
Taskfile.yml
```
これはLinuxユーザーにとって特に重要です。 WindowsとmacOSは大文字と小文字を区別しないファイルシステム持っているので、公式にはサポートされていないにもかかわらず、`taskfile.yml`は正常に動作します。 Linuxでは`Taskfile.yml`だけが動作します。
## キーワードを正しい順序にする
- `version:`
- `includes:`
- 設定項目として、`output:``silent:``method:`、そして`run:`があります。
- `vars:`
- `env:`, `dotenv:`
- `tasks:`
## インデントにはスペース2つを使用する
これはYAMLファイルの最も一般的な慣習であり、Taskはそれに倣うものです。
```yaml
# bad
tasks:
foo:
cmds:
- echo 'foo'
# good
tasks:
foo:
cmds:
- echo 'foo'
```
## メインセクションをスペースで分ける
```yaml
# bad
version: '3'
includes:
docker: ./docker/Taskfile.yml
output: prefixed
vars:
FOO: bar
env:
BAR: baz
tasks:
# ...
# good
version: '3'
includes:
docker: ./docker/Taskfile.yml
output: prefixed
vars:
FOO: bar
env:
BAR: baz
tasks:
# ...
```
## タスク間にスペースを設ける
```yaml
# bad
version: '3'
tasks:
foo:
cmds:
- echo 'foo'
bar:
cmds:
- echo 'bar'
baz:
cmds:
- echo 'baz'
# good
version: '3'
tasks:
foo:
cmds:
- echo 'foo'
bar:
cmds:
- echo 'bar'
baz:
cmds:
- echo 'baz'
```
## 変数名は大文字で定義する
```yaml
# bad
version: '3'
vars:
binary_name: myapp
tasks:
build:
cmds:
- go build -o {{.binary_name}} .
# good
version: '3'
vars:
BINARY_NAME: myapp
tasks:
build:
cmds:
- go build -o {{.BINARY_NAME}} .
```
## テンプレート記法で変数名の前後に空白を設けない
```yaml
# bad
version: '3'
tasks:
greet:
cmds:
- echo '{{ .MESSAGE }}'
# good
version: '3'
tasks:
greet:
cmds:
- echo '{{.MESSAGE}}'
```
この書き方は多くの人によってGoのテンプレート作成にも使われています。
## タスク名の単語をハイフンで区切る
```yaml
# bad
version: '3'
tasks:
do_something_fancy:
cmds:
- echo 'Do something'
# good
version: '3'
tasks:
do-something-fancy:
cmds:
- echo 'Do something'
```
## タスクの名前空間にコロンを使用する
```yaml
# good
version: '3'
tasks:
docker:build:
cmds:
- docker ...
docker:run:
cmds:
- docker-compose ...
```
これはインクルードされたタスクファイルを使用する場合に、自動的に行われます。
## 複雑な複数行のコマンドの使用は避け、外部スクリプトを使用する
```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
```

View File

@@ -0,0 +1,240 @@
---
slug: /taskfile-versions/
sidebar_position: 5
---
# Taskfile Versions
The Taskfile syntax and features changed with time. This document explains what changed on each version and how to upgrade your Taskfile.
## What the Taskfile version mean
The Taskfile version follows the Task version. E.g. the change to Taskfile version `2` means that Task `v2.0.0` should be release to support it.
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 3 ![latest](https://img.shields.io/badge/latest-brightgreen)
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 XXH3 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 "Hello, World!"
```
```yaml
version: '3'
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
version: '2'
tasks:
echo:
cmds:
- echo "Hello, World!"
```
Version 2 allows you to write global variables directly in the Taskfile, if you don't want to create a `Taskvars.yml`:
```yaml
version: '2'
vars:
GREETING: Hello, World!
tasks:
greet:
cmds:
- echo "{{.GREETING}}"
```
The variable priority order changed to the following:
1. Task variables
2. Call variables
3. Taskfile variables
4. Taskvars file variables
5. Environment variables
A new global option was added to configure the number of variables expansions (which default to 2):
```yaml
version: '2'
expansions: 3
vars:
FOO: foo
BAR: bar
BAZ: baz
FOOBAR: '{{.FOO}}{{.BAR}}'
FOOBARBAZ: '{{.FOOBAR}}{{.BAZ}}'
tasks:
default:
cmds:
- echo "{{.FOOBARBAZ}}"
```
## Version 1
:::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
echo:
cmds:
- echo "Hello, World!"
```
The variable priority order was also different:
1. Call variables
2. Environment
3. Task variables
4. `Taskvars.yml` 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

View File

@@ -0,0 +1,18 @@
---
slug: /translate/
sidebar_position: 12
---
# 翻訳
このドキュメントの翻訳を手伝ってくれませんか? このドキュメントではどのように翻訳に協力できるかを説明します。
※GitHubリポジトリ上にある翻訳されたマークダウンファイルを直接編集しないでください 翻訳作業は[Crowdin][crowdin]を使っています。 リポジトリはCrowdinからの進捗状況で定期的に更新されます。
翻訳に協力するためにCrowdinプロジェクトへのアクセスが必要な場合は、[Discordサーバーの#translationsチャンネル][discord]でCrowdinへのアクセスを依頼してください。 特定の言語がまだCrowdinに表示されていない場合は依頼してください。
<!-- prettier-ignore-start -->
<!-- prettier-ignore-end -->
[crowdin]: https://crowdin.com/project/taskfile
[discord]: https://discord.gg/6TY36E39UK

File diff suppressed because it is too large Load Diff

Some files were not shown because too many files have changed in this diff Show More