Ensure Docker user UID:GID matches host user UID:GID #403
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a doozy.
Recent changes to Briefcase included using Docker for ease of ensuring a consistent build environment for linux. Cross-operating system building (building linux on macos) works to a degree, and this Docker-based installation works fine on macos.
However.
Differences in implementation details of Docker for Desktop and docker-ce means that when saving computed output in mounted volumes, the owner of the created files differs between environments.
In macOS (the most tested usecase), this is the local user and their group (for macOS, the user and the group
wheel
, GID 20)In linux, this is root:root.
Once the processing is done within the container and computation continues on the host system, the linux build process on linux fails, because there is an ownership issue, given the computed files are owned by root:root
The way to fix this is to ensure that the user being used matches the UID:GID of the host. How? By passing those though in the build args (this PR), and using those values to create a user and optionally group in the Dockerfile (see beeware/briefcase-linux-appimage-template#1).
Why optionally? Ah, because of that
wheel
issue. Users in linux and macOS are guaranteed [citation needed] to have an ID larger than 500. Except wheel has an ID of 20, which can overload. So, we optionally create the group with the matching ID, but always create the user. In theory the user should always be created. The name of this user/group doesn't matter, as long as the UID/GID match. In our case, we make sure the home directory is reasonable given the username we chose (brutus, group briefcase)A note for potential future explorers: given this PR uses the current user ID, in a multi-user setup where the same linux system is used by multiple briefcase application developers and Docker image caches are shared, there could potential ownership issues should the base Docker image be used from a cache of a different user with a different UID, hence re-introducing the ownership issue this PR seeks to fix.
(In all references, macOS is macOS Catalina, linux is Ubuntu 19.04, for the testing of this PR)