[gfcli] gf run won't rebuild in docker container

[UncleChair]

What version of Go and system type/arch are you using?

go version go1.21.6 linux/arm64 in docker container win/x86 with WSL2 in local without go

What version of GoFrame are you using?

v2.6.2

Can this bug be re-produced with the latest release?

Yes

What did you do?

I am developing on windows with WSL2 and want to run a development environment in the docker container with tool chains, so I write a docker file:

FROM golang:1.21-alpine as base
FROM base as dev
WORKDIR /var/www
CMD wget -O gf "https://github.com/gogf/gf/releases/latest/download/gf_$(go env GOOS)_$(go env GOARCH)" && chmod +x gf && ./gf install -y && rm ./gf && gf run main.go

and a docker-compose file

version: "3"
services:
  web:
    build:
      dockerfile: Dockerfile
      context: .
      target: dev
    depends_on:
      - database
    volumes:
      - ./:/var/www
    environment:
      CONTAINER_ROLE: web
    ports:
      - "8000:8000"
    ...

After that, I used docker-compose build and up. The gf run do works for the first time, but if I change any code in the VScode in windows side, the gf run would not rebuild code in the container anymore. I tried a macOS device and it would work. So I found some reference related to WSL2. It seems that the file update on the windows side would not send notification to linux side. Similar condition with air, but air could use poll mode to solve this problems.

What did you expect to see?

gf run should rebuild the code in container

What did you see instead?

gf run will not rebuild after updating files in VScode on windows side

[gqcn]

@UncleChair The cli tool gf watches all files of *.go format in its working directory in default, using inotify component from https://github.com/fsnotify/fsnotify . According to your description, I do not think it's an issue of cli tool of gf, but the issue that the inotify could not receive the events of changed files outside the container on the mounted volume between windows host and linux container.

I've no idea about WSL2, I hope that anyone that can tell you. Or, you can submit an issue to https://github.com/fsnotify/fsnotify about this scenario of events lost.

[UncleChair]

@gqcn Thanks for your reply. But seems inotify is not considering solving it since many other projects also meet this problem. Or do you think it is acceptable to add a “polling” mode for the gf run? Though it may consume lot of resources lol.

[wohenbushuang]

I met the similar problem, and here is my finding.

First of all, the code should be stored inside WSL2 instead of on Windows disk to obtain the full Linux-like usage experience. And I used the offical demo project focus-single as the sample for test.

1. Single dev container: success

// devcontainer.json
{
	"name": "Go",
	"image": "mcr.microsoft.com/devcontainers/go:1-1.21-bullseye"
}

2. Dev container with docker compose: success

// devcontainer.json
{
	"name": "Go compose",
	"dockerComposeFile": "docker-compose.yml",
	"service": "app",
	"workspaceFolder": "/workspaces/${localWorkspaceFolderBasename}",
}

# docker-compose.yml
version: '3.8'

services:
  app:
    image: mcr.microsoft.com/devcontainers/go:1-1.21-bullseye

    volumes:
      - ../..:/workspaces:cached
      
    # Overrides default command so things don't shut down after the process ends.
    command: sleep infinity

3. Dev container with docker compose and Dockerfile (as @UncleChair did): fail

So temporarily I choose not to use Dockerfile for dev and install the toolchains such as gf, git manually. Thankfully, Golang dev doesn't need complicated environment preparation.

BTW, I don't think that "polling" is an elegant solution ...

[UncleChair]

@wohenbushuang Thanks for your suggestion! I think to obtain consistence usage of Linux should be a solution. As for my project, it would be ok to just move all the files into the WSL, since I only use go and would not introduce other development dependences. But I am not sure if there would be other projects which have a much complicate requirement that want to introduce go development, making move it to WSL painful. In that case, if they still want to work on Windows disks, they may have to introduce other tools like air with "polling" mode for the rebuilding. Anyway, it is just my assumption of a situation that a project has to work on Windows disk, I may also just put my file inside the WSL for development. I also don't think "polling" is good solution, since it just a compromise to the file notification problem when working on the Windows :)

[wohenbushuang]

I had tried polling with vite project before. The experience was awful that the polling will run out of the WSL disk IO (which is already limited) and make Windows jammed.

other projects which have a much complicate requirement that want to introduce go development, making move it to WSL painful.

You can write some shell script files.

But I still hope that the problem with Dockerfile can be solved in some day.