Entrypoints Update

[hushed junco]

https://youtu.be/affTNwsTdVU by @acoustic lance

[silk roost]

Hello, I’m super excited by this new feature and will closely follow up the progresses. One thing that I noted in the PR is that, at the moment, host access is not possible. However, if I’m not mistaken, I see in the demo that the sources are mounted from the host in the base container function. Could you clarify the situation on this front?

[acoustic lance]

Yeah, so when you execute a command in a project the "project root" gets loaded into the dagger engine and will be the current working directory of your command code. So any files from that project root are available to you.

However, if you need any files/dirs from directories on your host outside of the project root, then those are not available. You also can't currently export to any file/dirs on your host. That's what I've been working on adding: https://github.com/dagger/dagger/pull/5157

As it stands, I think we will end up supporting file/dir export to the host, but probably not support importing any file/dir from the host yet as it introduces a lot of complexity for unknown amounts of benefit.

[silk roost]

OK, so if I understand correctly, dagger do --debug run should work from the root of https://github.com/yann-soubeyrand/dagger-entrypoints-test, right? Then I may have a permission issue (maybe with SELinux), because I get this error when using Podman to run the engine input:1: container.from.withMountedDirectory.withEntrypoint.withExec.stdout failed to create device /var/lib/dagger/runc-overlayfs/snapshots/snapshots/386/fs/dev/full: operation not permitted, and this error when using Docker input:1: container.from.withMountedDirectory.withEntrypoint.withExec.stdout error from sender: context canceled. Or maybe I’m missing something?

[silk roost]

Indeed, with Docker I have SELinux errors. However, it seems to be something else with Podman.

[ebon kayak]

What if you need to mount credential files (npmrc, kubeconfig). Still reading on what’s out there so maybe I missed it. This is alpha level or ready to use now? Would love to know a quick comparison on what might change adopting this vs invoking dagger through mage (at this time and current state)

[acoustic lance]

Ah yeah that seems like it's probably SELinux, though I'm curious if you get that when running any dagger pipelines on that host, or is it only when using entrypoints?

[acoustic lance]

Yeah that's a good example one downside of not supporting arbitrary host file/dir access. Technically there will be a workaround available once we add support for secrets as command inputs, e.g. if you have

func Foo(ctx dagger.Context, kubeconfig *dagger.Secret) (string, error) { 
...
}

You'll be able to call dagger do foo --kubeconfig "$(cat ~/.kube/config)". Obviously not as ideal, and we can re-assess adding support for arbitrary file/dirs as inputs too, but hopefully unblocks in the meantime.

[acoustic lance]

It's really pre-alpha right now, the support was only merged because the PR was getting too large 🙂 However, we have a milestone for an "experimental" release, which will include documentation and such, which should be achievable soon.

[acoustic lance]

I think the biggest differences between using mage to invoke dagger and using project commands would be:

1. Commands all run containerized and benefit from the same caching you get with an dagger WithExec
2. There's more sugar around support for dagger types as inputs (e.g. *dagger.Secret as mentioned above) and output types (e.g. being able to return a dagger.File and export that to your host)

More than that, but those are the major differences, happy to clarify further

[ebon kayak]

great info. Appreciate it. Look forward to seeing what happens.

I did see some comments on a PR about the namespace:command and just wanted to say based on several years working with mage... clarity over brevity & "magic. Single biggest issue I have with mage is lack of flags/optional flag parsing.

Definitely AVOID commands beyond 1 level if possible.

dagger do build:all vs dagger do build all dev for example. Once you support flags and subcommands it could be a nightmware.

I personally think positional args should go away after the first one. Powershell (pwsh) gets this right with param hints.

dagger do build:all --env dev 
dagger do build:all:dev

not
dagger do build all dev ...etc

i can add comments in a new discussion if you mention me. Just thought i'd mention early. Refactoring pipelines is a beast if not explicit. This again powershell handles beautifully when done right by letting you just call params with no order required normally.

Great work!