Add guidelines for artifacts#1029
Conversation
| The [ownership, mode, and other attributes](layer.md#file-attributes) of the initial empty directory are unspecified. | ||
| The array MUST have at least one entry. | ||
|
|
||
| When the `config.mediaType` is set to `application/vnd.oci.image.config.v1+json`, the following additional restrictions apply: |
There was a problem hiding this comment.
Do these restrictions also apply to legacy data types?
Do they not apply to artifact types?
I'm confused by this language in light of #1025, is the goal to describe what registries have already implemented, or is the goal of the specification to advance the industry by defining new benchmarks for registries to meet to reach OCI conformance?
There was a problem hiding this comment.
From the fact finding, the content of the layer wasn't important to the registry, other than being non-zero and having at least one layer. This moves the verbiage around the structure of the layers, which is a client side concern, to only apply for the image.config types of images. That allows artifacts to structure their layers specific to their artifact type, any content in any order that the artifact defines in their own spec outside of OCI.
1216ab4 to
1fb7ff2
Compare
manifest.md
Outdated
| "schemaVersion": 2, | ||
| "mediaType": "application/vnd.oci.image.manifest.v1+json", | ||
| "config": { | ||
| "mediaType": "application/vnd.example+type", |
There was a problem hiding this comment.
+oci was agreed in the meeting. Please update the example to reflect guidance for single blob artifacts that want the artifactType to align with the mediaType of the blob.
There was a problem hiding this comment.
I've updated with the requested changes.
1fb7ff2 to
4e53d2e
Compare
Signed-off-by: Brandon Mitchell <git@bmitch.net>
4e53d2e to
6119843
Compare
| ```json,title=Minimal%20artifact&mediatype=application/vnd.oci.image.manifest.v1%2Bjson | ||
| { | ||
| "schemaVersion": 2, | ||
| "mediaType": "application/vnd.oci.image.manifest.v1+json", | ||
| "config": { | ||
| "mediaType": "application/vnd.example+type+oci", | ||
| "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a", | ||
| "size": 2 | ||
| }, | ||
| "layers": [ | ||
| { | ||
| "mediaType": "application/vnd.example+type+oci", | ||
| "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a", | ||
| "size": 2 | ||
| } | ||
| ] | ||
| } | ||
| ``` |
There was a problem hiding this comment.
For completeness, should this example have some annotations? It's entirely compliant as is, just a little weird that someone would want to store an artifact where the only unique information is the mediaType, "the one vnd.example+type+oci".
| }, | ||
| "layers": [ | ||
| { | ||
| "mediaType": "application/vnd.example+type+oci", |
There was a problem hiding this comment.
Setting the mediaType of the ScratchData layer to the same as the config blob here is acceptable. And people can argue about whether or not the content really is that media type, it kind of depends on what that mediaType's spec says.
But as this layer mediaType is not expected to be used to drive any sort of behaviour, unlike the config mediaType, why not use applcation/octet-stream, because when is something not an octet stream?
|
Nits were moved to #1042. I'll reopen a new PR with the decision to add an |
This is an alternate take on #1023. The goal is to document the "scratch layer" from #1025, and include details from opencontainers/artifacts that will allow us to eventually archive the repo.