Command: download resources


ocm download resources [<options>]  <component> {<name> { <key>=<value> }}


  -c, --constraints constraints   version constraint
  -d, --download-handlers         use download handler if possible
  -x, --executable                download executable for local platform
  -h, --help                      help for resources
      --latest                    restrict component versions to latest
      --lookup stringArray        repository name or spec for closure lookup fallback
  -O, --outfile string            output file or directory
  -r, --recursive                 follow component reference nesting
      --repo string               repository name or spec
  -t, --type stringArray          resource type filter


Download resources of a component version. Resources are specified by identities. An identity consists of a name argument followed by optional <key>=<value> arguments.

The option -O is used to declare the output destination. For a single resource to download, this is the file written for the resource blob. If multiple resources are selected, a directory structure is written into the given directory for every involved component version as follows:

<component>/<version>{/<nested component>/<version>}

The resource files are named according to the resource identity in the component descriptor. If this identity is just the resource name, this name is ised. If additional identity attributes are required, this name is append by a comma separated list of <name>=<>value> pairs separated by a “-” from the plain name. This attribute list is alphabetical order:

<resource name>[-[<name>=<>value>]{,<name>=<>value>}]

If the option –constraints is given, and no version is specified for a component, only versions matching the given version constraints (semver are selected. With –latest only the latest matching versions will be selected.

If the –repo option is specified, the given names are interpreted relative to the specified repository using the syntax


If no –repo option is specified the given names are interpreted as located OCM component version references:

[<repo type>::]<host>[:<port>][/<base path>]//<component>[:<version>]

Additionally there is a variant to denote common transport archives and general repository specifications

[<repo type>::]<filepath>|<spec json>[//<component>[:<version>]]

The –repo option takes an OCM repository specification:

[<repo type>::]<configured name>|<file path>|<spec json>

For the Common Transport Format the types directory, tar or tgz is possible.

Using the JSON variant any repository type supported by the linked library can be used:

Dedicated OCM repository types:

  • ComponentArchive

OCI Repository types (using standard component repository to OCI mapping):

  • ArtifactSet
  • CommonTransportFormat
  • DockerDaemon
  • Empty
  • OCIRegistry
  • oci
  • ociRegistry

The library supports some downloads with semantics based on resource types. For example a helm chart can be download directly as helm chart archive, even if stored as OCI artifact. This is handled by download handler. Their usage can be enabled with the –download-handlers option. Otherwise the resource as returned by the access method is stored.

With the option –recursive the complete reference tree of a component reference is traversed.

If a component lookup for building a reference closure is required the –lookup option can be used to specify a fallback lookup repository. By default the component versions are searched in the repository holding the component version for which the closure is determined. For Component Archives this is never possible, because it only contains a single component version. Therefore, in this scenario this option must always be specified to be able to follow component references.

See Also

  • ocm download — Download oci artifacts, resources or complete components