
Task
Task is a task runner / build tool that aims to be simpler and easier to use than, for example, GNU Make.
See taskfile.dev for the documentation.
Task is a task runner / build tool that aims to be simpler and easier to use than, for example, GNU Make.
See taskfile.dev for the documentation.
Hi,
Add the possibility to use import
or includes
to imports some others tasks.
With the default strategy as namespace
.
File: docker/v1.0/Taskfile.yaml
version: "2"
task:
build:
cmds:
- docker build...
File: go/v1.0/Taskfile.yaml
version: "2"
task:
build:
cmds:
- go build ...
File (in my project): Taskfile.yaml
imports:
docker: https://.../docker/v1.0/Taskfile.yaml
go: file://.../go/v1.0/Taskfile.yaml
— or —
includes:
docker: https://.../docker/v1.0/Taskfile.yaml
go: file://.../go/v1.0/Taskfile.yaml
task:
build:
- task: "docker:build"
- task: "go:build"
task go:build go:docker
— or —
task build
What do you think?
feature on holdUPDATE: This is a general feature request to not run equal dependencies more than once. E.g. if task A
and task B
both depend on taskC
, running both task A
and task B
in parallel (witin one instance of task), should be able to resolve the dependencies so that taskC
is only run once, and this is the interesting port, if it's equal, which we will get to next.
Since you can pass variables to tasks, it's not enough to just look at the name. The best option is probably to rely on a hash of the name + sorted and resolved input variables. A close second could be to rely on unresolved but still sorted input variables, which is not perfect, but could be an acceptable trade-off if it's somehow easier in code.
I have multiple tasks in my Taskfile
that depend on a single task called go-dep
that runs the command glide install
. When I run task
to build multiple targets, I would expect go-dep to be called at most 1 time (zero if it's found to be up-to-date). Instead, I see it's called once for each task that depend on it:
$ task
task: No argument given, trying default task
glide install
glide install
glide install
glide install
PS! go-deps
in this case is called with no vars, but the rule should really apply to run a dep at most 1 time when the vars are exactly the same.
This is a general issue to track proposals with small or big breaking changes, that could be released in the next major version.
This list is a work in progress and can change at any time.
Development is happening on the v3 branch.
github.com/go-task/task/v2
to v3
Taskvars.yml
and Taskfile_{{OS}}.yml
. This was done before we had a generic inclusion of Taskfiles implemented. We should add options to
vendor
directory? (#214)method:
option. Default changed from timestamp
to checksum
(#246).TIMESTAMP
and .CHECKSUM
to status:
(#216)method:
(shouldn't also check the main guide)There are more issues and feature request that could be added to this release.
proposal v3 metaFor some startup tasks or cleanup paths commands could run in parallel while others should be run in order. Add a Parallel property to task to allow switching between modes
enhancementHi everybody 👋
Once in a while, people ask me why the development is slow, questions got unanswered, bug reports are not responded, features not added, PRs not reviewed, etc.
The answer is simple: the project has grown to become bigger than I ever expected. With a full time job and a life outside work, I have limited time to dedicate to this project. More demand is generated from users than I could keep up even if I doubled the time I dedicate to this project.
So first of all I'd like to ask for your patience and understanding.
Secondly, I'd like to hear opinions and ideas on how to keep the project moving.
And lastly, I'ld like to ask for some help. I had two other people with write access to the repo in the past, but they quickly lost interest in the project. Other than that short period, I've being alone. You could help:
Adding a --summary
flag for task to get more a summary of the task
See #107
New field in task called summary
version: '2'
tasks:
release:
deps: [build]
summary: |
Release your project to github
It will build your project before starting the release it.
Please make sure that you have set GITHUB_TOKEN before starting.
cmds:
- your-release-tool
build:
cmds:
- your-build-tool
Output for task --summary release
:
task: release
Release your project to github
It will build your project before starting the release it.
Please make sure that you have set GITHUB_TOKEN before starting.
dependencies:
- build
commands:
- your-release-tool
Behaviour:
--summary
will not execute the task--summary
will display the summary of a task (see above)--summary
will use description as fallback, if summary does not exist--summary
will output a warning (or information), if no description/summary is present--summary
will output the dependencies if there are any--summary
will output the commands if there are anyTests:
task_test.go
Documentation is present for that feature
Does go-task currently offer the option of "passthrough" arguments? For example, if I have currently have a task to run the AWS CLI out of a Docker container:
tasks:
aws:
cmds:
- docker-compose run --rm aws
Is it possible to have the ability for a command like task aws -- ls s3://my-bucket
to be translated to docker-compose run --rm aws ls s3://my-bucket
, meaning task
will pass through anything after --
to the underlying shell command?
This is a more convenient way to pass extra variables compared to the current approach: task write-file FILE=file.txt "CONTENT=Hello, World!"
. Currently, using this approach allows me to write task aws CMD="ls s3://my-bucket"
but the extra variable definition and quotes creates a lot of friction that I think can be alleviated with my proposal.
If this is not possible, it would be a really nice capability to have in the future.
feature proposal variablesThis is my first proposal to add includeable Taskfiles over http.
The config looks like the following:
includes:
moo:
path: https://raw.githubusercontent.com/go-task/task/master/Taskfile.yml
cache: 30s
foo: https://raw.githubusercontent.com/tonobo/task/master/Taskfile.yml
hui:
path: ./
flush_includes: yes
References: #98
feature on hold# https://taskfile.dev
version: '2'
tasks:
a:
cmds:
- echo "Task a"
- echo $PATH
b:
cmds:
- echo "Task b"
- echo "{{.PATH}}"
c:
env:
PATH: tools
cmds:
- echo "Task c"
- echo $PATH
d:
env:
PATH: tools
cmds:
- echo "Task d"
- echo "{{.PATH}}"
e:
env:
PATH:
sh: echo "tools;$PATH"
cmds:
- echo "Task e"
- echo $PATH
f:
env:
PATH:
sh: echo "./tools;$PATH"
cmds:
- echo "Task f"
- echo $PATH
g:
env:
PATH:
sh: echo "$(realpath ./tools);$PATH"
cmds:
- echo "Task g"
- echo $PATH
Hello. Firstly, thank-you for Task. It has, overall, made my development life easier and more pleasant.
I don't know if the problem I have is a bug or if I simply don't understand the correct way to achieve my goal. I'd like to be able to modify the environment variable PATH
(either prepending or appending a project-specific directory to the existing value), but I can't figure out how to do this using the set of commands available within Taskfiles
.
To provide context, my Taskfile
is for use in building go applications. Some applications (projects) require project-specific build tools/helpers that I place in a top-level tools
subdirectory (i.e., <project name>/tools
). Note that my Taskfile
resides at <project name>/Taskfile.yml
. I wish to use the go generate
command, which effectively requires that external generation tools be accessible via PATH
, so I must add <project name>/tools
to PATH
before running go generate
in the task.
While I'm working in Windows, I'm making effective use of busybox-w32 to provide a fairly comprehensive set of what are otherwise Linux tools, so things like cp
, echo
and realpath
are available. I've also tried this via WSL
such that things are more like a real Linux environment, with the same results.
The output I get from the above Taskfile (when run under sh
or bash
via WSL
) is as follows (results in native Windows are the same):
$ task a; task b; task c; task d; task e; task f; task g
echo "Task a"
Task a
echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
echo "Task b"
Task b
echo "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
echo "Task c"
Task c
echo $PATH
tools
echo "Task d"
Task d
echo "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
echo "Task e"
Task e
echo $PATH
tools;/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
echo "Task f"
Task f
echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
echo "Task g"
Task g
echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
Tasks a
, b
, c
and d
are just simple tests; it's tasks e
, f
and g
that illustrate the real issue. Task e
works correctly, prepending tools
to the current PATH
, but neither f
nor g
have any effect. Task g
is the closest to what I need in terms of operations (i.e., adding the absolute path of a project-specific directory).
I'd greatly appreciate any input you could provide on this issue. Thanks in advance.
bugTask version: v3.7.0 (h1:8dDFv12/Lxi6PHkYNIIm7N6v6oRGxePpLK67LuMh/Rs=)
Operating System: Linux 5.13.10-arch1-1 #1 SMP PREEMPT Thu, 12 Aug 2021 21:59:14 +0000 x86_64 GNU/Linux
version: '3'
silent: false
tasks:
check:
desc: Generates proto with prepared docker-image
cmds:
- echo $GID
- echo $UID
check it:
✗ task check
task: [check] echo $GID
task: [check] echo $UID
1000
✗ echo $GID
1000
✗ echo $UID
1000
bug
hello @andreynering, the fix is quite simple :-D, what is complicated and worthwhile to spend some time to understand is the first commit a496a75, that introduces extensive tests to reproduce the behavior.
I realized that to fix this problem, it is not possible to tweak the timeout of mvdan.cc/sh, we must be more drastic and don't pass to it any cancellable context. The problem that I observed is the following (reproduced in the tests):
I suggest to checkout a496a75, run
task install && go test -run '^TestSignalSentToProcessGroup' -count=1 -v=1
and get acquainted with the (expected) failures.
Then, checkout the tip of the branch and run the same tests, to validate that everything is fixed.
There are some things that are still missing: testing what happens on Windows and deciding how far propagate in the Task functions the fact that the context should not even passed. I mean: func RunCommand(ctx context.Context, opts *RunCommandOptions)
is now lying, since the context will not be passed to anything.
As a reference, here are the failing tests on Linux:
task install && go test -run '^TestSignalSentToProcessGroup' -count=1 -v=1
task: [install] go install -v -ldflags="-w -s -X main.version=a496a75b05" ./cmd/task
github.com/go-task/task/v3/internal/execext
=== RUN TestSignalSentToProcessGroup
=== RUN TestSignalSentToProcessGroup/child_simulates_terraform:_receives_1_sigint_and_does_cleanup
unix_test.go:174:
wanted but not found:
[sleepit: cleanup done
task: Failed to run task "default": exit status 3
]
unix_test.go:179:
unwanted but found:
[sleepit: got signal=interrupt count=2
sleepit: cleanup canceled
task: Failed to run task "default": exit status 4
]
unix_test.go:183:
output:
[task: [default] /home/mmolteni/opensource/go-task/tmp/sleepit handle -term-after=2 -sleep=10s -cleanup=50ms
sleepit: ready
sleepit: PID=3713003 sleep=10s cleanup=50ms
sleepit: work started
task: signal received: interrupt
sleepit: got signal=interrupt count=1
sleepit: got signal=interrupt count=2
sleepit: work canceled
sleepit: cleanup started
sleepit: cleanup canceled
task: Failed to run task "default": exit status 4
]
=== RUN TestSignalSentToProcessGroup/child_does_not_handle_sigint:_receives_sigint_and_terminates_immediately
unix_test.go:174:
wanted but not found:
[task: Failed to run task "default": exit status 130
]
unix_test.go:179:
unwanted but found:
[task: Failed to run task "default": context canceled
]
unix_test.go:183:
output:
[task: [default] /home/mmolteni/opensource/go-task/tmp/sleepit default -sleep=10s
sleepit: ready
sleepit: PID=3713018 sleep=10s cleanup=0s
sleepit: work started
task: signal received: interrupt
task: Failed to run task "default": context canceled
]
=== RUN TestSignalSentToProcessGroup/child_intercepts_sigint:_receives_sigint_and_does_cleanup
unix_test.go:174:
wanted but not found:
[sleepit: cleanup done
task: Failed to run task "default": exit status 3
]
unix_test.go:179:
unwanted but found:
[sleepit: got signal=interrupt count=2
task: Failed to run task "default": context canceled
]
unix_test.go:183:
output:
[task: [default] /home/mmolteni/opensource/go-task/tmp/sleepit handle -sleep=10s -cleanup=2s
sleepit: ready
sleepit: PID=3713030 sleep=10s cleanup=2s
sleepit: work started
sleepit: got signal=interrupt count=1
task: signal received: interrupt
sleepit: work canceled
sleepit: got signal=interrupt count=2
sleepit: cleanup started
task: Failed to run task "default": context canceled
]
--- FAIL: TestSignalSentToProcessGroup (2.13s)
--- FAIL: TestSignalSentToProcessGroup/child_simulates_terraform:_receives_1_sigint_and_does_cleanup (0.11s)
--- FAIL: TestSignalSentToProcessGroup/child_does_not_handle_sigint:_receives_sigint_and_terminates_immediately (0.01s)
--- FAIL: TestSignalSentToProcessGroup/child_intercepts_sigint:_receives_sigint_and_does_cleanup (2.01s)
FAIL
exit status 1
FAIL github.com/go-task/task/v3 2.136s
Hi,
The files in the checksum directory are created with user-write-permissions - https://github.com/go-task/task/blob/9eda1629bb72459580a156d52fa5f3dd15d93b7b/internal/status/checksum.go#L47
This prevents other users from run task later in that directory.
Would be helpful if it could be changed - either by default, by parameter, or by '--no-checksum' argument.
Thanks
Bumps github.com/stretchr/testify from 1.7.2 to 1.7.5.
b5ce165
fixing panic in calls to assertion with nil m.mutex (#1212)c206b2e
Mock can be deadlocked by a panic (#1157)1b73601
suite: correctly set stats on test panic (#1195)ba1076d
Add .Unset method to mock (#982)c31ea03
Support comparing byte slice (#1202)48391ba
Fix panic in AssertExpectations for mocks without expectations (#1207)840cb80
arrays value types in a zero-initialized state are considered empty (#1126)07dc7ee
Bump actions/setup-go from 3.1.0 to 3.2.0 (#1191)c33fc8d
Bump actions/checkout from 2 to 3 (#1163)3c33e07
Added Go 1.18.1 as a build/supported version (#1182)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase
.
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebase
will rebase this PR@dependabot recreate
will recreate this PR, overwriting any edits that have been made to it@dependabot merge
will merge this PR after your CI passes on it@dependabot squash and merge
will squash and merge this PR after your CI passes on it@dependabot cancel merge
will cancel a previously requested merge and block automerging@dependabot reopen
will reopen this PR if it is closed@dependabot close
will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major version
will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor version
will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependency
will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)Current there is no way to disable this message
silent: true
can't disable this message and also I'd like to keep the output of what command are actually executing.
Just like make
(without --debug
) wouuld do, only show commands but not which make target is matched.
It took me some time to discover why the output of some commands was very confusing as the order of the console lines were not in order.
That is happening because when run using grouping both stdout and stderr are captures separated and printed separated, one after another. As you can imagine that can cause very confusing console output for script. Easy to see especially when running bash scripts with set -x
.
It would be preferable if the subprocess would use line-buffering and print lines in order they were generated, making read of output more human friendly.
I have encountered an inconsistency in vars of included taskfiles and need some assistance. The setup I have looks like this. There is a common-include taskfile and a package1 taskfile. The parent taskfile includes both taskfiles. The package1 also includes common-include. The problem arises with the variables that are passed. From parent to common-include everything works fine but from package1 to common-include the passed variable is simply ignored.
❯ tree .
.
├── include
│ └── Taskfile.include.yaml
├── package1
│ └── Taskfile.package1.yaml
└── Taskfile.yaml
2 directories, 3 files
./Taskfile.yaml
version: '3'
includes:
included:
taskfile: ./include/Taskfile.include.yaml
vars:
VAR_1: provided-from-parent-var1
package1:
taskfile: ./package1/Taskfile.package1.yaml
tasks:
default:
cmds:
- task: included:task1
./package1/Taskfile.package1.yaml
version: '3'
includes:
included:
taskfile: ../include/Taskfile.include.yaml
vars:
VAR_1: provided-from-package1-var1
tasks:
default:
cmds:
- task: included:task1
./include/Taskfile.include.yaml
version: "3"
vars:
VAR_1: '{{.VAR_1 | default "included-default-var1"}}'
tasks:
task1:
cmds:
- echo "VAR_1 is {{.VAR_1}}"
❯ go-task
task: [included:task1] echo "VAR_1 is provided-from-parent-var1"
VAR_1 is provided-from-parent-var1
❯ go-task package1:default
task: [package1:included:task1] echo "VAR_1 is included-default-var1"
VAR_1 is included-default-var1
By executing go-task
the default task from parent is executed and the VAR_1 has the provided value. By executing go-task package1:default
the default task from package1 is executed and the VAR_1 does not have the provided value provided-from-package1-var1
but the default value from the common-include included-default-var1
.
-n
as an alias to --dry
(#776, #777).--exit-code
(-x
) flag that will pass-through the exit form the command being ran (#755).\r
because we were only removing the final \n
but not \r\n
(#717).--list
and --list-all
flags can now be combined with the --silent
flag to print the task names only, without their description (#691).If you find this project useful, you can consider donating.
Source code(tar.gz)group
output mode, useful for grouping tasks in CI systems. Check out the documentation for more information (#647, #651).Taskfile.dist.yml
and Taskfile.dist.yaml
to the supported file name list. Check out the documentation for more information (#498, #666).--list-all
(alias -a
) flag is now available. It's similar to the existing --list
(-l
) but prints all tasks, even those without a description (#383, #401).defer:
keyword (Documentation, #475, #626).$
variable prefix and ^
command prefix (#642, #644, #645)..yaml
extension (as an alternative to .yml
). This was requested multiple times throughout the years. Enjoy! (#183, #184, #369, #584, #621).{{.CLI_ARGS}}
argument to prevent one with spaces to become many (#613).cmd:
was left empty (#612, #614).shellQuote
(#609, mvdan/sh#763).shellQuote
function was added to the template system ({{shellQuote "a string"}}
) to ensure a string is safe for use in shell (mvdan/sh#727, mvdan/sh#737, Documentation)read -p
flag is now supported (#314, mvdan/sh#551, mvdan/sh#772)pwd -P
and pwd -L
flags are now supported (#553, mvdan/sh#724, mvdan/sh#728)$GID
environment variable is now correctly being set (#561, mvdan/sh#723)interactive: true
setting to improve support for interactive CLI apps (#217, #563).nil
errors (#534, #573).~
(#539, #557).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, #359).sources:
and status:
in the same task (#411, #427, #477).dotenv:
(#517).NO_COLOR
environment variable (#459, fatih/color#137).--watch
mode (#484, #485).--
and a special CLI_ARGS
variable (#327).--concurrency
(alias -C
) flag, to limit the number of tasks that run concurrently. This is useful for heavy workloads (#345).--list
and --summary
by skipping running shell variables for these flags (#332)..task
directory being created in the task directory instead of the Taskfile directory (#247).sh:
) were not running in the task directory when the task has a custom dir or it was in an included Taskfile (#384).--watch
flag) got a few different bug fixes and should be more stable now (#423, #365).label:
attribute (#412).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).internal
directory (#358).v3
, all CLI variables will be considered global variables (#336, #341).env
like files (#324, #356).label:
to task so you can override the task name in the logs (#321, #337).expansions
on v3 since it has no effect.Taskvars.yml
is not automatically included anymore.Taskfile_{{OS}}.yml
is not automatically included anymore.includes
, so you can manually include a Taskfile based on operation system, for example..TASK
variable in templates with the task name (#252).method:
option. With this option, you can set a default method to all tasks in a Taskfile (#246).timestamp
to checksum
(#246).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).This is probably the last v3 preview release before it's released as stable.
expansions
on v3 since it has no effect.Taskvars.yml
is not automatically included anymore.Taskfile_{{OS}}.yml
is not automatically included anymore.includes
, so you can manually include a Taskfile based on operation system, for example.This is probably the last v2 release before v3 is considered stable. See https://github.com/go-task/task/issues/195 and https://github.com/go-task/task/pull/220.
--help
flag (#300, #330).context
errors when using the --watch
flag (#313, #317)..TASK
variable in templates with the task name (#252).v3
branch--parallel
flag (alias -p
) to run tasks given by the command line in parallel (#266).task
CLI only informing global vars would not execute the default
task.silent: true
a the root of the Taskfile.exit 0
was called (#251).method:
option. With this option, you can set a default method to all tasks in a Taskfile (#246).timestamp
to checksum
(#246).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).method: checksum
will now re-run if generated files are deleted (#228, #238).azqlite azqlite is a lightweight wrapper around github.com/Azure/azure-storage-queue-go to interact with the Azure Storage Queue service in a simpler
Docker-based remote code runner / 基于 Docker 的远程代码运行器
github-act-runner A reverse engineered github actions compatible self-hosted runner using nektos/act to execute your workflow steps. Unlike the offici
dashd-go is an alternative full node dash implementation written in Go (golang)
LinkPage LinkPage is a FOSS self-hosted alternative to link listing websites such as LinkTree and Campsite.bio Features Self hostable and open source
M3O M3O is an open source public cloud platform. We are building an AWS alternative for the next generation of developers. Overview AWS was a first ge
oTF An open source alternative to terraform enterprise. Functionality is currently limited: Remote execution mode (plans and applies run remotely) Sta
Nomad Skeleton Driver Plugin Skeleton project for Nomad task driver plugins. Thi
embedshim The embedshim is the kind of task runtime implementation, which can be used as plugin in containerd. With current shim design, it is used to
slo-computer SLOs, Error windows and alerts are complicated. Here's an attempt to make it easy SLO, burn_rate, error_rate, budget_spend are convoluted
cloutcli library to make building things with bitclout easy quick start demo cmd $ ./clout demo clout demo visualizegraph # make clout.gv graph fi
Describing Instances/VPCs data, select one or multiple instances, and make connection(s) to selected instances. Caching the response of API calls for 1day using Tmpfs.
Web Mirror Based on reverseproxy Solution for: Website that only set 'X-Frame-Options' to 'sameorigin'. Hide website real url Content interception & m
sigstore-scaffolding This repository contains scaffolding to make standing up a full sigstore stack easier and automatable. Our focus is on running on
ks Utility to make kubeseal --raw a bit easier. Building GOOS=windows GOARCH=amd64 go build -o ks-windows-amd64.exe ks.go GOOS=windows GOARCH=386 go b
Assignment In this assignment, you have to make a billing machine for the XYZ Cafe. The machine consist of a group of buttons each representing a uniq
bombardier bombardier is a HTTP(S) benchmarking tool. It is written in Go programming language and uses excellent fasthttp instead of Go's default htt
English | 中文 Cassowary is a modern HTTP/S, intuitive & cross-platform load testing tool built in Go for developers, testers and sysadmins. Cassowary d
Go Bullet Train (GBT) Highly configurable prompt builder for Bash, ZSH and PowerShell written in Go. It's inspired by the Oh My ZSH Bullet Train theme