feat: support rechunking using Chunkah#790
Conversation
HastD
force-pushed
the
chunkah
branch
2 times, most recently
from
effed06 to
0e92302
Compare
Add a `--chunkah` option to `bluebuild build` that rechunks the image using [Chunkah](https://github.com/coreos/chunkah), a more modern, content-agnostic rechunker that's actively maintained and should offer various improvements over build-chunked-oci and the legacy rechunker. This is implemented using a fairly generic "post-build hook" mechanism that allows a post-processing step (such as rechunking) to be applied after building the image but before tagging and pushing.
| let mut initial_args = Vec::<OsString>::new(); | ||
| if use_sudo { | ||
| initial_args.push("sudo".into()); | ||
| if blue_build_utils::has_env_var(blue_build_utils::constants::SUDO_ASKPASS) { | ||
| initial_args.push("-A".into()); |
There was a problem hiding this comment.
I think I should work on that cmd_append! macro. This feels more messy than it needs to be.
There was a problem hiding this comment.
Ok, went ahead and made it. It's called cmd_mut!. Released on version 1.5.0.
https://gitlab.com/wunker-bunker/comlexr/-/commit/1523e3e65c7d344c1ec1874b5f6567ce84f134f9
There was a problem hiding this comment.
Oh nice, that will be very useful. I'll go ahead and modify the code to use it.
There was a problem hiding this comment.
Though actually wait, this might not quite solve the messiness here, since the issue is with needing to dynamically determine the command name (not subsequent arguments).
There was a problem hiding this comment.
You can use a block for the initial command name.
let command = cmd!(
{
if this {
"that"
} else {
"other"
}
},
"arg1",
"arg2",
);There was a problem hiding this comment.
Right but it's still awkward to do something like "optionally insert sudo at the beginning of the command", since it makes the subsequent argument conditional, too. What I'd ideally want is something like
cmd!(
if condition => "sudo",
"foo",
// ...
)where it automatically handles making the first argument where the condition is met into the command name. The new cmd_mut! macro is nice, but I don't think it will actually simplify things here; the problem is that depending on a combination of conditions, any of sudo, podman, or skopeo could be the command name, and where the argument list picks up after that also depends on those conditions.
There was a problem hiding this comment.
We have the sudo_cmd! macro in the project. That does that for you
There was a problem hiding this comment.
| #[derive(Debug, Clone, Copy, Builder)] | ||
| #[builder(derive(Debug, Clone))] | ||
| pub struct RemoveImageOpts<'scope> { | ||
| pub image: &'scope str, |
There was a problem hiding this comment.
Could we try to keep this as &Reference? I'm noticing extra .to_string() calls being added which means more allocations. Also it helps to keep the API stricter.
There was a problem hiding this comment.
Yeah, I can change it back.
There was a problem hiding this comment.
Though also I wouldn't worry too much about allocations; I'm pretty sure the vast majority of BlueBuild's runtime is spent on I/O done by external processes. I haven't seen profiling data, but I'd be surprised if allocations account for more than 0.1% of runtime.
There was a problem hiding this comment.
Though also I wouldn't worry too much about allocations; I'm pretty sure the vast majority of BlueBuild's runtime is spent on I/O done by external processes. I haven't seen profiling data, but I'd be surprised if allocations account for more than 0.1% of runtime.
That's a fair point, but the extra safety in the API is still useful.
2 participants
Add a
--chunkahoption tobluebuild buildthat rechunks the image using Chunkah, a more modern, content-agnostic rechunker that's actively maintained and should offer various improvements over build-chunked-oci and the legacy rechunker.This is implemented using a fairly generic "post-build hook" mechanism that allows a post-processing step (such as rechunking) to be applied after building the image but before tagging and pushing.