Create a Component Version
Creating and Storing Component Versions
Component Versions are created using a component-constructor.yaml
file, which is a description file that contains one or multiple components. The file describes the components and their artifacts - resources and sources, metadata in form of labels and references to other components.
Component Versions are locally stored in archives using the Common Transfer Format (CTF). A CTF archive may contain any number of component versions and is used to transfer components to and between component repositories.
Note that a CTF archive itself is also an OCM repository, so it can be used as source or target for component transfer operations using the OCM CLI.
The command ocm add componentversions
directly creates a component version from a component-constructor.yaml
file and stores it in a local CTF archive.
Create a Component Version
In this examle we will use the The ocm
CLI tool to create a very basic component version that contains a local resource and a resource that is accessed from a remote location. The local resource is the podinfo
Helm Chart and the referenced resource is a Docker image stored in an OCI registry.
We start by creating a test folder where we execute all required steps for this example and navigating into it:
Now we download the podinfo
Helm Chart that we want to use as local resource and extract it:
Create a file component-constructor.yaml
, which describes all elements of the component. You can use our public configuration schema to validate the configuration. The schema is available at https://ocm.software/schemas/configuration-schema.yaml
and can be used in your editor to validate the configuration (e.g., in Visual Studio Code).
Component versions need to have at least a name
, version
and provider
attribute. All other attributes are optional. Check out an example component descriptor or the OCM Specification to see all available attributes.
As mentioned before our example component will just contain a Helm Chart and a Docker image as resources:
A resource is described either by its access information to a remote repository or by locally provided resources.
For remote access, the field access
is used to describe the
access method.
The type field is used to specify the kind of access.
If the resource content is taken from local resources, the field input
is used to specify
the access to the local resources. Similarly to the access
attribute, the kind of the input source is described by the field type
.
Available access and input types are described here.
For more complex scenarios, the description files might use variable substitution (templating), see Best Practices.
Add Component Version to CTF archive
To store our component version locally and to make it transportable, we now add it to a CTF archive
using the following command. The option --create
is used to create a new CTF archive if it does not exist:
What happened?
The command creates the CTF archive (option --create
) and adds the listed components
with the described resources.
The transport archive’s contents can be found in artifact-index.json
. This file
contains the list of component version artifacts to be transported.
The content of the transport archive is stored as OCI artifacts. Notice that the repository names of Component Version artifacts (found at artifacts.respository
) are prefixed by component-descriptors/
.
The component version is described as an OCI manifest:
Notice that the output of the component version above contains the component descriptor as one of the layers
. It can be identified by its content type, which is application/vnd.ocm.software.component-descriptor.v2+yaml+tar
. In this case, the component descriptor can be displayed with the following command:
The other elements listed as layers
describe the blobs for the local resources stored along with the component version. The digests can be seen in the localReference
attributes of the component descriptor.