#dagger functions quick basic help

1 messages · Page 1 of 1 (latest)

ashen pendant
#

  • so dagger wraps up the invocation and running of a remote module. This module can be in one of the three supported languages right now that does not require any of the runtimes or tools to be installed. That's part of the module that dagger would invoke right?

  • so let's say I have some magefiles and I want to start using that in dagger without requiring any go runtime local. I could either compile the mage file and it would run on the host or I could use dagger to call the content but everything would run inside the container right? If you have an example of where you ported some prior mage content over to this new format, I'd like to see.

  • lastly let's say I have a developer utility. Essentially, I'd be grabbing, the changie binary mounting whatever paths I want, and using the entry point as the changie command?

So if it's a tool that needs to run in the local context, dagger is not the right fit, but if I want it to be contained then dagger is a great fit. Gonna update to latest dagger file and see how this will work in azure repos. Seems really cool!

crimson light
#

If you have an example of where you ported some prior mage content over to this new format, I'd like to see.

Good question. We are in the process of doing exactly that for our own CI 🙂 @sacred portal and @hollow delta may have a fresh link to the latest dev branch for that.

#

But yes, in a nutshell: to port a custom client tool (in your case mage + your magefile) to a Dagger Function, you would:

  1. wrap that tool into a containerized Dagger Function
  2. replace the direct invocation of the tool with an invocation of the wrapper function
  3. if needed, refactor from there, typically to split up the one big function into several smaller functions

Doing this is pretty easy, because 90% of your dagger client code remains the same. The remaining 10% that does require manual code changes, comes from losing "ambient access" to the client's host system. See #daggernauts message

sacred portal
#

Yeah there have been a few starts at converting our magefiles over the various iterations on what became modules; Justin's most recent is here and has a good example of making an external directory available to all the Functions in a module, the gist being:

  1. Use a constructor here that accepts the Directory: https://github.com/jedevc/dagger/blob/653147321d133c5be652232ca724b1aa4fc752f0/ci/main.go#L9
  2. All the functions on Dagger now have access to that Directory without needing to each be passed it explicitly, e.g.: https://github.com/jedevc/dagger/blob/653147321d133c5be652232ca724b1aa4fc752f0/ci/main.go#L9

But yeah there's more work planned to make this lower-overhead for users, the current support is pretty barebones.

This issue is also relevant: https://github.com/dagger/dagger/issues/5993 Specifically my most recent comment with an idea on how to perhaps make this super seamless (which I recently discovered overlaps with something @grim forge started cooking up independently: https://discord.com/channels/707636530424053791/1212084268474568796).

  • Basically, if all the ideas pan out, we may be able to support running Dagger SDK code directly on the host while A) avoiding dependencies on compilers/interpreters/toolchains being installed and B) also being able to call out to containerized modules.
crimson light
sacred portal
# crimson light Just to clarify the constructor trick: it's unrelated to the `util` modlue and i...

Yes exactly, not the cleanest example ideally. We also have docs on constructors here: https://docs.dagger.io/developer-guide/go/520657/constructor But the Directory use case specifically seems like a good candidate for a "Cookbook" entry if we plan on re-adding that to our own Functions docs. I'm sure we'd end up linking to it a lot

Module Constructor | Dagger

Sometimes it's convenient to have a special function for constructing the main module object. This can, for example, be a simple way to accept module-wide configuration.

crimson light
#

Are any of the individual pieces daggerized? ie. bottom-up daggerization of the individual utility functions, like "docs linter"?

#

Right now I'm trying to contribute a PR to our docs, getting GHA linting errors, and honestly have no clue what to do locally

#

Kind of a "cobbler's shoes" moment

sacred portal
hollow delta
#

Sorry, been a bit slow (having a series of very sick days)
There's only the engine+cli parts daggerized at the moment, the next step would be the SDKs and then potentially we could have something mergeable?

#

The problem is that because functions can't be called from the old SDKs, we'd need to do a full port of pretty much everything - I know @sacred portal is thinking about this though

grim forge
#

Could we do SDKs as different modules in each language, for maximal dogfooding? For languages that support zenith that is 😛

pastel veldt
ashen pendant
#

I'll add that I looked briefly yesterday and wasn't clear on how to get started replacing local code running in mage with the new approach but I think I've got an idea essentially replacing with go file with main and input processed as examples show. I wanted to play with it more but Goreleaser already does my builds and that project I didn't have time to rework in dagger.