rambling about some dagger adoption and development usage

[lean bear]

• Originally dagger felt like it fit the role of replacing a makefile, mage, and other tooling locally, which it does
• except that because everything is copied currently without being a mount, now we run into the problem of a local development experience that then deviates from the CI.

So here's my confusion coming back around after realizing I can do a service up with live mounting....

• A dev wants to do live reload on a website or run npm server. They edit a file and need to see the result, now there's no clear path with dagger because it isolates fully and doesn't bring in the changes from my host as I edit.
• I want to run a dagger command that will use a tool like changie to tag. because it's not mounting my current git directory, but a copy this means if I tag and try to push it's out of sync with what's done locally now right? I would then have to run locally and do another git pull to see this tag because it would all be isolated?
• A dev would normally run tilt and launch some port forwards, build a few things, and interact with some kubernetes resources. I'm not certain that would work the same now because the port forwards would be isolated in dagger engine, not on host (though I'm sure there's other steps that could get close, I've not work through them).
• Part of this is a question... would you consider the normal use of dagger to be CLONE internally the target repo and do the actions, or PASS directory target and have dagger copy it?

So this "isolation from the host" is freaking great in many ways, but for a developer there are additional challenges.

Does this make sense or are there any posts on this target usage of developers? To someone doing build/release engineering dagger is a dream. But if I rolled this out to the more of the development team, I forsee that many of the local development issues would be tricky to navigate with the current state of things.

So to be clear I don't want you to waste a ton of time on all these, I'm just starting a thread based on what I was quickly thinking this last weekend on, and maybe you have some blog or other entries about this stuff. You know I've been around the community a while, but a few of these I still haven't figured out 🙂

Mage == running in local scope so it makes sense logically to me as an advanced task automation/runner but deals with environment/tooling issues because of this. But it has access to the same resources as host.

Dagger isolates which is great! But when it comes to local things that a dev might setup, like ensuring they have installed an authentication provider, or port forwarding etc, struggling to see where dagger fits.....

No rush/pressure on answering, will check back as time permits if anyone is interested in sharing, or at least linking to a related github discussion/thread.

[smoky ridge]

I find it hard to relate entirely with all this mostly because I don't have experience but one thing which did click with me was your point on cloning from git or passing the directory.

if the dagger module is to run from a Ci platform, only everything in git will be part of that. which is how we would expect it. remote git never contains local.

if we run dagger locally, and build it to work with local. that does not mean only whats in git. but what dir we pass it.

then we have another case entirely. a completely isolated dagger module which can only clone git, because its not even stored with code or project files. a module which runs cicd from a git clone.

that to me is flexibility but also some guidance on what is best practice and not abusing dagger or using it in a way which means you are not benefiting from its portability to run anywhere. local state = not cicd environment.

to me. dagger is a portable cicd and it should be used with a mindset of I'm going to plug this into a cicd platform.

if we use dagger for other features or dev experiences, maybe that's possible but not the best way to go?

wasn't there also discussion around the concept of a docker Context like when you run a docker build. would some of that also be related to what you're talking about. docker context has support o a docker Ignore file. this should in some ways match up with a git ignore.

[lean bear]

Good points. Yeah it's a conflict for me cause I have "mage" running local go commands. But this expects certain tooling to exist locally because it's also about quality of life improvements for local development, setting up tooling and such.

Dagger so far doesn't seem like it fits there.
Instead I would have to seperate out local automation tasks from CI tasks, and this gets blurry, thus my confusion despite being a fan. It's a struggle to fully figure out the mental model of where dagger fits for me right now.