✨ Use init template from any dagger project

[qjcg]

What are you trying to do?

Today, I can use dagger project init -t hello to create a new dagger plan file using a single template available from the upstream dagger repo.

I would like to be able to use template files defined in my own dagger project (or that of another user on github) so that the template can be tailored to my particular needs.

For example, I could run:

dagger project init -t github.com/foo/bar@main:myTemplate

Where myTemplate might match a file or directory name under some designated directory (e.g. templates) in the github.com/foo/bar repo.

Why is this important to you?

I want to quickly and easily add dagger pipelines into many different repos. Starting from scratch to create a new Plan each time is very inefficient.

How are you currently working around this?

Sometimes I'll start a new Plan from scratch in a new repo.

Other times I'll copy an existing dagger plan from another local directory to use as a starting point. I'd like to enable others I collaborate with to do something like this from a shared GitHub repo containing a few different templates.

[TomChv]

Thanks for your request! I think it's a really good idea!

I put questions I have in mind:

• Should we handle private repository?
• Should we find for a predicated path in the repository (like you said templates)?
• What about gitlab, bitbucket or even gist??
• That could replace our current template logic that embeds files in the directory? Should we support both?

/cc @marcosnils @aluzzardi @helderco

[helderco]

I usually use cookiecutter. There's an abreviation for github: cookiecutter gh:foo/bar. It handles everything you're saying. Is there something like it in golang so we can use it internally?

[marcosnils]

Is there something like it in golang so we can use it internally?

The thing that comes to my mind is to see if the mechanics of the go importpath could be reused here. ref: https://pkg.go.dev/cmd/go#hdr-Remote_import_paths

cc @shykes to get opinions about the DX

[qjcg]

Thanks all for the quick replies! I'm glad I'm not the only one who sees big potential value for the dagger project in making it as frictionless as possible to quickly add new Plans to many repos --- let 1_000_000 dagger pipelines bloom! :)

@TomChv :

Should we handle private repository?

Ideally yes, I think orgs with private repos and self-hosters should be first class citizens.

Should we find for a predicated path in the repository (like you said templates)?

This is a subjective design choice, but thinking about it, I think defining templates as subdirectories of a top-level templates dir could work. Another option would be to define a template dir as any dir containing a sentinel file (e.g. dagger_template.cue or a better name, etc).

What about gitlab, bitbucket or even gist??

As long as the implementation effort is reasonable, these are all widely used, so I'd say yes, the more the merrier!

That could replace our current template logic that embeds files in the directory? Should we support both?

If I imagine the most delightful DX I can for this feature, I could still scaffold up a new Plan using the dagger tool even when I'm offline (e.g. if I'm on a flight with no or bad wifi). To support that, perhaps there could be a small number of embedded templates included (as is done with the hello template today), in addition to supporting templates from other projects.

@helderco :

Is there something like [cookiecutter] in golang so we can use it internally?

The only similar project I'm aware of is boilr, but the project seems dead (has not been updated since 2017). @marcosnils 's idea to leverage the go importpath sounds promising.

[marcosnils]

Going back to the DX topic, what would be the minimum expected feature?

if I do dagger project init --template <url>

From the DX perspective, these is my main reason to not implement this currently:

What's the advantage of using a template over re-using and importing already existing actions? i.e if I do the following:

dagger.#Plan & {
            test: mypackage.#Test & {}
}

mypackage.#Test is an action that I can already reference through my dagger projects. It's important to abstract my workflwos the "right" way so I can get the most while re-using actions.

as @helderco mentioned, if you're already using cookiecutter or something that helps scaffolding your projects, how could a dagger init template add any value on those scenarios?

[helderco]

I guess now there’s cake cutter 😄

[mircubed]

Closing due to end of support for CUE SDK - https://dagger.io/blog/ending-cue-support