
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 everybody,
There were some discussions at #694 with regard to ideas of a possible future major release. GitHub discussions are not too good for these discussions so I decided to open this issue to be more centralized and visible (issues can be pinned).
Also, that probably needs some direction and organization, as having more people involved means we now have different opinions we need to reconcile.
@ghostsquad started working on some ideas on his fork, but I consider that to be a Proof of Concept ™️, and things will likely be different in its final version in the repository.
This issue is a WIP and will be iterated as time passes.
version: '3'
to version: '4'
and their Taskfile should keep working mostly the same, with minimal changescmds
to something else, for example. Most changes should be for new featuresversion: '3'
everything should keep working as before, with rare exceptionsversion: '2'
workingv3
branchsetup:
and hooks proposals: #204, #667, #668This is a ongoing document and will be improved...
metaHi,
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.
When integrating with other tools (like vscode extension, or when trying to script exporting tasks to github actions) we really want to avoid having to parse the free-form output, especially as this will likely change and break integration, even between minor versions.
If we would output as JSON, we can make the parsing far more reliable and less likely to break between versions, especially as if we add extra data, it would not render the original format obsolete.
Things to be included in JSON output:
I often want to use the directory of where the Taskfile is located as an input to other commands (not the current working directory), but it seems like sprig
really locks down access to the filesystem.
Is this possible to do with Task
as a first-class idea?
For example, something like:
tasks:
show-current-dir:
desc: "show where Task is executing from"
cmds:
- echo {{ .TASKFILE_LOCATION }}
Note that this isn't the same as just using $PWD
or -d
because the working directory might be different; Task should probably provide this as a first-class feature if it doesn't already.
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
Hi there,
I would like to install go-task on my Linux distro with homebrew but unfortunately, there is already a built-in Formula named task
in homebrew-core for taskwarrior that I happen to use.
Since the latter is quite more ancient than go-task, would you consider renaming the binary in your homebrew tap ?
Thanks in advance !
wontfixDoes 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 variablesFixes #976
I noticed that the
timestamp
method doesn't seem to work. It reruns the tasks all the time even though nothing has changed.This happens when the task generates some artifacts in the first run and doesn't re-generate them in the subsequent runs. This causes the following run to return
false
. https://github.com/go-task/task/blob/63c50d13eec142694ff5a074c3f9cda6c53d8be3/internal/status/timestamp.go#L41To fix this issue,
task
should include the last run time in thegenerates
. This way, the time of the generates will be newer than the sources, and so there is no need for rerunning.This solution
- would also fix the issue with an empty
generates
array.- is consistent with the
checksum
method, and these two should work the same in most cases.- is way faster than the checksum method because the source times are checked lazily and getting the metadata of a file is faster.
I noticed that the timestamp
method doesn't seem to work. It reruns the tasks all the time even though nothing has changed.
This happens when the task generates some artifacts in the first run and doesn't re-generate them in the subsequent runs. This causes the following run to return false
.
https://github.com/go-task/task/blob/63c50d13eec142694ff5a074c3f9cda6c53d8be3/internal/status/timestamp.go#L41
To fix this issue, task
should include the last run time in the generates
. This way, the time of the generates will be newer than the sources, and so there is no need for rerunning.
This solution
generates
array.checksum
method, and these two should work the same in most cases.I'd like to change the method of checking for the state of a task to timestamp
for all the tasks because the checksum
method is slow. Is there a way to do this?
NOTE: This is incomplete work. It's a proof-of-concept that is going well, but the actual behavior and schema will change until it reaches master
, so avoid using this unless for testing purposes.
Feedback is welcome on how you expect this to work 🙂.
Credits given to @no0dles for the first PoC on #285 and its our tool hammerkit.
On his implementation, @no0dles used the official Docker client library for Go. Sounds reasonable, but I decided to try a different approach: I'm calling docker run ...
directly. There's a couple of reasons this may be interesting:
flags
prop on the YAML to allow the user to set specific Docker flags (flags: [--cpus=1, --pull=always]
). This would be harder to implement if using the Go client, would potentially require a prop to each setting. List of flags available here.flags
it's also possible to do this.dir
prop and its relation with the mounts
prop.method/sources/generates
? Try to run them inside the container? Run outside? Forbid usage on when task is a container?
container
prop, so it's possible to set all tasks on run in a given container?
This is meant to be a transitioning implementation for #681 before it becomes the default behavior on a later version. When reviewing this PR, please take into consideration that I don't have much of an experience writing in Go.
The optional command line flag for this feature "--propagate-status," without a shortcut.
I've noticed that Task kills the process when reloading it in Watch mode instead of gracefully terminating it with SIGTERM:
As far as I can tell, this happens because the task context gets cancelled here, which seems to just kill the process instead of sending an interrupt signal.
It would be nice if there was an option to gracefully stop it instead (and wait for it to stop, in case the cleanup takes a while).
I think it should also behave like InterceptInterruptSignals
and forcefully exit if 3 consecutive interrupts are detected (in case shutdown hangs).
My machine is running Windows 10 by the way.
needs triageI hope everyone had a great Christmas 🎄 and I wish all an incredible 2023 as well 🌟 🎆
This release includes mostly small bug fixes, but it also included support to the brand new --json
flag.
Taskfile.yml
once we're done reading it (#963, #964 by @HeCorr).Taskfile_{{OS}}.yml
file (#961, #971 by @pd93).--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 by @davidalpert, #764).USER_WORKING_DIR
special variable was added to add even more flexibility for monorepos (#289, #920).dotenv
support (#389, #904).includes
(#942, #943).Special thanks to @pd93 for working on 3 of the topics above. Some other important contributions in recent releases were from him as well.
Also, thanks @appwrite for sponsoring Task as part of their OSS Fund Program.
Source code(tar.gz)task --list --silent
(task --ls
). This means that aliases will be completed by the completion scripts (#919).--list
/--list-all
output (#806, #890).default
task in an included Taskfile by using just the namespace. For example: docs:default
is now automatically aliased to docs
(#661, #815).aliases
for tasks and namespaces (#268, #340, #879).interval: '500ms'
or using the --interval=500ms
flag (#813, #865).--list
, --list-all
and --summary
flags (#845, #874).label:
was being shown instead of the task name on --list
(#603, #877).npm
as new installation method: npm i -g @go-task/cli
(#870, #871, npm package).--list
and --list-all
(#818).env:
introduced in the previous release (#858, #866).CLI_ARGS
(--
) in Bash completion (#863).--list-all
with --list
as already possible on the Bash completion (#861).ROOT_DIR
and TASKFILE_DIR
. This was a highly requested feature (#215, #857, Documentation).sources
(#826, #831)..task
directory location with the TASK_TEMP_DIR
environment variable.TASK_COLOR_RESET
, TASK_COLOR_BLUE
, TASK_COLOR_GREEN
, TASK_COLOR_CYAN
, TASK_COLOR_YELLOW
, TASK_COLOR_MAGENTA
and TASK_COLOR_RED
(#568, #792).output: group
mode where STDOUT and STDERR were being print in separated blocks instead of in the right order (#779).-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).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).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