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

Display image details from Manifest v2 schema 2 (fixes #128) #168

Open
wants to merge 2 commits into
base: v2
Choose a base branch
from

Conversation

xgin
Copy link

@xgin xgin commented May 1, 2017

I borrowed ideas from #101 and made the API requests with application/vnd.docker.distribution.manifest.v2+json but without v1Compatibility.
Useful description: distribution/distribution#1252 (comment)

This PR conflicts with #167 and the rebase is required before merge.

Issue for reference #128

bvanderlaan pushed a commit to bvanderlaan/docker-registry-frontend that referenced this pull request Jun 13, 2018
The Manifest API will return information about the image or tag. This information
is stored in a schema, that schema has two versions. For older Docker clients/
registries the v1 schema is returned by default; however, newer registries
can return either v1 or v2. The API requires that you set a header to tell
it which schema version you want.

PR kwk#101 added the use of the Manifest API so we can show the Dockerfile, and
size, and labels, etc. It is setting the header of the request so that we
get the v2 version of the schema however it is parsing/expecting the V1
version of the schema. If we are using an older registry (i.e. 2.1.1) then
this works because the header is ignored and only the V1 is returned; however,
if using a newer version (i.e. 2.6.2) the v2 schema would be returned and
not parsed correctly.

PR kwk#168 modifies the use of the Manifest API so that it _does_ parse/expect
the V2 schema; however, that means that the app will no longer work in
older registries (or for images pushed by older clients) as it no longer
supportes the V1 schema.

This change set merged these two PRs together by checking the content type
header in the response to figure out which version the registry returned.
It then parses the payload depending on the schema version. With this change
the user gets a very similar experance regardless of the manifest schema version
being returned.

Note: There is likly room for performance improvments here, I plan on a larger
refactor and will like to address the ineffeciencies their
bvanderlaan pushed a commit to bvanderlaan/docker-registry-frontend that referenced this pull request Jun 14, 2018
The Manifest API will return information about the image or tag. This information
is stored in a schema, that schema has two versions. For older Docker clients/
registries the v1 schema is returned by default; however, newer registries
can return either v1 or v2. The API requires that you set a header to tell
it which schema version you want.

PR kwk#101 added the use of the Manifest API so we can show the Dockerfile, and
size, and labels, etc. It is setting the header of the request so that we
get the v2 version of the schema however it is parsing/expecting the V1
version of the schema. If we are using an older registry (i.e. 2.1.1) then
this works because the header is ignored and only the V1 is returned; however,
if using a newer version (i.e. 2.6.2) the v2 schema would be returned and
not parsed correctly.

PR kwk#168 modifies the use of the Manifest API so that it _does_ parse/expect
the V2 schema; however, that means that the app will no longer work in
older registries (or for images pushed by older clients) as it no longer
supportes the V1 schema.

This change set merged these two PRs together by checking the content type
header in the response to figure out which version the registry returned.
It then parses the payload depending on the schema version. With this change
the user gets a very similar experance regardless of the manifest schema version
being returned.

Note: There is likly room for performance improvments here, I plan on a larger
refactor and will like to address the ineffeciencies their
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant