fix(devx): mount permission issues on Linux #1517
Conversation
✅ Deploy Preview for docs-kargo-akuity-io ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| RUN addgroup --gid ${GROUP_ID} user \ | ||
| && adduser --disabled-password --gecos '' --uid ${USER_ID} --gid ${GROUP_ID} user \ | ||
| && mkdir -p /workspaces/kargo/ui/node_modules \ | ||
| && chown -R ${USER_ID}:${GROUP_ID} /workspaces/kargo |
There was a problem hiding this comment.
This fails on Mac.
------
> [3/4] RUN addgroup --gid 20 user && adduser --disabled-password --gecos '' --uid 501 --gid 20 user && mkdir -p /workspaces/kargo/ui/node_modules && chown -R 501:20 /workspaces/kargo:
0.105 addgroup: The GID `20' is already in use.
------
Dockerfile.dev:31
--------------------
30 | # create a non-root user with the UID and GID from the caller on the host
31 | >>> RUN addgroup --gid ${GROUP_ID} user \
32 | >>> && adduser --disabled-password --gecos '' --uid ${USER_ID} --gid ${GROUP_ID} user \
33 | >>> && mkdir -p /workspaces/kargo/ui/node_modules \
34 | >>> && chown -R ${USER_ID}:${GROUP_ID} /workspaces/kargo
35 |
--------------------
Before zeroing in on the ID on the host being already in use in the container, however, there's a question of whether this could ever be expected to work on Mac or WSL anyway...
In either case, unlike the case with Linux, the Docker daemon runs inside a VM. That complicates things because one's uid and gid on the host machine aren't necessarily the same as the uid and gid of the user on the VM that executes the container.
There was a problem hiding this comment.
The latter part (around macOS and WSL2) typically should not be an issue, as the mount there tends to be a network drive which does not suffer from the same problems.
Given this, one option would likely be to only provide the build arguments when Linux arch is detected. While defaulting to some 1xxx UID/GUID when none are provided.
This addresses an issue observed on Linux systems where files written to mount paths would end up being owned by root, or files could not be read because they were _not_ owned by the container's user. It is achieved by creating a user within the development image with the same UID and GID as the caller on the host, while ensuring mount target paths do exist for this user and group before the container starts. This effectively makes the `hack-build-cli` target work while also delivering smoother operations with `hack-codegen`. In the future, we should likely rethink the way we work with tooling dependencies and their versions. As this problem was harder to tackle due to the `codegen` target performing system-global installations. Signed-off-by: Hidde Beydals <hidde@hhh.computer>
hiddeco
force-pushed
the
fix-mount-perms-hack
branch
from
053f882 to
2bb3b38
Compare
| -v $(dir $(realpath $(firstword $(MAKEFILE_LIST)))):/workspaces/kargo \ | ||
| -v /workspaces/kargo/ui/node_modules \ | ||
| -w /workspaces/kargo \ | ||
| kargo:dev-tools | ||
|
|
||
| DEV_TOOLS_BUILD_OPTS = | ||
| ifeq ($(GOOS),linux) |
There was a problem hiding this comment.
GOOS is often undefined. Would it make sense to use uname here instead?
There was a problem hiding this comment.
$(GOOS) != ${GOOS}, and actually is based on uname already. See:
Line 43 in 2bb3b38
There was a problem hiding this comment.
Apologies... I overlooked that.
Fixes #1506
This addresses an issue observed on Linux systems where files written to mount paths would end up being owned by root, or files could not be read because they were not owned by the container's user.
It is achieved by creating a user within the development image with the same UID and GID as the caller on the host, while ensuring mount target paths do exist for this user and group before the container starts.
This effectively makes the
hack-build-clitarget work while also delivering smoother operations withhack-codegen.In the future, we should likely rethink the way we work with tooling dependencies and their versions. As this problem was harder to tackle due to the
codegentarget performing system-global installations.