watchexec/cargo-watch

cargo-watch doesn't rerun application on changes within a Docker container

Red3nzo opened this issue · 5 comments

Red3nzo commented

Currently writing a staging environment before pushing to prod & need to use a Debian based (rust:1.63-slim-buster) container which will run executable along side my rust executable.

The issue I'm getting is that cargo-watch only seems to run once & that is only on container startup, any changes made to the code that is mounted via volumes doesn't trigger cargo-watch whatsoever.

My `docker configs

// DOCKERFILE
FROM rust:1.63-slim-buster

WORKDIR /usr/src/app

RUN apt-get update \
  && apt-get install -y socat

RUN cargo install cargo-watch

COPY . .
RUN chmod +x ./staging-entrypoint.sh
RUN mv ./staging-entrypoint.sh /usr/local/bin

EXPOSE 3100

// DOCKER-COMPOSE
version: '3.5'

services:
  core:
    container_name: 'core'
    image: <in_house_image>
    volumes:
      - ./core/.:/usr/src/app
    ports:
      - 3100:3100
    entrypoint: [ "staging-entrypoint.sh" ]

Shell script to trigger

#!/bin/sh
set -e

echo "Establishing connection to server through TCP"
exec <PRIVATE_COMMAND>

echo "Starting core staging exec"
exec cargo-watch -w /usr/src/app/src -x 'run'

The following doesn't trigger any updates at all, I have to mainly rebuild the docker container to see my changes. Even though the changes have been mounted to the container.

Container starts, hangs here & never recompiled

core  | warning: `core` (bin "core") generated 9 warnings
core  |     Finished dev [unoptimized + debuginfo] target(s) in 3.76s
core  |      Running `target/debug/core`
passcod commented

This depends entirely on what the underlying host/docker filesystem and volume integration does. In many cases, file events are not emitted at all due to these internals. You can try:

  • using polling mode
  • using cargo watch from outside docker, sending a signal to the docker container or command to the docker daemon
  • varying the storage driver if possible on your setup
dragonnn commented

I did hit the same issue with is strange because that worked for months inside the container fine.
I don't think this is a bug inside cargo watch but some update in my system must caused this :/

passcod commented

If you could say which platform this is on and the output from docker info, that could be helpful! Will tell us the storage driver and versions etc, maybe we can find something in a changelog...

dragonnn commented

Sure, no problem!

docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  compose: Docker Compose (Docker Inc., 2.10.2)

Server:
 Containers: 29
  Running: 5
  Paused: 0
  Stopped: 24
 Images: 297
 Server Version: 20.10.18
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: false
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runtime.v1.linux runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6.m
 runc version:
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.19.7-arch1-g14-1
 Operating System: Arch Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 22.9GiB
 Name: rog
 ID: GAC3:NXQH:4LNF:SZS7:2S36:CU3C:Z6DI:PVIF:K6S3:A2WQ:26RX:4PNS
 Docker Root Dir: /home/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
    ...snip
 Live Restore Enabled: false

I only found that: docker/desktop-linux#30

dragonnn commented

That strange, today it is working.
Maybe a reboot fixed it :/