feat: make rpm-ostree use oci-dir + rootless CI - #261
Conversation
This is a way to use rpm-ostree inside a container without root privileges during the build. Fixes: ublue-os#260
|
with this PR with this PR + oci-archive 5m 20s for build |
This is created now when rechunking with rpm-ostree. We always clean it up but users may want to inspect it, it should never be committed.
|
We especially want rooless CI in the future because ubuntu 26.04 uses sudo-rs where the |
|
We can output to oci-archive which makes uploading as an artifact a bit nicer (and podman/skopeo can directly consume) This would add some time likely to the output. But I very much like going down this path to avoid using sudo -E |
I don't really have a strong opinion about it |
| --from "localhost/${target_image}:${tag}" \ | ||
| --output containers-storage:"localhost/${target_image}:${tag}" | ||
| --rootfs /rpm-ostree \ | ||
| --output oci-archive:/run/out/"${target_image}.oci" |
There was a problem hiding this comment.
with the oci-archive I get this now sometimes when running it locally and yeah it definitely takes longer than oci-dir
Copying config 8aebf9f31a done |
Writing manifest to image destination
+ CHUNKED_IMAGE=8aebf9f31ac8f7ebc95270507de2edf6ed1fb44ffbde7e2c4a5dc656725e2fb2
+ podman tag 8aebf9f31ac8f7ebc95270507de2edf6ed1fb44ffbde7e2c4a5dc656725e2fb2 image-template:latest
+ rm -rf ./image-template_rpm-ostree_OvEZzt
error: interrupted by SIGINT
m2 likes this for direct uploads via workflow artifacts
06c1924 to
cd98ea3
Compare
bsherman
left a comment
bsherman
left a comment
There was a problem hiding this comment.
I didn't measure any timings, but I did run this locally doing a just build and a just ostree-rechunk (and a just rechunk for giggles).
Seems to work well.
| --pull=never \ | ||
| --mount=type=image,src="${target_image}:${tag}",target=/rpm-ostree \ | ||
| --privileged \ | ||
| -v "/var/lib/containers:/var/lib/containers" \ |
There was a problem hiding this comment.
Out of curiosity could this line just have been -v "~/.local/share/containers/storage:/var/lib/containers" \ and then we wouldnt have to mess around with the oci archive?
There was a problem hiding this comment.
no, I would have preferred it this way actually IF IT WORKED, try what happens if you use ~/.local/share/containers/storage in any capacity
There was a problem hiding this comment.
You are actually able to specify a driver to make container storage work. See MDev-Linux@ecf2b3b
There was a problem hiding this comment.
huh, really good to know that you can actually make this work, was this documented somewhere?
There was a problem hiding this comment.
https://github.com/containers/image/blob/main/docs/containers-transports.5.md
Would you like me to open a PR for that?
There was a problem hiding this comment.
https://github.com/containers/image/blob/main/docs/containers-transports.5.md Would you like me to open a PR for that?
If it faster then I think it might me worth looking at, it doesn't matter super much anyway, although we would be losing out on the potential of pushing the oci archive as a workflow artifact (without additional steps)
There was a problem hiding this comment.
I'm thinking it may be better to do it in a later step, because it seems wastefull to compress the image into an archive and then decompress it back to container storage just to push it to the registry. CHUNKED_IMAGE="$(podman pull oci-archive:"${RPM_OSTREE_OUTPUT_DIR}/${target_image}.oci")"
Ill open a PR here shortly.
Improves build performace on #261 by writing the image layers directly to the host container store instead of compressing to an OCI archive then decompressing before pushing to the registry. Co-authored-by: renner <80410025+renner0e@users.noreply.github.com>
4 participants
This is a way to use rpm-ostree inside a container without root
privileges during the build.
Fixes: #260