Doesn't GCR support pagination?

[nakabonne]

Hi, thanks for making the quite useful package. I love this one.

The v1/remote looks to implements the client that always uses the Link header value when proceeding through results linearly.

go-containerregistry/pkg/v1/remote/list.go

Lines 52 to 59 in 3584fa0

	uri := &url.URL{
	Scheme: repo.Registry.Scheme(),
	Host: repo.Registry.RegistryStr(),
	Path: fmt.Sprintf("/v2/%s/tags/list", repo.RepositoryStr()),
	// ECR returns an error if n > 1000:
	// https://github.com/google/go-containerregistry/issues/681
	RawQuery: "n=1000",
	}

Wheres the v1/google package seems to not have any option to do that.

go-containerregistry/pkg/v1/google/list.go

Lines 79 to 106 in 3584fa0

	func (l *lister) list(repo name.Repository) (*Tags, error) {
	uri := url.URL{
	Scheme: repo.Registry.Scheme(),
	Host: repo.Registry.RegistryStr(),
	Path: fmt.Sprintf("/v2/%s/tags/list", repo.RepositoryStr()),
	}
	req, err := http.NewRequestWithContext(l.ctx, http.MethodGet, uri.String(), nil)
	if err != nil {
	return nil, err
	}
	resp, err := l.client.Do(req)
	if err != nil {
	return nil, err
	}
	defer resp.Body.Close()
	if err := transport.CheckError(resp, http.StatusOK); err != nil {
	return nil, err
	}
	tags := Tags{}
	if err := json.NewDecoder(resp.Body).Decode(&tags); err != nil {
	return nil, err
	}
	return &tags, nil
	}

It means Google Container Registry doesn't implement it, or just this client hasn't implemented it yet? Sorry if this sounds dumb, but it would be great if you could let me know.

[jonjohnsonjr]

Hi, thanks for making the quite useful package. I love this one.

Thanks! I really appreciate it.

It means Google Container Registry doesn't implement it, or just this client hasn't implemented it yet?

GCR doesn't implement this pagination, mostly for historical reasons. If you look at the response, GCR adds a bunch of non-standard fields, including a map from image digest to some metadata. This makes the response a lot more useful, but also makes pagination troublesome...

It's hard to know if clients actually care about only tags, or if they also care about that manifest map. We could paginate just the tags and not populate the manifest map for paginated requests, but that would break clients that care about the manifest map.

In theory, we could paginate both the manifest map and the tags list, but that would make the http handler a lot more complicated, so we just settled on returning the whole response until someone complains.

Out of curiosity, what would you expect to happen for a paginated request? Also, why would it be useful to you?

Sorry if this sounds dumb, but it would be great if you could let me know.

Not dumb at all, it's a very reasonable question.

[nakabonne]

In theory, we could paginate both the manifest map and the tags list, but that would make the http handler a lot more complicated

That makes sense!

Out of curiosity, what would you expect to happen for a paginated request? Also, why would it be useful to you?

As you may know, I currently implement a program that periodically calls google.List() to determine the latest tag. Then I'm now worried about that the result could be quite a large size if there are a lot of tags. The document of Docker Registry API V2 also says:

For repositories with a large number of tags, this response may be quite large. If such a response is expected, one should use the pagination.

https://docs.docker.com/registry/spec/api/#listing-image-tags

I haven't actually measured the response size to see if it is realistic, but if possible, I would like to avoid a single response size that is unexpected.

(Btw, my problem will be solved, if there is another way to detect the latest tags for a specific image other than listing all tags)

[github-actions]

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.