githubnemo/CompileDaemon

Reload not working on OSX

paologf-mb opened this issue ยท 13 comments

I'm setting up a project in Go following this guide https://levelup.gitconnected.com/how-to-live-reload-code-for-golang-and-docker-without-third-parties-ee90721ef641 , on Linux it works fine. Using it from mac when I change a file from my editor, the file into the container change but CompileDaemon doesn't recognise the change and doesn't rebuild.
If I enter the container and save the changed file, CompileDaemon rebuild.

DOCKER FILE

FROM golang:latest

WORKDIR /go/src

DockerCompose

version: '3'
services:
  app:
    build:
      context: .
    volumes:
      - ".:/go/"
    container_name: golang_app
    command: bash -c "go get github.com/githubnemo/CompileDaemon && CompileDaemon -command="./app""
    ports:
      - "8080:8080"
    tty: true
    depends_on:
      - db

VERSIONs

OSX Catalina 10.15.2
Docker version 19.03.5 ( Using Docker Desktop application)

Any help?

@paologf-mb Did you try it with go 1.12?

Same as #44
I suspect its how the container sends events to the host due to the difference in file systems and their synchronization. Sometimes it works fine and sometimes it stops working altogether. Removing large folders like vendor and .git helped the rebuilds. Giving more resources helped as well, but it still occurs from time to time

In my case, it was Docker issue. After reinstallation of Docker, everything worker fine. Thanks!

@pycckuu I tried reinstalling docker but it didnt work, plus I have tried it over 10 MacBooks at work and same result for everyone, reload works several times and afterwards doesn't recognize changes.

Sadly I have no macs available so it is hard for me to debug this but I doubt there is anything I can actively do at this point. It is either fsnotify/fsnotify that has issues or the implementation of the bind mount between MacOS host and the container.

Thanks to @HurSungYun, CompileDaemon now supports -polling=true which switches from FS notifications to active polling for changes. While this is neither instant (notifications are delayed by the polling rate) nor resource friendly (always looking instead of being event driven) it is a workaround to help get people back to work. I strongly discourage you from using this in any production environment.

@githubnemo It would be great if warnings are documented in READMD.md. Can I update it?

Btw, I believe using hot-reload daemon for production is not a good practice in itself, isn't it?

oh you already updated it. nevermind XD

@githubnemo It would be great if warnings are documented in READMD.md. Can I update it?
oh you already updated it. nevermind XD

Yep but thanks anyway :)

Btw, I believe using hot-reload daemon for production is not a good practice in itself, isn't it?

I have nothing against using fsnotify based hot-reload but using polling should be discouraged as it is quite wasteful and should never become a default or habit just because there's a bug somewhere.

(But you are right of course, normally you would expect your artefacts to be stable and not need hot-reloading once shipped to production, as such I would see it as bad practice to use hot-reloading in production.)

I started having this problem with the latest versions of docker-desktop. One thing I noticed was the default behavior of enabling the Use gRPC FUSE for file sharing flag in the preferences. Turning this off, and restarting my machine, seemed to resolve the issue.

Screen Shot 2020-12-05 at 10 02 43 PM

Perhaps others will have luck with toggling this option off?