This is listed under "Tier 1: Replace Immediately" in the Inclusive Naming Initiative:
https://inclusivenaming.org/word-lists/tier-1/#master

Lets say I have 2 files, up.sql and rollback.sql that I want to push to the registry so that in my devOps I can pull them down (and display in the release pipeline)

Push the first file

oras push demo.azurecr.io/demo-app:latest  --manifest-config NUL:application/vnd.unknown.config.v1+json .\up.sql:application/vnd.unknown.layer.v1+sql

then the second one

oras push demo.azurecr.io/demo-app:latest  --manifest-config NUL:application/vnd.unknown.config.v1+json .\rollback.sql:application/vnd.unknown.layer.v1+sql

And then when I pull I only get the last one I pushed (rollback.sql)

oras pull demo.azurecr.io/demo-app:latest  --media-type application/vnd.unknown.layer.v1+sql

I have tried various versions of these commands without success.

Anyone here that can point me to the thing I´m missing/misunderstanding?

The TOB approved the following project:

• Update the [OCI distribution-spec][distribution-spec] to generically reference [OCI manifest][image-manifest] and [OCI index][image-index], with [OCI Image][image-spec] as one of many artifact types it can store.

Just opening up an issue on this to track progress...

Tracks adding a config descriptor to index, enabling index to be a type of artifact.
This would support:

• Notary v2 signatures, persisted as indexes, enabling existing linkage and garbage collection
• CNAB

The guidance here is more harmful than if it simply didn't exist.

Encouraging the proliferation of custom mediaTypes (rather than reusing existing, registered types) reduces the ability to reuse software. If your layers are gzipped tarballs, there's no reasons to invent a unique layer media type.

There's no reason to prescribe an opinionated framework on top of RFC 6838. This guidance just obscures what artifact authors should be looking at.

Follow up to #46 and #61

This repo causes lots of confusion for people asking "What is an OCI Artifact". If we need better language in image-spec/distribution spec around this definition, then we should do that instead, and redirect this to that page.

The important behavior here has been codified into distribution-spec. Please see https://github.com/opencontainers/distribution-spec/blob/main/spec.md#pushing-manifests-with-subject

Append a descriptor for the pushed image or artifact manifest to the manifests in the referrers list. The value of the artifactType MUST be set in the descriptor to value of the artifactType in the artifact manifest, or the config descriptor mediaType in the image manifest. All annotations from the image or artifact manifest MUST be copied to this descriptor.

Hi, I am trying to push a VHD file as an oci artifact to azure container registry using oras push command. The file size is 9gb approx and I'm seeing the following error:

Preparing vhdfilename.vhd
Uploading 2fff39d3fd1a vhdfilename.vhd
time="2022-06-01T12:59:21+05:30" level=warning msg="reference for unknown type: application/vnd.unknown.config.v1+vhd" digest="sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" mediatype=application/vnd.unknown.config.v1+vhd size=0
time="2022-06-01T12:59:21+05:30" level=warning msg="reference for unknown type: application/vnd.oci.image.config.v1+vhd" digest="sha256:2fff39d3fd1a01c5fb6287dc5f62e08b87f78ef32da0f5264821cd8b30e7f4c4" mediatype=application/vnd.oci.image.config.v1+vhd size=10000269824
Error: failed to copy: failed to do request: Put "https://somahantaregistry.azurecr.io/v2/images/vhdimagename/blobs/uploads/a064371b-522c-444e-a1c9-7a4d49d1189d?_nouploadcache=false&_state=HwNK2cj-sTQ_eOUO1LwCqyS4N_JMBTMKmNFsV8nJzXt7Ik5hbWUiOiJpbWFnZXMvc2ltcGx2bWltYWdlIiwiVVVJRCI6ImEwNjQzNzFiLTUyMmMtNDQ0ZS1hMWM5LTdhNGQ0OWQxMTg5ZCIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAyMi0wNi0wMVQwNzoyOTozMC4wMDUyMzQxNzRaIn0%3D&digest=sha256%3A2fff39d3fd1a01c5fb6287dc5f62e08b87f78ef32da0f5264821cd8b30e7f4c4": write tcp 192.168.29.71:51899->52.168.114.2:443: wsasend: An existing connection was forcibly closed by the remote host.

