Skip to content
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

Filters, matchers, and elision (tracking issue) #821

Closed
jonjohnsonjr opened this issue Nov 10, 2020 · 1 comment
Closed

Filters, matchers, and elision (tracking issue) #821

jonjohnsonjr opened this issue Nov 10, 2020 · 1 comment
Labels
enhancement New feature or request lifecycle/stale

Comments

@jonjohnsonjr
Copy link
Collaborator

jonjohnsonjr commented Nov 10, 2020

Something that has come up a lot is that it's cumbersome to resolve an index to the appropriate image.

Filters and Matchers

remote will kind of do this for you if you pass an appropriate WithPlatform when calling remote.Image or remote.Descriptor.Image on an index.

layout is even more frustrating, because the top level interface is itself an index. If an index is written to a layout.Path, you will have to iterate over the layout.Path.ImageIndex() to find it, then iterate over layout.Path.ImageIndex().ImageIndex(h) to find the appropriate child image. This is a lot of code.

Doing this kind of thing is common enough that we should add helpers to partial. (#797)

One thing that current implementations have mostly punted on is recursive indexes, which we should consider for a more general implementation. Sometimes, you want to just consider an artifact's direct children when looking for something. In other situations, it makes sense to recurse through everything.

Elision

When writing an artifact, sometimes we don't actually want to write everything that's referenced by it. It would be nice to leverage any matching/filtering infrastructure for the elision API, if it makes sense.

Examples:

We may want only to write manifests to a layout.Path to represent a collection of images that has been pushed to a registry, since downloading the blobs would be slow. (tektoncd/pipeline#216)

We might only want to write a single image from an index to a layout.Path, but we want to include the index that references it so that we can fetch its siblings later if needed or maintain only the relevant parts of the Merkle DAG for verification. (#817)

When writing to the docker daemon, we may only want to omit layers that are already present in the daemon's image store. (#205)

cc @deitch

@github-actions
Copy link

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request lifecycle/stale
Projects
None yet
Development

No branches or pull requests

1 participant