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...
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?
UPDATE: 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.
For 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
Hi 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 !
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.
Fixes #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.
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