Fix 'ocitool push' for oci_images based on other oci_images - #141
Merged
BryceBeagle merged 1 commit intoSep 9, 2026
Merged
Conversation
There's been a bug in the `OCILayout` implementation where it did not contain the correct metadata for pushing an `oci_image` where the base is another `oci_image`. The way `rules_oci` works is it build each blob in the bazel build dir, and then creates a blob -> path mapping called `blob_index` that is used at push time. The previous implementation naively assumed that an image would only ever have one `blob_index` map, but this isn't the case. Every image has one for itself and its base(s). This hasn't been an issue because the push operation short-circuits: if a blob is already in the registry, it doesn't try to push the blob again. If it doesn't try to push the blob, it doesn't try to find the blob in the `blob_index`. This was fine because until now all `base`s for images we had been using were "remote" ones (i.e. already pushed to the registry). But I'm trying to create an `oci_image` target that bases itself on another in-repo `oci_image` target. In this case, the base's blobs _aren't_ in the registry, the push operation tries to push them, and then freaks out because the `blob_index` doesn't have the metadata. This PR fixes this so that `blob_index` is turned into `direct_blob_index` (for the current image) and `transitive_blob_indices`, a superset that also includes the index/es for the base. These indices are then _all_ provided to the push tool, we can properly find the blobs at push time.
BryceBeagle
marked this pull request as ready for review
September 9, 2026 12:30
shlomobenyaminov
approved these changes
Sep 9, 2026
Contributor
Author
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
[email protected] cancelled this merge request build |
BryceBeagle
deleted the
bryce.beagle/fix-ocitool-push-for-layered-rules_oci-images
branch
September 9, 2026 14:07
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
There's been a bug in the
OCILayoutimplementation where it did notcontain the correct metadata for pushing an
oci_imagewhere the baseis another
oci_image.The way
rules_ociworks is it build each blob in the bazel build dir,and then creates a blob -> path mapping called
blob_indexthat is usedat push time.
The previous implementation naively assumed that an image would only
ever have one
blob_indexmap, but this isn't the case. Every image hasone for itself and its base(s).
This hasn't been an issue because the push operation short-circuits: if
a blob is already in the registry, it doesn't try to push the blob
again. If it doesn't try to push the blob, it doesn't try to find the
blob in the
blob_index.This was fine because until now all
bases for images we had been usingwere "remote" ones (i.e. already pushed to the registry). But I'm trying
to create an
oci_imagetarget that bases itself on another in-repooci_imagetarget.In this case, the base's blobs aren't in the registry, the push
operation tries to push them, and then freaks out because the
blob_indexdoesn't have the metadata.This PR fixes this so that
blob_indexis turned intodirect_blob_index(for the current image) andtransitive_blob_indices, a superset that also includes the index/esfor the base.
These indices are then all provided to the push tool, we can properly
find the blobs at push time.