Just FYI, to check if I'm doing something wrong, I tried pushing another VHD file of approx. 500Mb size using same command (just changed the filename), and was successfully able to push and pull it as well.

I am not able to understand why I am not able to push the bigger file.

Thanks

The TOB approved the following project:

• Update the [OCI image-spec][image-spec] to reference images as an implementation of artifacts, using [OCI manifest][image-manifest] and [OCI index][image-index]

Just creating an issue to track progress..

Capture how artifact authors can provide localized strings and logos for how their artifact can be visualized in registry specific tooling.
This surfaces the details captured here: https://github.com/opencontainers/artifacts/blob/f9710ad60b6de311843df88d8f8fa1e6d0d44b50/authoring-artifacts.md#optional-publishing-the-artifact-type

We initially focused on putting config in the mediaType, and including a +json on the extension, simply as momentum for how they were represented at the time.
We later clarified config should be reserved when there's actually a config object, and the +json|+yaml should be reserved to represent how the optional config blob is formatted.

The current docs at Defining a Unique Artifact Type don't clarify config, and show examples of using config, even though no config object is actually used.

TODO:
Add clarity to define an artifact type with a shortened string, only including config in the string if an actual config object is represented, including +json|+yaml|+txt to represent the actually config formatting.

Capturing a request for how registry operators and registry vendors can upload the artifactType.json schema. And, how the distribution-spec would present the supported types.
The list of supported types might be per repo, or per registry.
This would ultimately be a spec enhancement (PR) on distribution, but tracking here as part of artifacts.

In the approved TOB Proposal for artifacts, we reference manifest.config.mediaType as the means by which we define a unique artifact and layer.mediaType used to uniquely define artifact layers.

OCI Artifacts Project Proposal
2. registry operators and vendors - guidance for how operators and vendors can support new artifact types, including how they can opt-in or out of well known artifact types.
Registry operators that already implement media-type filtering will not have to change. The artifact repo will provide context on how new media-types can be used, and how media-types can be associated with a type of artifact.

Vote on Clarification

Maintainer approval

• @dmcgowan
• @SteveLasker
• @mikebrow
• @stevvooe

This issue is a clarification to be used in subsequent how-to content and the pending artifacts spec.

Specifically:

• manifest.config.mediaType defines unique artifact types
• layer.mediaType defines artifact layers

References

OCI Meeting Notes References:

• OCI Hackmd July 17, 2019 notes:

• At the top of the artifacts explain the index and manifest defintions
• Within the repo have a collection of exsting artifacts, including the image spec mediaTypes, similar to the PR on distribution
  "Artifacts are defined by setting the manifest.config.mediaType to a globally unique value. The following format is used to differentiate the type of artifact:
  application/vnd.[org|company].[objectType].[optionalSubType].config.[version]+json

Helm registry & Singularity push as reference implementations.

• Helm references:
  • manifest.config.mediaType = "application/vnd.cncf.helm.config.v1+json" reference
  • layer.mediaType = "application/vnd.cncf.helm.chart.content.layer.v1+tar" reference
  • ORAS reference to support OCI Artifacts
• Singularity references:
  • manifest.config.mediaType = "application/vnd.sylabs.sif.config.v1+json" reference
  • layer.mediaType = "appliciation/vnd.sylabs.sif.layer.tar" reference
  • ORAS reference to support OCI Artifacts

I want to use OCI Artifacts to store video files (remote desktop session recordings) efficiently, and one thing I would need is a way to play the videos files directly in a browser, without downloading them locally first. Since we can already declare a proper mime type for the artifacts (mediaType field), all that would be required is a blob URL that responds with the proper mime type, allowing the browser to recognize the contents and play it directly as it is being downloaded.

Using the proper mime type should make video files playable in the browser either by opening the URL directly, or by embedding the blob URL inside the HTML5 video tag.

