-
Notifications
You must be signed in to change notification settings - Fork 288
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ephemeral lifecycle image, enabling podman support #2129
Conversation
Signed-off-by: Ozzy Osborne <bardweller@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - thanks for the PR @BarDweller 🙏🏼
@BarDweller I think I am fine with this one, if you can address the comments from Natalie I will merge it on Monday :) |
Signed-off-by: Juan Bustamante <jbustamante@vmware.com> Signed-off-by: Ozzy Osborne <bardweller@gmail.com>
Signed-off-by: Ozzy Osborne <bardweller@gmail.com>
Signed-off-by: Juan Bustamante <jbustamante@vmware.com> Signed-off-by: Ozzy Osborne <bardweller@gmail.com>
Signed-off-by: Ozzy Osborne <bardweller@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Summary
Podman will set ownership for a volume based on ownership of the first mountpoint it is mounted to, or the executing uid/gid if the mountpoint is absent.
pack
runs untrusted builds by running the first step (either detect or analyze depending on selected platform version) as root against a matched lifecycle image. Lifecycle images cannot contain a mountpoint for the workspace as lifecycle images are common across many builds that may not use the same uid/gid.Thus with podman, pack ends up causing the workspace volume to end up owned by root.
Subsequent mounts of the volume are unable to undo the ownership applied by this initial mount, leading to builds failing against podman as it becomes impossible for the build uid/gid to create or remove files within the workspace directory.
This change introduces an ephemeral lifecycle container, akin to the ephemeral builder image already in use.
The ephemeral lifecycle image adds only the workspace directory to the selected lifecycle image, when a lifecycle image will be in use. The workspace directory is added owned by the current build uid/gid, and the ephemeral lifecycle image is used instead of the chosen lifecycle image for all container invocations that would have used the chosen lifecycle image.
Output
Before
Example errors from the build would indicate permissions/ownership of
/workspace
to be insufficient for the build to proceed.After
Afterwards, builds succeed as expected
Documentation
Related
Resolves #___
Updated to swap podman rootless, for just podman, as podman rootful is equally non-functional today