Skip to content

Support buildah commit --amend #6107

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

Open
arewm opened this issue Apr 3, 2025 · 4 comments
Open

Support buildah commit --amend #6107

arewm opened this issue Apr 3, 2025 · 4 comments

Comments

@arewm
Copy link

arewm commented Apr 3, 2025

I would like to run buildah in a build platform where I can inject specific files (content-sets.json) into the container filesystem after users' Containerfile-driven builds are complete. If users want to --squash their build then we can achieve this functionality by squashing the image when we commit. If users want the build layer to be distinct from the parent image (i.e. not squashing), however, buildah will add the content in a separate layer. This results in users having an unexpected last layer consisting of only the added files and not their application code.

@cgwalters
Copy link

cgwalters commented Apr 3, 2025

I would like to run buildah in a build platform where I can inject specific files (content-sets.json) into the container filesystem after users' Containerfile-driven builds are complete.

Unrelated to the RFE but: it's not clear to me that's really the desired end state. I think it'd be better to have that data written by a dnf plugin inside the layer that modifies RPMs - then it'd live in the naturally correct layer. Say I intentionally want two layers, one with RPM deps and one with the app. It's hard for an external tool to know this.

(Or also relevantly, if one wants to do content-addressed split layers then we want it in the same layer as the rpm database generally)

@cgwalters
Copy link

Or to say it a different way, every way in which a Konflux pipeline manipulates my built container image in a way that's hard to replicate with podman build is probably wrong. And the cachi2 stuff is by far the biggest violation of this principle.

@arewm
Copy link
Author

arewm commented Apr 3, 2025

I agree that the specific use case that I mentioned would be better if it was handled by dnf directly. I think that we are likely going to end up taking a slightly different approach for the use case I mentioned by generating the file before building the image and then appending a COPY command to the Containerfile. Since we are already off topic, this isn't any better for reproducibility, but it is consistent with what has beed done previously with OSBS.

Copy link

github-actions bot commented May 4, 2025

A friendly reminder that this issue had no activity for 30 days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants