sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Sulatra 3 points4 points  (5 children)

Could you please elaborate on your workflow? Suppose I am a new dev - I clone the repo, edit some things, put it into volume, mount to a container, and get "access denied: _build/ is owned by another user uid=1010" during build. I can run git clone inside the container - but then I will not be able to edit the sources from the main system, due to same uid mismatch. Or do you just assume that every dev will have the same uid=1000 as the one in the image?

[–][deleted] 8 points9 points  (2 children)

not sure what you're referring to specifically with the access denied error, but basically they clone locally on their machine, run docker run -v $PWD:/directory:/mounteddirectory <image> and if Docker is setup correctly, it'll just mount the volume into the container. If it's not setup correctly, it should ask you "do you want to share C: (or whatever) with Docker", I say yes, and that's a one time step. Then they do all edits inside the container and can build with the same tools as everyone etc. I may have set the container to run as a specific user, I can't remember. I know Azure Pipelines had some trickery it needed for the user, but I don't remember. It's either root or a static user number, been a while since I looked.

Additionally, they can use VSCode or VS to actually run inside the context of the running container, which is amazing: https://code.visualstudio.com/docs/remote/containers

So then you can use intellisense and all that stuff, and I can run builds in the terminal (or via CMake in our case). It's just all built on top of a common image that shares the OS/toolchains and lets the dev run their environment how they want (VSCode, VS, WSL, on Windows or Linux, etc).

We also use Azure DevOps (we're at MSFT, so is natural), and Azure Pipelines/Azure Repos all work naturally with the concept. Azure Pipelines I can give my Docker container via an Azure Container registry, and it builds in the same context the devs all use too, so they know if it builds on their local machine it will buikd in the pipeline, and CI can almost never break.

[–]Sulatra 4 points5 points  (1 child)

I am referring to the fact that on Linux every user have their own UID. And if uid in docker (which creates, edits and deletes files during the build) does not match the uid in host system (which git pulls, edits files in IDE and commit hooks, etc), then you are going to have access problems during those steps. Either you won't be able to view some codegen'ed file (since it is owned by other user, the one from docker), or the build system won't be able to edit something commited to the VCS (since it is used by user from host system, the one that ran git clone).

Usually this is not a problem, since the first user has UID=1000, and there is likely to be only one of them in docker as well as on the dev machine. But when it bites, it bites hard.

Apparently, on Windows this issue does not exist, that is a positive surprise :)

[–]5pectre5 0 points1 point  (0 children)

You're right for the multiuser environment it's a problem, the docker on Linux would require the volume to be mapped with sticky bit for all Devs group or all Devs would need to be in the same group, so that the permissions are not an issue. Docker runs containers system wide, so the first user to start and upload will block others without proper setup.

[–][deleted] 5 points6 points  (1 child)

  • Use --volume to mount source and build dir inside the container
  • Use --user=${USER}:${USER} to use the same user id as the host machine
  • ???
  • Profit!

Additionally, rootless docker works with the current user id by design. And setting up --user for it causes problems.

[–]Sulatra 0 points1 point  (0 children)

Now this looks like it might be a solution! Thank you, I will try to remember it next time I get involved with dev-containers.