Noob question on hot-reloads and *dagger.Service

[sonic citrus]

so, I've been playing around with the idea of using a *dagger.Service as a way to do "hot reload" development.

Ideally, I'd love to do something like this:

find . -name "*.go" -type f | entr -r dagger -s call dev --src=. up

(this is actually working code, but only because I'm running it in silent mode.)
Are there common patterns or built-ins that would allow me to see the interactive console or at least the StdOut/StdErr from my running service(s) that others are using?

My secondary thought was maybe I actually run entr inside of the service container, using WithMountedDirectory as a way to expose a mutable src directory into the container, but while I was able to get WithMountedDirectory to mount, I wasn't able to get any bi-directional file access between my host and the container (its probably just something I'm doing wrong).

Anyway - this doesn't seem to pass the sniff test for me, and I'm hoping someone has a obvious thing think I'm missing that you could point me to that works.

[sonic citrus]

hmmm. no joy 😂

[unique panther]

hey @sonic citrus! sorry we missed this!

I saw that you find the original issue (https://github.com/dagger/dagger/issues/6990) where this conversation is happening. We do have ideas on how to support this flow better mainstream but we currently don't have the bandwidth to tackle this task.

Regarding your question, if you run dagger call with -vvv or --progress plain, you'll have be able to see the service logs with either approach

[sonic citrus]

oh! --progress plain is perfect! I missed that one in the docs.

[mellow coral]

I also happened to be looking at hot-reloading of a local dev server with Dagger yesterday evening, and this thread helped me out. (Because I didn't know about Dagger services till then. 🙂) Thanks!

I have my dev server running now and can access it from a browser on my host machine, but after testing it more and reading through the GitHub Issue linked above, my understanding is that Dagger's withMountedDirectory function doesn't propagate changes from the host directory to the container directory, like Docker bind mounts do. Is this correct? (I had assumed withMountedDirectory worked like the Dockerfile VOLUME instruction, while withDirectory worked like the Dockerfile COPY instruction, but now I'm not sure there's actually any difference between them?)

Incidentally, as I'm getting started with Dagger, I've also been having issues understanding the mappings in general between the Dagger Container methods and regular container instructions (like the ones listed at https://docs.docker.com/reference/dockerfile/#overview). I found the documentation at https://docs.dagger.io/api/types/#container, but I'm not sure if there's anything more detailed out there?

Come to think of it, I'm also not clear whether the Dagger Container methods run at container build time or at container runtime. I may need to find where to read up on how Dagger manages and runs containers in general.

[unique panther]

I have my dev server running now and can access it from a browser on my host machine, but after testing it more and reading through the GitHub Issue linked above, my understanding is that Dagger's withMountedDirectory function doesn't propagate changes from the host directory to the container directory, like Docker bind mounts do. Is this correct? (I had assumed withMountedDirectory worked like the Dockerfile VOLUME instruction, while withDirectory worked like the Dockerfile COPY instruction, but now I'm not sure there's actually any difference between them?)

yes, that's correct. Dagger's withMountedDirectory is equivalent to docker's RUN --mount Dockerfile instruction.

Dagger maps better to docker build than to docker run. Keep in mind that as a build and pipeline system, it's important to guarantee the hermetic aspects of the build. That's why doing things like bind mounting directories from the host is still a design that we need to flesh out as it generally doesn't play very nicely with the build use-case. Also take into account that Dagger's architecture allows the client and the server (engine) to live in different machines and that's another of the reasons why supporing bind mounts is not trivial.

[mellow coral]

Thanks for your response! The comparison to the RUN --mount Dockerfile instruction is helpful.

So I take it that auto-reloading of my dev server isn't possible at this time (aside from using hacks like what @sonic citrus described), but it hopefully will be at some point in the future. 🤞

This feature is really important to me in my adoption of Dagger, because:

1. It would allow a shared configuration both for running a project locally and for building it in CI. (As it stands now, I need to set up Dagger functions for CI, but Dockerfiles and Docker Compose files for running locally. This creates more clutter in the repo, and introduces more work and more risk when making changes that affect how the project is built/run.)
2. It would help ensure that the environment in which the project is run locally is similar to the prod environment.
3. I think that if developers on a team were to use the same tool to run the project locally as what is used in CI, they would be more likely to learn and contribute to the CI code. I've had issues motivating teammates to learn and understand CI code (because "the devops team owns that"), so I think this could be a huge win in getting applicaiton developers to take more ownership of the build/deployment process.

This limitation isn't a deal-breaker for what I'm currently working on (I'm just trying out Dagger while creating a CI pipeline for my personal website that uses Jekyll and GitHub Pages), but it makes me feel like I might want to wait on this feature before advocating for using Dagger in projects at work.

[unique panther]

So I take it that auto-reloading of my dev server isn't possible at this time (aside from using hacks like what @sonic citrus described), but it hopefully will be at some point in the future. 🤞

this topic has been discussed in the past and I even recall seeing an internal prototype on how something like this could work. Thing is that priorities changed in the short term. Hopefully we can go back to this some time soon 🙏

This limitation isn't a deal-breaker for what I'm currently working on (I'm just trying out Dagger while creating a CI pipeline for my personal website that uses Jekyll and GitHub Pages), but it makes me feel like I might want to wait on this feature before advocating for using Dagger in projects at work

We understand and thx for sharing. I'll relay this to the right people internally so we're aware that this is important in your case.

cc @queen pecan @marsh orbit