Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Feature: A Compromise Solution For Reusing common Taskfiles In Different Projects #770

Closed
hhstore opened this issue Jun 12, 2022 · 6 comments · Fixed by #1152
Closed

Comments

@hhstore
Copy link

hhstore commented Jun 12, 2022

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 include solution 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 path directly.
  • If not, automatically git clone to .task/ ( or ~/.local/.task/) path.
  • In addition, task adds a new command. task sync, which automatically detects the include section of Taskfile.yml and synchronizes updates manually.
# 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.

image

Similar issues:

A collection of taskfiles:

@hhstore hhstore changed the title New Feature: Reuse common Taskfiles in different projects New Feature: A Compromise Solution For Reusing common Taskfiles In Different Projects Jun 12, 2022
@tommyalatalo
Copy link

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
Copy link

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
Copy link

dark06 commented Mar 1, 2023

Any idea if this might be feasible in the near future? This feature would be very helpful.

@lorenzofaresin

This comment was marked as spam.

@pd93 pd93 mentioned this issue Apr 24, 2023
@shadiramadan
Copy link

I recommend checking out how kustomize handles it:
https://github.com/kubernetes-sigs/kustomize/blob/master/examples/remoteBuild.md

@pd93
Copy link
Member

pd93 commented 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).

@pd93 pd93 closed this as completed Aug 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants