-
-
Notifications
You must be signed in to change notification settings - Fork 780
Description
I'm currently working in a mono-repo of sorts and each of our services/libraries has a Taskfile with a "build" task.
When a service depends on a library we use "includes" and "deps" to make sure the library is built before the service is built.
We also have a root Taskfile that includes all service Taskfiles and calls their build task in a deps array.
This works really well but we've found that when a library is referenced by multiple services it will be built multiple times by the root Taskfile.
We also found that the "sources" feature doesn't work for tasks shared between included Taskfiles.
Here's the dry run from the root Taskfile showing the library getting built twice:
$ task build --dry
task: [service-a:library:build] run-build.sh
task: [service-b:library:build] run-build.sh
task: [service-a:build] run-build.sh
task: [service-b:build] run-build.shand here's what a service Taskfile looks like
version: '3'
includes:
web:
taskfile: ../library/Taskfile.yml
dir: ../library
tasks:
build:
run: once
deps: [library:build]
cmds:
- run-build.sh
sources:
- src/**/*and the library Taskfile
version: '3'
tasks:
build:
run: once
cmds:
- run-build.sh
sources:
- src/**/*It seems like the include namespacing causes task to treat every task as a unique one when multiple Taskfiles include a shared task.
We also noticed that if we run a "task build" in service-a and then service-b that the .task/ checksum cache is not shared and so the library is built twice. The same applies for any order of builds, i.e. building the library then the services.
Ideally the includes form a directed acyclic graph (DAG) and task will run the dependencies in order and only once (when run:once is set), with the task's checksum cache being considered.
Is this something in scope for improvement in taskfile v3?