Repository navigation
New Feature: A Compromise Solution For Reusing common Taskfiles In Different Projects #770
Description
Background:
- There are many issues being discussed about
reusing common Taskfiles. - It can be seen that this demand is very strong.
- Given that the
remote includesolution doesn't work. I think of a compromise solution.
A Compromise Solution:
like this:
includes:
sre:
taskfile: "https://github.com/better-sre/config"
type: git+local # or git+global
dir: ./.task/xxx # or ~/.local/.task/xxx
sync: auto # sync github: daily check
- When include contains type option is
git. - It will automatically check if the
.task/(or ~/.local/.task/) path has the same name path. - If it exists, use the
local pathdirectly. - If not, automatically
git cloneto.task/( or ~/.local/.task/) path. - In addition, task adds a new command.
task sync, which automatically detects the include section ofTaskfile.ymland synchronizes updatesmanually.
# automatically detects the include section of `Taskfile.yml` and synchronizes updates `manually`.
task sync- This solution is still based on the
local path. There is no difficulty in implementation. - But it solves the problem of convenience.
Reference:
My current solution:
- https://github.com/better-sre/config#usage
- This repo can also be used as an example directory structure, my Taskfile here is multi-level nested.
- About reusing Taskfile in different projects. Here, I gave 3 feasible solutions.
- This is my current practice of reusing public Taskfiles. It can solve the problem, but it is not convenient enough.
- I'm wondering if go-task can support option 2 or option 3.
Similar issues:
- Add "imports" or "includes" #98
- Adding URLs in includes #380
- Remote includes via Git #556
- "includes" path does not resolve {{.HOME}} variable #670
- Adding URLs in includes #380
- These are all discussing the same requirement.
A collection of taskfiles:
Reacted by Ryan Currah, Sergio Valverde, Jhonn Frazão, Tommy Alatalo, Matthias Preu, paluszkiewiczB, Giuseppe Santoro, Bittrance, Pierre-Emmanuel MERCIER, Eli Wilson and 13 more
Activity
[-]New Feature: Reuse common Taskfiles in different projects[/-][+]New Feature: A Compromise Solution For Reusing common Taskfiles In Different Projects[/+]tommyalatalo commentedon Aug 25, 2022
This is definitely needed, I'm currently storing my included taskfiles in a submodule, and it's a constant pain to keep updating the submodule reference. Fetching it using git or the public APIs for Gitlab/Github would alleviate this issue pretty much completely, especially if it would be possible to use git references like branches, tags or commits to choose what to track.
ryancurrah commentedon Aug 31, 2022
Was researching this tool and was looking for a feature like this in the docs. This feature would def make it a strong case to use it over Makefiles.
dark06 commentedon Mar 1, 2023
Any idea if this might be feasible in the near future? This feature would be very helpful.
lorenzofaresin commentedon Apr 18, 2023
shadiramadan commentedon May 4, 2023
I recommend checking out how kustomize handles it:
https://github.com/kubernetes-sigs/kustomize/blob/master/examples/remoteBuild.md
pd93 commentedon Aug 29, 2023
Hi All! Thanks to everyone for upvoting this issue. It's been the most upvoted issue for quite a while, so I'm happy to say that we're now actively working on an experiment for this!
As a result, I'm going to close this issue. You can follow the progress over in the new Remote Taskfiles experiment issue (#1317).