Command: transfer componentversions

Usage 

ocm transfer componentversions [<options>] {<component-reference>} <target>

Options 

  -c, --constraints constraints   version constraint
  -V, --copy-resources            transfer referenced resources by-value
  -h, --help                      help for componentversions
      --latest                    restrict component versions to latest
      --lookup stringArray        repository name or spec for closure lookup fallback
  -f, --overwrite                 overwrite existing component versions
  -r, --recursive                 follow component reference nesting
      --repo string               repository name or spec
      --script string             config name of transfer handler script
  -s, --scriptFile string         filename of transfer handler script
  -t, --type string               archive format (directory, tar, tgz) (default "directory")
      --uploader <name>=<value>   repository uploader (<name>:<artifact type>:<media type>=<JSON target config) (default [])

Description

Transfer all component versions specified to the given target repository. If only a component (instead of a component version) is specified all versions are transferred.

If the option –constraints is given, and no version is specified for a component, only versions matching the given version constraints (semver https://github.com/Masterminds/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

<component>[:<version>]

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 –type option accepts a file format for the target archive to use. The following formats are supported:

  • directory
  • tar
  • tgz

The default format is directory.

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.

It the option –overwrite is given, component version in the target repository will be overwritten, if they already exist.

It the option –copy-resources is given, all referential resources will potentially be localized, mapped to component version local resources in the target repository. This behaviour can be further influenced by specifying a transfer script with the script option family.

If the –uploader option is specified, appropriate uploaders are configured for the transport target. It has the following format

<name>:<artifact type>:<media type>=<yaml target config>

The uploader name may be a path expression with the following possibilities:

  • ocm/ociRegistry: oci Registry upload for local OCI artifact blobs. The media type is optional. If given ist must be an OCI artifact media type.
  • plugin/[/<uploader name]: uploader provided by plugin.

It is possible to use a dedicated transfer script based on spiff. The option –scriptFile can be used to specify this script by a file name. With –script it can be taken from the CLI config using an entry of the following format:

type: scripts.ocm.config.ocm.software
scripts:
  <name>: 
    path: <filepath> 
    script:
      <scriptdata>

Only one of the fields path or script can be used.

If no script option is given and the cli config defines a script default this one is used.

Examples 


$ ocm transfer components -t tgz ghcr.io/mandelsoft/kubelink ctf.tgz
$ ocm transfer components -t tgz --repo OCIRegistry:ghcr.io mandelsoft/kubelink ctf.tgz

See Also

← componentversions
componentversions →