ocm hash componentversions [<options>] {<component-reference>}
componentversions, componentversion, cv, components, component, comps, comp, c
--actual use actual component descriptor
-c, --constraints constraints version constraint
-H, --hash string hash algorithm (default "SHA-256")
-h, --help help for componentversions
--latest restrict component versions to latest
--lookup stringArray repository name or spec for closure lookup fallback
-N, --normalization string normalization algorithm (default "jsonNormalisation/v3")
-O, --outfile string Output file for normalized component descriptor (default "-")
-o, --output string output mode (JSON, json, norm, wide, yaml)
-r, --recursive follow component reference nesting
--repo string repository name or spec
-s, --sort stringArray sort fields
-U, --update update digests in component version
-V, --verify verify digests found in component version
Hash lists normalized forms for all component versions specified, if only a component is specified all versions are listed.
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 option --actual
is given the component descriptor actually
found is used as it is, otherwise the required digests are calculated on-the-fly.
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.
The following normalization modes are supported with option --normalization
:
jsonNormalisation/v1
jsonNormalisation/v2
jsonNormalisation/v3
(default)
Note that the normalization algorithm is important to be equivalent when used for signing and verification, otherwise the verification can fail. Please always migrate to the latest normalization algorithm whenever possible. New signature algorithms can be used as soon as they are available in the component version after signing it.
The algorithms jsonNormalisation/v1 and jsonNormalisation/v2 are deprecated and should not be used anymore. Please switch to jsonNormalisation/v3 as soon as possible.
The following hash modes are supported with option --hash
:
NO-DIGEST
SHA-256
(default)SHA-512
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 types supported by the linked library can be used:
OCI Repository types (using standard component repository to OCI mapping):
CommonTransportFormat
: v1OCIRegistry
: v1oci
: v1ociRegistry
With the option --output
the output mode can be selected.
The following modes are supported:
(default)
JSON
json
norm
wide
yaml
$ ocm hash componentversion ghcr.io/open-component-model/ocm//ocm.software/ocmcli:0.17.0
$ ocm hash componentversion --repo OCIRegistry::ghcr.io/open-component-model/ocm ocm.software/ocmcli:0.17.0