Pull fails after commiting inside docker container.

[tri-ml]

Pull fails after commiting inside docker container.

[tk-woven]

Thanks for reporting this!

I just inspected the Docker configuration. make docker-start-interactive drops you into a Docker container as root. Any command you run that creates files will have the behavior you describe on your host. Looking at what the command actually executes:

$ make docker-start-interactive 
docker run \
  -it \
  --rm \
  --shm-size=1G \
  -e AWS_DEFAULT_REGION \
  -e AWS_ACCESS_KEY_ID \
  -e AWS_SECRET_ACCESS_KEY \
  -e DISPLAY=:1 \
  -v /home/tk-woven/dgp:/home/dgp \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v ~/.ssh:/root/.ssh \
  -v ~/.aws:/root/.aws \
  -v /tmp/.X11-unix/X0:/tmp/.X11-unix/X0 \
  --net=host \
  --ipc=host

I don't see any mapped files that look like the pre-commit cache. So, pre-commit should only be placing files inside the context of your container. That the error you see is in particular is with permissions under .git, I suspect this is related to running git operations only. This will affect your host as the codebase is bind-mounted from your host into the container.

As for the git issues inside the container, git does not seem to be provided in the image fetched by docker pull ghcr.io/tri-ml/dgp:master. I'm guessing you installed it locally.

Bad owner or permissions on /root/.ssh/config

Since you are operating as root, I believe what is happening here is that git is refusing to use your SSH identity because your active user is root but the uid/gid on your ssh files is brought in from your host environment and is not literally root.

[tk-woven]

BTW I've never actually used the Docker container for development myself, only the virtual environment. I'm guessing the folks who set up this workflow only intend for users to make code changes inside the container and not perform git operations. We'd still hit permissions issues if people created even source files inside the container, though.

[nehalmamgain]

I'm guessing you installed it locally.

Right, the GETTING STARTED also provides instructions on this

To set up linters wherever you plan on using git from (either on your host or inside the container), run

# If in Docker, run the following; otherwise skip this block.
dgp$ apt update
dgp$ apt install -y git
dgp$ git config --global --add safe.directory /home/dgp

# Set up the linters.
dgp$ make setup-linters

BTW I've never actually used the Docker container for development myself, only the virtual environment. I'm guessing the folks who set up this workflow only intend for users to make code changes inside the container and not perform git operations.

Hm understood. So I should run pre-commit separately inside container and always commit with --no-verify outside container...

[nehalmamgain]

Btw from the docs, it seems the workflow allows for users to use git inside the container (just not on devices where user doesn't have root permissions I guess...)

To set up linters wherever you plan on using git from (either on your host or inside the container)

[tk-woven]

Thanks; maintainers should probably change the docs to avoid guiding users into the situation you found yourself in. I have to delegate this at this time, though.

[tk-woven]

Maybe an opportunity for @ryo-takahashi-1206 and company to support?

[ryo-takahashi-1206]

Thank you for sharing. I will do the followings within 1 week:

• Try bringing the host UID to the container
  • if no one is affected, make this the default behavior
  • Otherwise, invent some option to bring the host UID
• Or, show alarts in make docker-start-interactive and the relvant docs

[tk-woven]

Thanks so much Takahashi-san; SGTM :)

[nehalmamgain]

Thank you Tyler and Takahashi-san 🙇‍♀️

[nehalmamgain]

Linking the fix for the issue: #138

[ryo-takahashi-1206]

@nehalmamgain
Please close this issue if you become happy with #138 🙇

[nehalmamgain]

Thank you for the fix!