Clarification: manifest.config.mediaType defines artifact types about artifacts HOT 13 CLOSED

Which btw, would have been totally okay too. :)

from artifacts.

I think this encodes what we intend. At minimum, a mediaType must encode the representation of the artifact (json, protobuf, encryption, compression, etc.). We should call out that this is a many to one relationship, in that you might have multiple mediaTypes representing the same content or similarly encoded content, but their handling may differ due to the mediaType. One example is the docker and oci mediatypes for indexes. They are identical formats, handling and meaning but have different mediaTypes. Another, contrived example, might be a format that uses regular OCI layers, compatible in format, but are interpreted differently by the format.

from artifacts.

just added a vote list.. to late on friday to think about it now will look at it Tuesday :-)

from artifacts.

This looks correct and I agree with the clarification...
but...
I still have some concerns about how CNAB is making use of the spec. I saw some work to add an optional config to OCI index to allow having that definition at the index layer as well. The current problem is that if the artifact type is in the manifest and not in the index, types which use other manifests are not well represented.

from artifacts.

Thanks Derek,
I’d consider CNAB being mostly in a state of flux related to mediaTypes. I’ve been talking with @radu-matei. This is mostly due to the lack of index.config support. As a result, he’s storing the CNAB config as a manifest artifact. We need more thought on this, which is why the current artifacts prs only refer to manifests. The index work will require a rev of something, so we’ve been deferring it to a next level conversation once we get the base for Helm, Singularity, OPA and some others solid. There’s a few other registries that are waiting for this to hit a complete state for these artifacts. CNAB registry spec will continue.

from artifacts.

hey @SteveLasker is there a reason the second Singularity reference ("appliciation/vnd.sylabs.sif.layer.tar") points to a Helm reference?

from artifacts.

To prove I’m human and demonstrate the value of PRs 🙄. I’ll fix later today.

from artifacts.

Ah good! I was totally convinced you were a robot 🤖 :)

from artifacts.

and why you shouldn’t press button on a phone, geeze

from artifacts.

@SteveLasker can you explain the layer.config.mediaType syntax in your PR description? Layers don't have a config property in their descriptors or in the layer themselves, so where would that mediaType actually go?

from artifacts.

@jonjohnsonjr - sorry, not config, just layer.mediaType: https://github.com/SteveLasker/artifacts/blob/artifact-authors-how-to/authoring-artifacts.md#defining-layer-types
Here's an example for pushing a some text files with ORAS

{
  "schemaVersion": 2,
  "config": {
    "mediaType": "application/vnd.unknown.config.v1+json",
    "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
    "size": 2
  },
  "layers": [
    {
      "mediaType": "application/vnd.oci.image.layer.v1.txt",
      "digest": "sha256:b869b02df9f607e50536cb7fc2037e27e786d6bbc7481be25b99c4a6505768ef",
      "size": 8,
      "annotations": {
        "org.opencontainers.image.title": "layer1.txt"
      }
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.txt",
      "digest": "sha256:35a70bc07ae77abc9970cc9234efddfc47545e85369cce75297673ba99edc32b",
      "size": 15,
      "annotations": {
        "org.opencontainers.image.title": "layer2.txt"
      }
    }
  ]
}

from artifacts.

Yes, these are the details of what the values might represent. For the purpose of this clarification, we're agreeing we're using manifest.config.mediaType to define the artifact type, and layer.mediaType to define the layer type.

from artifacts.

Closing the issue as agreed and resolved. I'll work on updating the structure of the PRs to include a spec.md that reflects how to define and use the mediaTypes

from artifacts.