My primary use case here is video files, but the same applies for audio files and images files, or anything that can be opened directly in a browser given the correct mime type.

I understand that support for "artifact indexes" similar to "image indexes" is expected to come in the future.

The OCI image specification doesn't support mixing image references (the manifests list of an image index) with image payload and image config (the config and layers list of an image manifest). Is it planed to make the OCI artifacts specification drift a bit from it allowing a mixture of both?

The use-case how I came to this is following. An artifact consists of:

• A configuration file (config in a manifest).
• Some files (layers in a manifest).
• A container image (manifests in an index).

But in general the idea is that an artifact can have it's own files and references to other artifacts (being a container image a special artifact type), being the artifacts tools capable of handle the referred artifacts as part of the artifact itself... For example, push/pull an artifact including all referred artifacts.

Of course you can put an image name or artifact name in the configuration and then recursively resolve those references, but having it all integrated makes the management much easier.

It appears the progression of this work is now located at https://github.com/oras-project/artifacts-spec

Can we mark this repo INACTIVE by prefixing the description with [INACTIVE] similar to these repos?

• https://github.com/opencontainers/runc.io
• https://github.com/opencontainers/web

And archiving them in GitHub settings?

There's no clear definition about what's an artifact, although the meaning can be found when reading the specification. It's nevertheless meaningful having a clear definition, because the term "artifact" is extremely overloaded.

I tend to call the files of an artifact "artifacts" themselves and then started calling the artifact "artifact set", until realizing the nonsense. But it should illustrate the need for a clear statement of what is an artifact.

What probably also makes it misleading is the plural in the name: artifacts. There's the OCI Image Specification (notice the singular in the name) and the OCI ArtifactS Specification (notice the plural), what sounds like specifying how to use a registry to store an "artifact set or bundle" containing multiple artifacts.

OCI specs appear to have releases (e.g., image spec and distribution spec). These are great for consumers of the specs because we know where they stand. If something is a feature addition, breaking change, and so forth. And, if someone implements a spec we know by the version when things break.

Can we get released versions of artifacts?

Without releases I can't tell its stability. Is this an experiment that might easily change or something that's stable with staying power?

Tracking for the creation of a branch titled reference-types under the oci-artifacts project

This branch would provide an open and transparent location for the incubation and validation of the working group to store artifact reference types within registries.

The /artifacts/tree/reference-types branch provides a vendor-neutral location for such incubations, fostering collaborative feedback for registries to implement reference type artifacts. This working group will strive to move these goals forward while gaining experience and valuable user feedback.

Artifacts Table of Contents

The following is the working plan for the Artifacts TOC.

Individual Content PRs

As each section will have various forms of feedback, I'll be breaking up the latest content into separate PRs.

This working TOC gives a bigger picture perspective of what's currently known. ("We don't know what we don't know") - so, help us know what you'd like to see.

Stable Links

As others provide links to content, moving content between different files and headings makes it more difficult to maintain those links. Getting the TOC (files and headings fixed) will minimize churn to consumers.

If you have other content you'd like to see added, please comment here so we can structure the files and headings appropriately.

Comments including:

• Needed Content (sections & scenarios)
• File Naming
• Heading Names, Within the Files

Working TOC

• Readme.md

  • What makes an artifact PR #5
  • Artifacts as well known types PR #5
  • Implementations- that support OCI Distribution PR #4
  • Definitions & Terms PR #3

• For Distribution Operators - Supporting Artifacts (supporting-artifacts.md)

  • Supporting Artifacts in a Registry
  • Well Known Types (consuming the list of published artifact types)
  • Displaying the Type, with Icons and Human Strings
  • Validating Artifacts
  • Importing Supported Artifacts to a Registry
  • Discovering Supported Artifacts (per registry, per repo)

• For Artifact Authors - Authoring and Publishing New Artifacts (registry-operators.md) - PR #6

  • Authoring new artifacts
  • Defining mediaTypes
    • unknown reserved
    • oci-image for docker/containerd
  • Annotations and config
  • Optional - Config Schema
  • Publishing new artifacts

• Supported Registries (implementations.md)