Functionality similar to postSyncCommand from hotR...
# 🌱|help-and-getting-started
Is there similar functionality to the postSyncCommand available for devMode? I'm pondering the case for compiled languages where one syncs over a binary and want to restart the service and similar.
Hi @tall-greece-98310 ! Unfortunately, there is no postSyncCommand support in devMode yet. But we plan to implement it.
That seems very useful. Especially for compiled languages.
@tall-greece-98310 For compiled languages using local mode can be a good alternative,
Yeah, but it has issues if the service need to access resources within the cluster. DNS etc.
@curved-intern-91221 Is there already a feature request on github? I didn't find one
I think there should be at least a way to force rebuilding the docker image for every code change
@big-spring-14945 no, we don't have a GH issue for that. It's on our internal roadmap.
Just to chime in, a post sync command would definitely be useful but we see users get a lot of mileage out tools like watchexec which watch the file system and respond to changes ( Something like:
Copy code
      - "/bin/sh"
      - "-c",
      - "watchexec -r -e java --debounce 1000 -- ./ # Tweak debounce depending on how slow the compile-and-run script is
Essentially: - Garden syncs changes as usual - The
process in the remote container watches for those changes and responds to them, e.g. by compiling your code and then restarting your server. - You can use the
flag so that it has time to compile and restart between changes. You may also want to tweak liveness probes here if it takes a long time for the server to restart, so that K8s doesn't evict the pod in the meantime.
Thanks for the watchexec tip!
Hi there 🙂 also trying to figure out how to get to the best dev experience for developing a web server with a compiled language like Rust (sorry if this is the place spot to post) what I'd like to get to - have a preview environment running where I can click around the frontend of our app - I find a bug! - I add a print statement or fix the bug or do a minor change and hit save in my editor - Rust webserver restarts automatically and I can click around the frontend again what is the current best practice here? 🙂 (local mode looks super exciting! but our Rust backend does call other services... is there an ETA for when the reachability of other services limitations will be lifted? 🤔 =>
Hi @millions-family-77940! Reachability of the underlying services can be a hard-to-implement task with the current local mode machinery, which is pretty lightweight. As as alternative, we have ben thinking about supporting Teleprecense in Garden core and using it as a basis for advanced local mode use cases. We haven't started any progress on that yet.
@millions-family-77940 have you looked into Dev Mode? I am not a Rustacean but I peeked into the tooling around Rust and web servers and it looks like what Rust people do is run
. Then you'd set up your sync folders between your local environment and remote environment. I do this with Python in this video:

our problem with dev-mode is that our Docker containers only contain the binary not the source files as of now (so not possible to recompile and restart the server within the docker container once it's built). I guess we might need to change that if we want to make better use of the dev mode 🤔
I think the thing we'll look into next is mirrord (very similar to telepresence) to see how that might help us 🙂
Ah, gotcha, in that case something you could try is targeting a different stage given a multi-stage Dockerfile that contains the source code when in the dev environment, for example
You could do this with conditionals in your Garden files and the
Just thinking out loud. If mirrord works, let us know! I've seen it pop up in the kubernetes reddit a few times before.
hello! i'm the resident rust enthusiast at garden 🦀 i'm adding a quick rust example here, i hope this helps!
@millions-family-77940 for the example above, i solved this by using a separate dockerfile with
cargo watch
on it, and a separate dockerfile for the release deployment. let me know if this would work for you or if you need additional help!
awesome, thanks a lot! I'll pass it on to our devs and will let you know if there are more questions 🙂
I've had an idea inspired by how
does things: if there was a way to detect if devMode is active for a service, then one could use a conditional for the image, so that it uses a separate dev image (with all the tooling required for that), that allows sync'ing files and all that, while not needing to touch the prod image (that shouldn't contain all that kind of stuff). e.g. we could have two container builds that a helm module depends on (conditionally via template ternary test on devMode being active or not). one is a devMode one and a standard "deploy" one. then in the service we can again use a ternary conditional to specify the image used for the service etc. Is there already a way to detect in a template if devMode is active? That'd be a killer addition I think.
Another tip for people needing to reach for local mode: the problem with reaching services inside the cluster (DNS and connectivity) can be solved by adding
( into the picture. It can even be started/stopped as part of the workflow or similar to ensure that at the point where the local mode service starts the local machine is able to access all DNS names and service ports just as if it had been running within the k8s cluster. This is similar to how one would use
, but I believe easier to include in a smooth workflow since you don't need to know the name of any pods etc. Rely on
for the reverse port forwarding of traffic FROM cluster TO local service, and on kubefwd for portforwarding of traffic FROM local service TO cluster.
I created a feature request for the devMode info being available in the module context:
In @ancient-diamond-80011 's example he used environments for the same purpose, but an environment is a global setting while devMode is module specific and hence seems more appropriate:
That feature request immediately got a comment with a workaround that is applicable today: