Response
No Content
OCI
Delete Artifact
Delete a OCIArtifact
An OCIArtifact is a single OCI Artifact (manifest) that describes an OCI Image or other OCI Artifact.
OCIArtifacts have a MediaType that informs you what the OCIArtifact contains. For OCIArtifacts with a MediaType of application/vnd.oci.image.manifest.v1+json or application/vnd.docker.container.image.v1+json, the Architecture field will show the compute architecture that the OCI Image was built for (e.g. “amd64”)
OCIArtifacts can be associated with zero or more ProjectReleases and PackageReleases.
DELETE
Previous
List TagsList multiple OCITags
An <em>OCIReference</em> represents a relationship between an OCITag and an
OCIArtifact.
When attempting to match a customer's container image to a known
OCIArtifact, we look up an OCITag that matches a particular digest. For
mutable OCITags, that digest association, however, changes over time. Until
OCIReference was introduced, we were only storing the first known
digest for these mutable tags, which ended up introducing a lot of stale
data into the digest classification process: the classifiers were not able
to find OCITags that match newer digests for these mutable tags and
therefore less accurate classifiers like ruleset and deduction classifier
needed to try and classify the cluster inventory record.
For OCITags that are mutable -- e.g. "latest" or "stable" or "v1" -- there
can be many digests that an OCITag has previously pointed to.
Previously-referred digests for an OCITag are made available through the
OCIReference object model. You may be wondering why we don't have an
<b>References</b> field on OCITag that just returns the digests that have been
previously associated with this OCITag. The reason for that is because the
list of previously-known digest associations can be very long (it's
unbounded) and so having this information in a separately-fetched object
model that can be paginated/controlled seemed like a better design.
Next
⌘I