From 99b6abe406796812fc5196a33d1de2cf6eea4767 Mon Sep 17 00:00:00 2001 From: morri-son Date: Tue, 17 Dec 2024 14:31:22 +0000 Subject: [PATCH] deploy: ea87db5eec5481fca9ae2bb373577011d22a0ced --- .../add/componentversions/index.html | 4 +- docs/cli-reference/add/index.html | 4 +- docs/cli-reference/add/references/index.html | 4 +- .../add/resource-configuration/index.html | 4 +- docs/cli-reference/add/resources/index.html | 4 +- .../cli-reference/add/routingslips/index.html | 4 +- .../add/source-configuration/index.html | 4 +- docs/cli-reference/add/sources/index.html | 4 +- .../check/componentversions/index.html | 4 +- docs/cli-reference/check/index.html | 4 +- docs/cli-reference/clean/cache/index.html | 4 +- docs/cli-reference/clean/index.html | 4 +- .../create/componentarchive/index.html | 4 +- docs/cli-reference/create/index.html | 4 +- .../create/rsakeypair/index.html | 4 +- .../create/transportarchive/index.html | 4 +- .../describe/artifacts/index.html | 4 +- docs/cli-reference/describe/cache/index.html | 4 +- docs/cli-reference/describe/index.html | 4 +- .../cli-reference/describe/package/index.html | 4 +- .../cli-reference/describe/plugins/index.html | 4 +- .../download/artifacts/index.html | 4 +- docs/cli-reference/download/cli/index.html | 4 +- .../download/componentversions/index.html | 4 +- docs/cli-reference/download/index.html | 4 +- .../download/resources/index.html | 4 +- docs/cli-reference/get/artifacts/index.html | 4 +- .../get/componentversions/index.html | 4 +- docs/cli-reference/get/config/index.html | 4 +- docs/cli-reference/get/credentials/index.html | 4 +- docs/cli-reference/get/index.html | 4 +- docs/cli-reference/get/plugins/index.html | 4 +- docs/cli-reference/get/pubsub/index.html | 4 +- docs/cli-reference/get/references/index.html | 4 +- docs/cli-reference/get/resources/index.html | 4 +- .../cli-reference/get/routingslips/index.html | 4 +- docs/cli-reference/get/sources/index.html | 4 +- docs/cli-reference/get/verified/index.html | 4 +- docs/cli-reference/help/attributes/index.html | 4 +- docs/cli-reference/help/configfile/index.html | 4 +- .../help/credential-handling/index.html | 4 +- docs/cli-reference/help/index.html | 4 +- docs/cli-reference/help/logging/index.html | 4 +- .../help/oci-references/index.html | 4 +- .../help/ocm-accessmethods/index.html | 4 +- .../help/ocm-downloadhandlers/index.html | 4 +- docs/cli-reference/help/ocm-labels/index.html | 4 +- docs/cli-reference/help/ocm-pubsub/index.html | 4 +- .../help/ocm-references/index.html | 4 +- .../help/ocm-uploadhandlers/index.html | 4 +- .../help/toi-bootstrapping/index.html | 4 +- docs/cli-reference/index.html | 4 +- .../list/componentversions/index.html | 4 +- docs/cli-reference/list/index.html | 4 +- docs/cli-reference/set/index.html | 4 +- docs/cli-reference/set/pubsub/index.html | 4 +- docs/cli-reference/show/index.html | 4 +- docs/cli-reference/show/tags/index.html | 4 +- docs/cli-reference/show/versions/index.html | 4 +- .../sign/componentversions/index.html | 4 +- docs/cli-reference/sign/hash/index.html | 4 +- docs/cli-reference/sign/index.html | 4 +- .../transfer/artifacts/index.html | 4 +- .../commontransportarchive/index.html | 4 +- .../transfer/componentarchive/index.html | 4 +- .../transfer/componentversions/index.html | 4 +- docs/cli-reference/transfer/index.html | 4 +- .../verify/componentversions/index.html | 4 +- docs/cli-reference/verify/index.html | 4 +- docs/component-descriptors/index.html | 4 +- docs/component-descriptors/index.xml | 2 +- docs/component-descriptors/sitemap.xml | 2 +- .../version-2/index.html | 100 +- .../version-3/index.html | 58 - .../contributing-guideline/index.html | 4 +- docs/contribution/index.html | 4 +- .../security-guideline/index.html | 4 +- docs/controller/architecture/index.html | 4 +- .../api-reference/index.html | 4 +- .../ocm-controller-api-v1/index.html | 4 +- .../replication-controller-api-v1/index.html | 4 +- .../controller-reference/index.html | 4 +- .../component-version/index.html | 4 +- .../ocm-controller/index.html | 4 +- .../component-subscription/index.html | 4 +- .../replication-controller/index.html | 4 +- docs/controller/index.html | 4 +- docs/controller/installation/index.html | 4 +- .../index.html | 4 +- docs/examples/index.html | 4 +- .../index.html | 4 +- .../create-a-component-version/index.html | 24 +- .../index.html | 32 +- .../getting-started-with-ocm/index.html | 4 +- .../getting-started-with-ocm/index.xml | 2 +- .../prerequisites/index.html | 4 +- .../sign-component-versions/index.html | 4 +- .../index.html | 4 +- docs/getting-started/index.html | 4 +- .../installing-the-ocm-cli/index.html | 4 +- docs/index.html | 4 +- docs/overview/about/index.html | 4 +- docs/overview/benefits-of-ocm/index.html | 4 +- docs/overview/important-terms/index.html | 4 +- docs/overview/index.html | 4 +- docs/overview/specification/index.html | 4 +- docs/overview/specification/schema-v2.html | 2 +- .../specification/schema-v3alpha1.html | 7120 ----------------- docs/roadmap/index.html | 4 +- docs/roadmap/our-roadmap/index.html | 4 +- docs/sitemap.xml | 2 +- docs/support/community/index.html | 4 +- docs/support/how-to-get-support/index.html | 4 +- docs/support/index.html | 4 +- docs/tutorials/best-practices/index.html | 4 +- .../index.html | 4 +- docs/tutorials/index.html | 4 +- .../input-and-access-types/index.html | 4 +- .../index.html | 4 +- .../index.html | 4 +- .../index.html | 4 +- docs/tutorials/ocm-and-gitops/index.html | 4 +- .../index.html | 4 +- index.xml | 7 +- search-index.json | 2 +- sitemap.xml | 2 +- 126 files changed, 335 insertions(+), 7472 deletions(-) delete mode 100644 docs/component-descriptors/version-3/index.html delete mode 100644 docs/overview/specification/schema-v3alpha1.html diff --git a/docs/cli-reference/add/componentversions/index.html b/docs/cli-reference/add/componentversions/index.html index 9d4ffb9c..d73b36ac 100644 --- a/docs/cli-reference/add/componentversions/index.html +++ b/docs/cli-reference/add/componentversions/index.html @@ -3,8 +3,8 @@ -
Docs
Open Component Model

componentversions

Usage

ocm add componentversions [<options>] [--version <version>] [<ctf archive>] {<component-constructor.yaml>}

Options

      --addenv                    access environment for templating
+
Docs

componentversions

Usage

ocm add componentversions [<options>] [--version <version>] [<ctf archive>] {<component-constructor.yaml>}

Options

      --addenv                    access environment for templating
   -C, --complete                  include all referenced component version
   -L, --copy-local-resources      transfer referenced local resources by-value
   -V, --copy-resources            transfer referenced resources by-value
diff --git a/docs/cli-reference/add/index.html b/docs/cli-reference/add/index.html
index 08ea0393..43fea8d3 100644
--- a/docs/cli-reference/add/index.html
+++ b/docs/cli-reference/add/index.html
@@ -3,5 +3,5 @@
 
-
Docs

add

Usage

ocm add [<options>] <sub command> ...

Options

  -h, --help   help for add

See Also

Sub Commands
\ No newline at end of file +
Docs

add

Usage

ocm add [<options>] <sub command> ...

Options

  -h, --help   help for add

See Also

Sub Commands
\ No newline at end of file diff --git a/docs/cli-reference/add/references/index.html b/docs/cli-reference/add/references/index.html index 153a3b85..9981e891 100644 --- a/docs/cli-reference/add/references/index.html +++ b/docs/cli-reference/add/references/index.html @@ -3,8 +3,8 @@ -
Docs

references

Usage

ocm add references [<options>] [<target>] {<referencefile> | <var>=<value>}

Options

      --addenv                 access environment for templating
+
Docs

references

Usage

ocm add references [<options>] [<target>] {<referencefile> | <var>=<value>}

Options

      --addenv                 access environment for templating
       --component string       component name
       --dry-run                evaluate and print reference specifications
       --extra <name>=<value>   reference extra identity (default [])
diff --git a/docs/cli-reference/add/resource-configuration/index.html b/docs/cli-reference/add/resource-configuration/index.html
index 73ed2856..5eeebe29 100644
--- a/docs/cli-reference/add/resource-configuration/index.html
+++ b/docs/cli-reference/add/resource-configuration/index.html
@@ -3,8 +3,8 @@
 
-
Docs

resource-configuration

Usage

ocm add resource-configuration [<options>] <target> {<configfile> | <var>=<value>}

Options

      --access YAML                         blob access specification (YAML)
+
Docs

resource-configuration

Usage

ocm add resource-configuration [<options>] <target> {<configfile> | <var>=<value>}

Options

      --access YAML                         blob access specification (YAML)
       --accessComponent string              component for access specification
       --accessHostname string               hostname used for access
       --accessRepository string             repository or registry URL
diff --git a/docs/cli-reference/add/resources/index.html b/docs/cli-reference/add/resources/index.html
index 411aa95c..292d4123 100644
--- a/docs/cli-reference/add/resources/index.html
+++ b/docs/cli-reference/add/resources/index.html
@@ -3,8 +3,8 @@
 
-
Docs

resources

Usage

ocm add resources [<options>] [<target>] {<resourcefile> | <var>=<value>}

Options

      --access YAML                         blob access specification (YAML)
+
Docs

resources

Usage

ocm add resources [<options>] [<target>] {<resourcefile> | <var>=<value>}

Options

      --access YAML                         blob access specification (YAML)
       --accessComponent string              component for access specification
       --accessHostname string               hostname used for access
       --accessRepository string             repository or registry URL
diff --git a/docs/cli-reference/add/routingslips/index.html b/docs/cli-reference/add/routingslips/index.html
index 46df5d18..b5125a8a 100644
--- a/docs/cli-reference/add/routingslips/index.html
+++ b/docs/cli-reference/add/routingslips/index.html
@@ -3,8 +3,8 @@
 
-
Docs

routingslips

Usage

ocm add routingslips [<options>] <component-version> <routing-slip> <type>

Options

  -S, --algorithm string     signature handler (default "RSASSA-PKCS1-V1_5")
+
Docs

routingslips

Usage

ocm add routingslips [<options>] <component-version> <routing-slip> <type>

Options

  -S, --algorithm string     signature handler (default "RSASSA-PKCS1-V1_5")
       --comment string       comment field value
       --digest string        parent digest to use
       --entry YAML           routing slip entry specification (YAML)
diff --git a/docs/cli-reference/add/source-configuration/index.html b/docs/cli-reference/add/source-configuration/index.html
index 4a894ddb..928b3d1e 100644
--- a/docs/cli-reference/add/source-configuration/index.html
+++ b/docs/cli-reference/add/source-configuration/index.html
@@ -3,8 +3,8 @@
 
-
Docs

source-configuration

Usage

ocm add source-configuration [<options>] <target> {<configfile> | <var>=<value>}

Options

      --access YAML                         blob access specification (YAML)
+
Docs

source-configuration

Usage

ocm add source-configuration [<options>] <target> {<configfile> | <var>=<value>}

Options

      --access YAML                         blob access specification (YAML)
       --accessComponent string              component for access specification
       --accessHostname string               hostname used for access
       --accessRepository string             repository or registry URL
diff --git a/docs/cli-reference/add/sources/index.html b/docs/cli-reference/add/sources/index.html
index f75d25b6..a0ada528 100644
--- a/docs/cli-reference/add/sources/index.html
+++ b/docs/cli-reference/add/sources/index.html
@@ -3,8 +3,8 @@
 
-
Docs

sources

Usage

ocm add sources [<options>] [<target>] {<resourcefile> | <var>=<value>}

Options

      --access YAML                         blob access specification (YAML)
+
Docs

sources

Usage

ocm add sources [<options>] [<target>] {<resourcefile> | <var>=<value>}

Options

      --access YAML                         blob access specification (YAML)
       --accessComponent string              component for access specification
       --accessHostname string               hostname used for access
       --accessRepository string             repository or registry URL
diff --git a/docs/cli-reference/check/componentversions/index.html b/docs/cli-reference/check/componentversions/index.html
index 15cc1fa2..dd2097da 100644
--- a/docs/cli-reference/check/componentversions/index.html
+++ b/docs/cli-reference/check/componentversions/index.html
@@ -3,8 +3,8 @@
 
-
Docs

componentversions

Usage

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

Options

      --fail-on-error      fail on validation error
+
Docs

componentversions

Usage

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

Options

      --fail-on-error      fail on validation error
   -h, --help               help for componentversions
   -R, --local-resources    check also for describing resources with local access method, only
   -S, --local-sources      check also for describing sources with local access method, only
diff --git a/docs/cli-reference/check/index.html b/docs/cli-reference/check/index.html
index 6ca943f1..449a7247 100644
--- a/docs/cli-reference/check/index.html
+++ b/docs/cli-reference/check/index.html
@@ -3,5 +3,5 @@
 
-
Docs

check

Usage

ocm check [<options>] <sub command> ...

Options

  -h, --help   help for check

See Also

Sub Commands
\ No newline at end of file +
Docs

check

Usage

ocm check [<options>] <sub command> ...

Options

  -h, --help   help for check

See Also

Sub Commands
\ No newline at end of file diff --git a/docs/cli-reference/clean/cache/index.html b/docs/cli-reference/clean/cache/index.html index 454a048c..db6b94be 100644 --- a/docs/cli-reference/clean/cache/index.html +++ b/docs/cli-reference/clean/cache/index.html @@ -3,8 +3,8 @@ -
Docs

cache

Usage

ocm clean cache [<options>]

Options

  -b, --before string   time since last usage
+
Docs

cache

Usage

ocm clean cache [<options>]

Options

  -b, --before string   time since last usage
   -s, --dry-run         show size to be removed
   -h, --help            help for cache

Description

Cleanup all blobs stored in oci blob cache (if given).

Examples


 $ ocm clean cache

See Also

Prev
attributes
Next
cache
\ No newline at end of file diff --git a/docs/cli-reference/clean/index.html b/docs/cli-reference/clean/index.html index 94b40a24..ce04518e 100644 --- a/docs/cli-reference/clean/index.html +++ b/docs/cli-reference/clean/index.html @@ -3,5 +3,5 @@ -
Docs

clean

Usage

ocm clean [<options>] <sub command> ...

Options

  -h, --help   help for clean

See Also

Sub Commands
\ No newline at end of file +
Docs

clean

Usage

ocm clean [<options>] <sub command> ...

Options

  -h, --help   help for clean

See Also

Sub Commands
\ No newline at end of file diff --git a/docs/cli-reference/create/componentarchive/index.html b/docs/cli-reference/create/componentarchive/index.html index 749d4b1a..98ea5182 100644 --- a/docs/cli-reference/create/componentarchive/index.html +++ b/docs/cli-reference/create/componentarchive/index.html @@ -3,8 +3,8 @@ -
Docs

componentarchive

Usage

ocm create componentarchive [<options>] <component> <version> --provider <provider-name> {--provider <label>=<value>} {<label>=<value>}

Options

  -F, --file string            target file/directory (default "component-archive")
+
Docs

componentarchive

Usage

ocm create componentarchive [<options>] <component> <version> --provider <provider-name> {--provider <label>=<value>} {<label>=<value>}

Options

  -F, --file string            target file/directory (default "component-archive")
   -f, --force                  remove existing content
   -h, --help                   help for componentarchive
   -p, --provider stringArray   provider attribute
diff --git a/docs/cli-reference/create/index.html b/docs/cli-reference/create/index.html
index ef19c516..473d17fd 100644
--- a/docs/cli-reference/create/index.html
+++ b/docs/cli-reference/create/index.html
@@ -3,5 +3,5 @@
 
-
Docs

create

Usage

ocm create [<options>] <sub command> ...

Options

  -h, --help   help for create

See Also

Sub Commands
\ No newline at end of file +
Docs

create

Usage

ocm create [<options>] <sub command> ...

Options

  -h, --help   help for create

See Also

Sub Commands
\ No newline at end of file diff --git a/docs/cli-reference/create/rsakeypair/index.html b/docs/cli-reference/create/rsakeypair/index.html index 2f8d9518..1e4a9fc1 100644 --- a/docs/cli-reference/create/rsakeypair/index.html +++ b/docs/cli-reference/create/rsakeypair/index.html @@ -3,8 +3,8 @@ -
Docs

rsakeypair

Usage

ocm create rsakeypair [<private key file> [<public key file>]] {<subject-attribute>=<value>}

Options

      --ca                     create certificate for a signing authority
+
Docs

rsakeypair

Usage

ocm create rsakeypair [<private key file> [<public key file>]] {<subject-attribute>=<value>}

Options

      --ca                     create certificate for a signing authority
       --ca-cert string         certificate authority to sign public key
       --ca-key string          private key for certificate authority
   -E, --encrypt                encrypt private key with new key
diff --git a/docs/cli-reference/create/transportarchive/index.html b/docs/cli-reference/create/transportarchive/index.html
index 9245f0d4..6973c9e8 100644
--- a/docs/cli-reference/create/transportarchive/index.html
+++ b/docs/cli-reference/create/transportarchive/index.html
@@ -3,8 +3,8 @@
 
-
Docs

transportarchive

Usage

ocm create transportarchive [<options>] <path>

Options

  -f, --force         remove existing content
+
Docs

transportarchive

Usage

ocm create transportarchive [<options>] <path>

Options

  -f, --force         remove existing content
   -h, --help          help for transportarchive
   -t, --type string   archive format (directory, tar, tgz) (default "directory")

Description

Create a new empty OCM/OCI transport archive. This might be either a directory prepared to host artifact content or a tar/tgz file.

See Also

  • ocm create — Create transport or component archive
Prev
toi-bootstrapping
Next
verified
\ No newline at end of file diff --git a/docs/cli-reference/describe/artifacts/index.html b/docs/cli-reference/describe/artifacts/index.html index 578db0dd..b9b67559 100644 --- a/docs/cli-reference/describe/artifacts/index.html +++ b/docs/cli-reference/describe/artifacts/index.html @@ -3,8 +3,8 @@ -
Docs

artifacts

Usage

ocm describe artifacts [<options>] {<artifact-reference>}

Options

  -h, --help            help for artifacts
+
Docs

artifacts

Usage

ocm describe artifacts [<options>] {<artifact-reference>}

Options

  -h, --help            help for artifacts
       --layerfiles      list layer files
   -o, --output string   output mode (JSON, json, yaml)
       --repo string     repository name or spec

Description

Describe lists all artifact versions specified, if only a repository is specified diff --git a/docs/cli-reference/describe/cache/index.html b/docs/cli-reference/describe/cache/index.html index 3e9ddf47..10efe489 100644 --- a/docs/cli-reference/describe/cache/index.html +++ b/docs/cli-reference/describe/cache/index.html @@ -3,6 +3,6 @@ -

Docs

cache

Usage

ocm describe cache [<options>]

Options

  -h, --help   help for cache

Description

Show details about the OCI blob cache (if given).

Examples


+
Docs

cache

Usage

ocm describe cache [<options>]

Options

  -h, --help   help for cache

Description

Show details about the OCI blob cache (if given).

Examples


 $ ocm cache info

See Also

  • ocm describe — Describe various elements by using appropriate sub commands.
Prev
cache
Next
cli
\ No newline at end of file diff --git a/docs/cli-reference/describe/index.html b/docs/cli-reference/describe/index.html index 4ba9aa34..3f0298b3 100644 --- a/docs/cli-reference/describe/index.html +++ b/docs/cli-reference/describe/index.html @@ -3,5 +3,5 @@ -
Docs

describe

Usage

ocm describe [<options>] <sub command> ...

Options

  -h, --help   help for describe

See Also

Sub Commands
\ No newline at end of file +
Docs

describe

Usage

ocm describe [<options>] <sub command> ...

Options

  -h, --help   help for describe

See Also

Sub Commands
\ No newline at end of file diff --git a/docs/cli-reference/describe/package/index.html b/docs/cli-reference/describe/package/index.html index 08c2ef49..19d42575 100644 --- a/docs/cli-reference/describe/package/index.html +++ b/docs/cli-reference/describe/package/index.html @@ -3,8 +3,8 @@ -
Docs

package

Usage

ocm describe package [<options>] {<component-reference>} {<resource id field>}

Options

  -h, --help                 help for package
+
Docs

package

Usage

ocm describe package [<options>] {<component-reference>} {<resource id field>}

Options

  -h, --help                 help for package
       --lookup stringArray   repository name or spec for closure lookup fallback
       --repo string          repository name or spec

Description

Describe a TOI package provided by a resource of an OCM component version.

The package resource must have the type toiPackage. This is a simple YAML file resource describing the bootstrapping of a dedicated kind diff --git a/docs/cli-reference/describe/plugins/index.html b/docs/cli-reference/describe/plugins/index.html index 59038758..fc062205 100644 --- a/docs/cli-reference/describe/plugins/index.html +++ b/docs/cli-reference/describe/plugins/index.html @@ -3,8 +3,8 @@ -

Docs

plugins

Usage

ocm describe plugins [<options>] {<plugin name>}

Options

  -h, --help   help for plugins

Description

Describes provides comprehensive information about the capabilities of +

Docs

plugins

Usage

ocm describe plugins [<options>] {<plugin name>}

Options

  -h, --help   help for plugins

Description

Describes provides comprehensive information about the capabilities of a plugin.

Examples


 $ ocm describe plugins
 $ ocm describe plugins demo

See Also

  • ocm describe — Describe various elements by using appropriate sub commands.
Prev
package
Next
plugins
\ No newline at end of file diff --git a/docs/cli-reference/download/artifacts/index.html b/docs/cli-reference/download/artifacts/index.html index 9f87b3ad..04d07314 100644 --- a/docs/cli-reference/download/artifacts/index.html +++ b/docs/cli-reference/download/artifacts/index.html @@ -3,8 +3,8 @@ -
Docs

artifacts

Usage

ocm download artifacts [<options>]  {<artifact>}

Options

      --dirtree          extract as effective filesystem content
+
Docs

artifacts

Usage

ocm download artifacts [<options>]  {<artifact>}

Options

      --dirtree          extract as effective filesystem content
   -h, --help             help for artifacts
       --layers ints      extract dedicated layers
   -O, --outfile string   output file or directory
diff --git a/docs/cli-reference/download/cli/index.html b/docs/cli-reference/download/cli/index.html
index d6fd5ade..91895414 100644
--- a/docs/cli-reference/download/cli/index.html
+++ b/docs/cli-reference/download/cli/index.html
@@ -3,8 +3,8 @@
 
-
Docs

cli

Usage

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

Options

  -c, --constraints constraints   version constraint
+
Docs

cli

Usage

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

Options

  -c, --constraints constraints   version constraint
   -h, --help                      help for cli
   -O, --outfile string            output file or directory
   -p, --path                      lookup executable in PATH
diff --git a/docs/cli-reference/download/componentversions/index.html b/docs/cli-reference/download/componentversions/index.html
index 4cee16f9..b8c3d44e 100644
--- a/docs/cli-reference/download/componentversions/index.html
+++ b/docs/cli-reference/download/componentversions/index.html
@@ -3,8 +3,8 @@
 
-
Docs

componentversions

Usage

ocm download componentversions [<options>] {<components>}

Options

  -h, --help             help for componentversions
+
Docs

componentversions

Usage

ocm download componentversions [<options>] {<components>}

Options

  -h, --help             help for componentversions
   -O, --outfile string   output file or directory
       --repo string      repository name or spec
   -t, --type string      archive format (directory, tar, tgz) (default "directory")

Description

Download component versions from an OCM repository. The result is stored in diff --git a/docs/cli-reference/download/index.html b/docs/cli-reference/download/index.html index 530f3a8a..4ea0cb03 100644 --- a/docs/cli-reference/download/index.html +++ b/docs/cli-reference/download/index.html @@ -3,5 +3,5 @@ -

Docs

download

Usage

ocm download [<options>] <sub command> ...

Options

  -h, --help   help for download

See Also

Sub Commands
\ No newline at end of file +
Docs

download

Usage

ocm download [<options>] <sub command> ...

Options

  -h, --help   help for download

See Also

Sub Commands
\ No newline at end of file diff --git a/docs/cli-reference/download/resources/index.html b/docs/cli-reference/download/resources/index.html index 9b99aaf2..76b6f3a7 100644 --- a/docs/cli-reference/download/resources/index.html +++ b/docs/cli-reference/download/resources/index.html @@ -3,8 +3,8 @@ -
Docs

resources

Usage

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

Options

      --check-verified              enable verification store
+
Docs

resources

Usage

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

Options

      --check-verified              enable verification store
   -c, --constraints constraints     version constraint
   -d, --download-handlers           use download handler if possible
       --downloader <name>=<value>   artifact downloader (<name>[:<artifact type>[:<media type>[:<priority>]]]=<JSON target config>) (default [])
diff --git a/docs/cli-reference/get/artifacts/index.html b/docs/cli-reference/get/artifacts/index.html
index 3d954a65..a7013e6b 100644
--- a/docs/cli-reference/get/artifacts/index.html
+++ b/docs/cli-reference/get/artifacts/index.html
@@ -3,8 +3,8 @@
 
-
Docs

artifacts

Usage

ocm get artifacts [<options>] {<artifact-reference>}

Options

  -a, --attached           show attached artifacts
+
Docs

artifacts

Usage

ocm get artifacts [<options>] {<artifact-reference>}

Options

  -a, --attached           show attached artifacts
   -h, --help               help for artifacts
   -o, --output string      output mode (JSON, json, tree, wide, yaml)
   -r, --recursive          follow index nesting
diff --git a/docs/cli-reference/get/componentversions/index.html b/docs/cli-reference/get/componentversions/index.html
index 27df4206..160f4ad5 100644
--- a/docs/cli-reference/get/componentversions/index.html
+++ b/docs/cli-reference/get/componentversions/index.html
@@ -3,8 +3,8 @@
 
-
Docs

componentversions

Usage

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

Options

  -c, --constraints constraints   version constraint
+
Docs

componentversions

Usage

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

Options

  -c, --constraints constraints   version constraint
   -h, --help                      help for componentversions
       --latest                    restrict component versions to latest
       --lookup stringArray        repository name or spec for closure lookup fallback
diff --git a/docs/cli-reference/get/config/index.html b/docs/cli-reference/get/config/index.html
index 3c0bba45..7bd088cf 100644
--- a/docs/cli-reference/get/config/index.html
+++ b/docs/cli-reference/get/config/index.html
@@ -3,8 +3,8 @@
 
-
Docs

config

Usage

ocm get config <options>

Options

  -h, --help             help for config
+
Docs

config

Usage

ocm get config <options>

Options

  -h, --help             help for config
   -O, --outfile string   output file or directory
   -o, --output string    output mode (JSON, json, yaml)

Description

Evaluate the command line arguments and all explicitly or implicitly used configuration files and provide diff --git a/docs/cli-reference/get/credentials/index.html b/docs/cli-reference/get/credentials/index.html index 09141643..99b6fc51 100644 --- a/docs/cli-reference/get/credentials/index.html +++ b/docs/cli-reference/get/credentials/index.html @@ -3,8 +3,8 @@ -

Docs

credentials

Usage

ocm get credentials {<consumer property>=<value>}

Options

  -h, --help             help for credentials
+
Docs

credentials

Usage

ocm get credentials {<consumer property>=<value>}

Options

  -h, --help             help for credentials
   -m, --matcher string   matcher type override
   -s, --sloppy           sloppy matching of consumer type

Description

Try to resolve a given consumer specification against the configured credential settings and show the found credential attributes.

Matchers exist for the following usage contexts or consumer types:

get

Usage

ocm get [<options>] <sub command> ...

Options

  -h, --help   help for get

See Also

Sub Commands
\ No newline at end of file +
Docs

get

Usage

ocm get [<options>] <sub command> ...

Options

  -h, --help   help for get

See Also

Sub Commands
\ No newline at end of file diff --git a/docs/cli-reference/get/plugins/index.html b/docs/cli-reference/get/plugins/index.html index 2371c246..35a1e59d 100644 --- a/docs/cli-reference/get/plugins/index.html +++ b/docs/cli-reference/get/plugins/index.html @@ -3,8 +3,8 @@ -
Docs

plugins

Usage

ocm get plugins [<options>] {<plugin name>}

Options

  -h, --help               help for plugins
+
Docs

plugins

Usage

ocm get plugins [<options>] {<plugin name>}

Options

  -h, --help               help for plugins
   -o, --output string      output mode (JSON, json, wide, yaml)
   -s, --sort stringArray   sort fields

Description

Get lists information for all plugins specified, if no plugin is specified all registered ones are listed.

With the option –output the output mode can be selected. diff --git a/docs/cli-reference/get/pubsub/index.html b/docs/cli-reference/get/pubsub/index.html index e3cdfcdf..3d3e0bf3 100644 --- a/docs/cli-reference/get/pubsub/index.html +++ b/docs/cli-reference/get/pubsub/index.html @@ -3,8 +3,8 @@ -

Docs

pubsub

Usage

ocm get pubsub {<ocm repository>}

Options

  -h, --help               help for pubsub
+
Docs

pubsub

Usage

ocm get pubsub {<ocm repository>}

Options

  -h, --help               help for pubsub
   -o, --output string      output mode (JSON, json, yaml)
   -s, --sort stringArray   sort fields

Description

A repository may be able to store a publish/subscribe specification to propagate the creation or update of component versions. diff --git a/docs/cli-reference/get/references/index.html b/docs/cli-reference/get/references/index.html index f3c28c5e..3978b2d0 100644 --- a/docs/cli-reference/get/references/index.html +++ b/docs/cli-reference/get/references/index.html @@ -3,8 +3,8 @@ -

Docs

references

Usage

ocm get references [<options>]  <component> {<name> { <key>=<value> }}

Options

  -c, --constraints constraints   version constraint
+
Docs

references

Usage

ocm get references [<options>]  <component> {<name> { <key>=<value> }}

Options

  -c, --constraints constraints   version constraint
   -h, --help                      help for references
       --latest                    restrict component versions to latest
       --lookup stringArray        repository name or spec for closure lookup fallback
diff --git a/docs/cli-reference/get/resources/index.html b/docs/cli-reference/get/resources/index.html
index bbe9bd10..27b044e3 100644
--- a/docs/cli-reference/get/resources/index.html
+++ b/docs/cli-reference/get/resources/index.html
@@ -3,8 +3,8 @@
 
-
Docs

resources

Usage

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

Options

  -c, --constraints constraints   version constraint
+
Docs

resources

Usage

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

Options

  -c, --constraints constraints   version constraint
   -h, --help                      help for resources
       --latest                    restrict component versions to latest
       --lookup stringArray        repository name or spec for closure lookup fallback
diff --git a/docs/cli-reference/get/routingslips/index.html b/docs/cli-reference/get/routingslips/index.html
index bc111dcd..4406d6d5 100644
--- a/docs/cli-reference/get/routingslips/index.html
+++ b/docs/cli-reference/get/routingslips/index.html
@@ -3,8 +3,8 @@
 
-
Docs

routingslips

Usage

ocm get routingslips [<options>]  <component> {<name>}

Options

      --all-columns               show all table columns
+
Docs

routingslips

Usage

ocm get routingslips [<options>]  <component> {<name>}

Options

      --all-columns               show all table columns
   -c, --constraints constraints   version constraint
       --fail-on-error             fail on validation error
   -h, --help                      help for routingslips
diff --git a/docs/cli-reference/get/sources/index.html b/docs/cli-reference/get/sources/index.html
index 4c15998b..fbb32fd8 100644
--- a/docs/cli-reference/get/sources/index.html
+++ b/docs/cli-reference/get/sources/index.html
@@ -3,8 +3,8 @@
 
-
Docs

sources

Usage

ocm get sources [<options>]  <component> {<name> { <key>=<value> }}

Options

  -c, --constraints constraints   version constraint
+
Docs

sources

Usage

ocm get sources [<options>]  <component> {<name> { <key>=<value> }}

Options

  -c, --constraints constraints   version constraint
   -h, --help                      help for sources
       --latest                    restrict component versions to latest
       --lookup stringArray        repository name or spec for closure lookup fallback
diff --git a/docs/cli-reference/get/verified/index.html b/docs/cli-reference/get/verified/index.html
index 54bad011..7acf91d3 100644
--- a/docs/cli-reference/get/verified/index.html
+++ b/docs/cli-reference/get/verified/index.html
@@ -3,8 +3,8 @@
 
-
Docs

verified

Usage

ocm get verified [<options>] {<component / version}

Options

  -h, --help               help for verified
+
Docs

verified

Usage

ocm get verified [<options>] {<component / version}

Options

  -h, --help               help for verified
   -o, --output string      output mode (JSON, json, wide, yaml)
   -s, --sort stringArray   sort fields
       --verified string    verified file (default "~/.ocm/verified")

Description

Get lists remembered verified component versions.

With the option –output the output mode can be selected. diff --git a/docs/cli-reference/help/attributes/index.html b/docs/cli-reference/help/attributes/index.html index 9f15c28f..9218593e 100644 --- a/docs/cli-reference/help/attributes/index.html +++ b/docs/cli-reference/help/attributes/index.html @@ -3,8 +3,8 @@ -

Docs

attributes

Description

The OCM library supports a set of attributes, which can be used to influence +

Docs

attributes

Description

The OCM library supports a set of attributes, which can be used to influence the behaviour of various functions. The CLI also supports setting of those attributes using the config file (see ocm configfile) or by command line options of the main command (see ocm).

The following options are available in the currently used version of the diff --git a/docs/cli-reference/help/configfile/index.html b/docs/cli-reference/help/configfile/index.html index bbee3e0f..0b68e2fc 100644 --- a/docs/cli-reference/help/configfile/index.html +++ b/docs/cli-reference/help/configfile/index.html @@ -3,8 +3,8 @@ -

Docs

configfile

Description

The command line client supports configuring by a given configuration file. +

Docs

configfile

Description

The command line client supports configuring by a given configuration file. If existent, by default, the file $HOME/.ocmconfig will be read. Using the option –config an alternative file can be specified.

The file format is yaml. It uses the same type mechanism used for all kinds of typed specification in the ocm area. The file must have the type of diff --git a/docs/cli-reference/help/credential-handling/index.html b/docs/cli-reference/help/credential-handling/index.html index 1a9086c9..d905b8e6 100644 --- a/docs/cli-reference/help/credential-handling/index.html +++ b/docs/cli-reference/help/credential-handling/index.html @@ -3,8 +3,8 @@ -

Docs

credential-handling

Description

In contrast to libraries intended for a dedicated technical environment, +

Docs

credential-handling

Description

In contrast to libraries intended for a dedicated technical environment, for example the handling of OCI images in OCI registries, the OCM ecosystem cannot provide a specialized credential management for a dedicated environment.

Because of its extensibility working with component versions could diff --git a/docs/cli-reference/help/index.html b/docs/cli-reference/help/index.html index 4d47daa3..bc2a5e35 100644 --- a/docs/cli-reference/help/index.html +++ b/docs/cli-reference/help/index.html @@ -3,5 +3,5 @@ -

Docs

help

Additional Topics

\ No newline at end of file +
Docs

help

Additional Topics

\ No newline at end of file diff --git a/docs/cli-reference/help/logging/index.html b/docs/cli-reference/help/logging/index.html index 12fc6276..6a2328cb 100644 --- a/docs/cli-reference/help/logging/index.html +++ b/docs/cli-reference/help/logging/index.html @@ -3,8 +3,8 @@ -
Docs

logging

Description

Logging can be configured as part of the ocm config file (ocm configfile) +

Docs

logging

Description

Logging can be configured as part of the ocm config file (ocm configfile) or by command line options of the ocm command. Details about the YAML structure of a logging settings can be found on https://github.com/mandelsoft/logging.

The command line also supports some quick-config options for enabling log levels for dedicated tags and realms or realm prefixes (logging keys).

The following tags are used by the command line tool:

  • blobhandler: execution of blob handler used to upload resource blobs to an ocm repository.
  • cd-diff: component descriptor modification

The following realms are used by the command line tool:

  • ocm: general realm used for the ocm go library.
  • ocm/accessmethod/ociartifact: access method ociArtifact
  • ocm/accessmethod/wget: access method for wget
  • ocm/blobaccess/wget: blob access for wget
  • ocm/compdesc: component descriptor handling
  • ocm/config: configuration management
  • ocm/context: context lifecycle
  • ocm/credentials: Credentials
  • ocm/credentials/dockerconfig: docker config handling as credential repository
  • ocm/credentials/vault: HashiCorp Vault Access
  • ocm/downloader: Downloaders
  • ocm/maven: Maven repository
  • ocm/npm: NPM registry
  • ocm/oci/docker: Docker repository handling
  • ocm/oci/mapping: OCM to OCI Registry Mapping
  • ocm/oci/ocireg: OCI repository handling
  • ocm/plugins: OCM plugin handling
  • ocm/processing: output processing chains
  • ocm/refcnt: reference counting
  • ocm/toi: TOI logging
  • ocm/transfer: OCM transfer handling
  • ocm/valuemerge: value marge handling

Examples


diff --git a/docs/cli-reference/help/oci-references/index.html b/docs/cli-reference/help/oci-references/index.html
index 4c73a9c4..7e4ce1e9 100644
--- a/docs/cli-reference/help/oci-references/index.html
+++ b/docs/cli-reference/help/oci-references/index.html
@@ -3,8 +3,8 @@
 
-
Docs

oci-references

Description

The command line client supports a special notation scheme for specifying +

Docs

oci-references

Description

The command line client supports a special notation scheme for specifying references to instances of oci like registries. This allows for specifying references to any registry supported by the OCM toolset that can host OCI artifacts. As a subset the regular OCI artifact notation used for docker diff --git a/docs/cli-reference/help/ocm-accessmethods/index.html b/docs/cli-reference/help/ocm-accessmethods/index.html index ef06511d..2abc56f7 100644 --- a/docs/cli-reference/help/ocm-accessmethods/index.html +++ b/docs/cli-reference/help/ocm-accessmethods/index.html @@ -3,8 +3,8 @@ -

Docs

ocm-accessmethods

Description

Access methods are used to handle the access to the content of artifacts +

Docs

ocm-accessmethods

Description

Access methods are used to handle the access to the content of artifacts described in a component version. Therefore, an artifact entry contains an access specification describing the access attributes for the dedicated artifact.

The following list describes the supported access methods, their versions diff --git a/docs/cli-reference/help/ocm-downloadhandlers/index.html b/docs/cli-reference/help/ocm-downloadhandlers/index.html index c25344ba..a4aff6c0 100644 --- a/docs/cli-reference/help/ocm-downloadhandlers/index.html +++ b/docs/cli-reference/help/ocm-downloadhandlers/index.html @@ -3,8 +3,8 @@ -

Docs

ocm-downloadhandlers

Description

A download handler can be used to process resources to be downloaded from +

Docs

ocm-downloadhandlers

Description

A download handler can be used to process resources to be downloaded from on OCM repository. By default, the blobs provided from the access method (see ocm ocm-accessmethods) are used to store the resource content in the local filesystem. Download handlers can be used to tweak this process. diff --git a/docs/cli-reference/help/ocm-labels/index.html b/docs/cli-reference/help/ocm-labels/index.html index 63bea1ce..84371a38 100644 --- a/docs/cli-reference/help/ocm-labels/index.html +++ b/docs/cli-reference/help/ocm-labels/index.html @@ -5,8 +5,8 @@ -

Docs

ocm-labels

Description

Labels are a set of arbitrary properties, which can be attached to elements +

Docs

ocm-labels

Description

Labels are a set of arbitrary properties, which can be attached to elements of a component version:

  • a component version itself
  • the provider of a component version
  • resources
  • sources
  • component references

The dedicated elements support this by providing a field labels, which is a list of label definitions. Every label definition has several fields:

ocm-pubsub

Description

An OCM repository can be configured to propagate change events via a +

Docs

ocm-pubsub

Description

An OCM repository can be configured to propagate change events via a publish/subscribe system, if there is a persistence provider for the dedicated repository type. If available any known publish/subscribe system can be configured with ocm set pubsub and shown with diff --git a/docs/cli-reference/help/ocm-references/index.html b/docs/cli-reference/help/ocm-references/index.html index e87d442f..886d429f 100644 --- a/docs/cli-reference/help/ocm-references/index.html +++ b/docs/cli-reference/help/ocm-references/index.html @@ -3,8 +3,8 @@ -

Docs

ocm-references

Description

The command line client supports a special notation scheme for specifying +

Docs

ocm-references

Description

The command line client supports a special notation scheme for specifying references to OCM components and repositories. This allows for specifying references to any registry supported by the OCM toolset that can host OCM components:

[+][<type>::][./]<file path>//<component id>[:<version>]

or

[+][<type>::][<json repo spec>//]<component id>[:<version>]

or

[+][<type>::][<scheme>://]<domain>[:<port>][/<repository prefix>]//<component id>[:<version]

or

[+][<type>::][<scheme>://]<host>[:<port>][/<repository prefix>]//<component id>[:<version]

Besides dedicated components it is also possible to denote repositories diff --git a/docs/cli-reference/help/ocm-uploadhandlers/index.html b/docs/cli-reference/help/ocm-uploadhandlers/index.html index 0065203e..502e5d13 100644 --- a/docs/cli-reference/help/ocm-uploadhandlers/index.html +++ b/docs/cli-reference/help/ocm-uploadhandlers/index.html @@ -3,8 +3,8 @@ -

Docs

ocm-uploadhandlers

Description

An upload handler is used to process resources using the access method +

Docs

ocm-uploadhandlers

Description

An upload handler is used to process resources using the access method localBlob transferred into an OCM repository. They may decide to store the content in some other storage repository. This may be an additional storage location or it diff --git a/docs/cli-reference/help/toi-bootstrapping/index.html b/docs/cli-reference/help/toi-bootstrapping/index.html index 5388022d..a38b3ec1 100644 --- a/docs/cli-reference/help/toi-bootstrapping/index.html +++ b/docs/cli-reference/help/toi-bootstrapping/index.html @@ -3,8 +3,8 @@ -

Docs

toi-bootstrapping

Description

Tiny OCM Installer (TOI) is a small toolset on top of the Open Component Model. +

Docs

toi-bootstrapping

Description

Tiny OCM Installer (TOI) is a small toolset on top of the Open Component Model. It provides a possibility to run images taken from a component version with user configuration and feed them with the content of this component version. It is some basic mechanism, which can be used to execute simple installation diff --git a/docs/cli-reference/index.html b/docs/cli-reference/index.html index 7ef7c497..85357be2 100644 --- a/docs/cli-reference/index.html +++ b/docs/cli-reference/index.html @@ -3,8 +3,8 @@ -

Docs

cli-reference

Options

  -X, --attribute stringArray     attribute setting
+
Docs

cli-reference

Options

  -X, --attribute stringArray     attribute setting
       --ca-cert stringArray       additional root certificate authorities (for signing certificates)
       --config stringArray        configuration file
       --config-set strings        apply configuration set
diff --git a/docs/cli-reference/list/componentversions/index.html b/docs/cli-reference/list/componentversions/index.html
index 03071a2b..791b00e4 100644
--- a/docs/cli-reference/list/componentversions/index.html
+++ b/docs/cli-reference/list/componentversions/index.html
@@ -3,8 +3,8 @@
 
-
Docs

componentversions

Usage

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

Options

  -c, --constraints constraints   version constraint
+
Docs

componentversions

Usage

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

Options

  -c, --constraints constraints   version constraint
   -h, --help                      help for componentversions
       --latest                    restrict component versions to latest
       --lookup stringArray        repository name or spec for closure lookup fallback
diff --git a/docs/cli-reference/list/index.html b/docs/cli-reference/list/index.html
index 4b71cfd1..dec80254 100644
--- a/docs/cli-reference/list/index.html
+++ b/docs/cli-reference/list/index.html
@@ -3,5 +3,5 @@
 
-
Docs

list

Usage

ocm list [<options>] <sub command> ...

Options

  -h, --help   help for list

See Also

Sub Commands
\ No newline at end of file +
Docs

list

Usage

ocm list [<options>] <sub command> ...

Options

  -h, --help   help for list

See Also

Sub Commands
\ No newline at end of file diff --git a/docs/cli-reference/set/index.html b/docs/cli-reference/set/index.html index 8189edf0..57f3b6f9 100644 --- a/docs/cli-reference/set/index.html +++ b/docs/cli-reference/set/index.html @@ -3,5 +3,5 @@ -
Docs

set

Usage

ocm set [<options>] <sub command> ...

Options

  -h, --help   help for set

See Also

Sub Commands
\ No newline at end of file +
Docs

set

Usage

ocm set [<options>] <sub command> ...

Options

  -h, --help   help for set

See Also

Sub Commands
\ No newline at end of file diff --git a/docs/cli-reference/set/pubsub/index.html b/docs/cli-reference/set/pubsub/index.html index ab9bd22c..78f11d85 100644 --- a/docs/cli-reference/set/pubsub/index.html +++ b/docs/cli-reference/set/pubsub/index.html @@ -3,8 +3,8 @@ -
Docs

pubsub

Usage

ocm set pubsub {<ocm repository>} [<pub/sub specification>]

Options

  -d, --delete   delete pub/sub configuration
+
Docs

pubsub

Usage

ocm set pubsub {<ocm repository>} [<pub/sub specification>]

Options

  -d, --delete   delete pub/sub configuration
   -h, --help     help for pubsub

Description

A repository may be able to store a publish/subscribe specification to propagate the creation or update of component versions. If such an implementation is available this command can be used diff --git a/docs/cli-reference/show/index.html b/docs/cli-reference/show/index.html index 15e07375..3c448913 100644 --- a/docs/cli-reference/show/index.html +++ b/docs/cli-reference/show/index.html @@ -3,5 +3,5 @@ -

Docs

show

Usage

ocm show [<options>] <sub command> ...

Options

  -h, --help   help for show

See Also

Sub Commands
\ No newline at end of file +
Docs

show

Usage

ocm show [<options>] <sub command> ...

Options

  -h, --help   help for show

See Also

Sub Commands
\ No newline at end of file diff --git a/docs/cli-reference/show/tags/index.html b/docs/cli-reference/show/tags/index.html index 437d6c6a..9914d7eb 100644 --- a/docs/cli-reference/show/tags/index.html +++ b/docs/cli-reference/show/tags/index.html @@ -3,8 +3,8 @@ -
Docs

tags

Usage

ocm show tags [<options>] <component> {<version pattern>}

Options

  -h, --help          help for tags
+
Docs

tags

Usage

ocm show tags [<options>] <component> {<version pattern>}

Options

  -h, --help          help for tags
   -l, --latest        show only latest tags
       --repo string   repository name or spec
   -o, --semantic      show semantic tags
diff --git a/docs/cli-reference/show/versions/index.html b/docs/cli-reference/show/versions/index.html
index 443a5dea..8f23a0ff 100644
--- a/docs/cli-reference/show/versions/index.html
+++ b/docs/cli-reference/show/versions/index.html
@@ -3,8 +3,8 @@
 
-
Docs

versions

Usage

ocm show versions [<options>] <component> {<version pattern>}

Options

  -h, --help          help for versions
+
Docs

versions

Usage

ocm show versions [<options>] <component> {<version pattern>}

Options

  -h, --help          help for versions
   -l, --latest        show only latest version
       --repo string   repository name or spec
   -s, --semantic      show semantic version

Description

Match versions of a component against some patterns.

If the –repo option is specified, the given names are interpreted diff --git a/docs/cli-reference/sign/componentversions/index.html b/docs/cli-reference/sign/componentversions/index.html index 62e93f15..4467bede 100644 --- a/docs/cli-reference/sign/componentversions/index.html +++ b/docs/cli-reference/sign/componentversions/index.html @@ -3,8 +3,8 @@ -

Docs

componentversions

Usage

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

Options

      --                          enable verification store
+
Docs

componentversions

Usage

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

Options

      --                          enable verification store
   -S, --algorithm string          signature handler (default "RSASSA-PKCS1-V1_5")
       --ca-cert stringArray       additional root certificate authorities (for signing certificates)
   -c, --constraints constraints   version constraint
diff --git a/docs/cli-reference/sign/hash/index.html b/docs/cli-reference/sign/hash/index.html
index 739f7ae5..d7eb21d6 100644
--- a/docs/cli-reference/sign/hash/index.html
+++ b/docs/cli-reference/sign/hash/index.html
@@ -3,8 +3,8 @@
 
-
Docs

hash

Usage

ocm sign hash <private key file> <hash> [<issuer>]

Options

  -S, --algorithm string      signature algorithm (default "RSASSA-PKCS1-V1_5")
+
Docs

hash

Usage

ocm sign hash <private key file> <hash> [<issuer>]

Options

  -S, --algorithm string      signature algorithm (default "RSASSA-PKCS1-V1_5")
       --ca-cert stringArray   additional root certificate authorities (for signing certificates)
   -h, --help                  help for hash
       --publicKey string      public key certificate file
diff --git a/docs/cli-reference/sign/index.html b/docs/cli-reference/sign/index.html
index bf3f75a2..942075af 100644
--- a/docs/cli-reference/sign/index.html
+++ b/docs/cli-reference/sign/index.html
@@ -3,5 +3,5 @@
 
-
Docs

sign

Usage

ocm sign [<options>] <sub command> ...

Options

  -h, --help   help for sign

See Also

Sub Commands
\ No newline at end of file +
Docs

sign

Usage

ocm sign [<options>] <sub command> ...

Options

  -h, --help   help for sign

See Also

Sub Commands
\ No newline at end of file diff --git a/docs/cli-reference/transfer/artifacts/index.html b/docs/cli-reference/transfer/artifacts/index.html index fa013872..d7ca55fb 100644 --- a/docs/cli-reference/transfer/artifacts/index.html +++ b/docs/cli-reference/transfer/artifacts/index.html @@ -3,8 +3,8 @@ -
Docs

artifacts

Usage

ocm transfer artifacts [<options>] {<artifact-reference>} <target>

Options

  -h, --help          help for artifacts
+
Docs

artifacts

Usage

ocm transfer artifacts [<options>] {<artifact-reference>} <target>

Options

  -h, --help          help for artifacts
       --repo string   repository name or spec
   -R, --repo-name     transfer repository name

Description

Transfer OCI artifacts from one registry to another one. Several transfer scenarios are supported:

  • copy a set of artifacts (for the same repository) into another registry
  • copy a set of artifacts (for the same repository) into another repository
  • copy artifacts from multiple repositories into another registry
  • copy artifacts from multiple repositories into another registry with a given repository prefix (option -R)

By default, the target is seen as a single repository if a repository is specified. diff --git a/docs/cli-reference/transfer/commontransportarchive/index.html b/docs/cli-reference/transfer/commontransportarchive/index.html index d6665090..47f99abb 100644 --- a/docs/cli-reference/transfer/commontransportarchive/index.html +++ b/docs/cli-reference/transfer/commontransportarchive/index.html @@ -3,8 +3,8 @@ -

Docs

commontransportarchive

Usage

ocm transfer commontransportarchive [<options>] <ctf> <target>

Options

  -L, --copy-local-resources        transfer referenced local resources by-value
+
Docs

commontransportarchive

Usage

ocm transfer commontransportarchive [<options>] <ctf> <target>

Options

  -L, --copy-local-resources        transfer referenced local resources by-value
   -V, --copy-resources              transfer referenced resources by-value
       --copy-sources                transfer referenced sources by-value
       --enforce                     enforce transport as if target version were not present
diff --git a/docs/cli-reference/transfer/componentarchive/index.html b/docs/cli-reference/transfer/componentarchive/index.html
index a687c44d..ed306603 100644
--- a/docs/cli-reference/transfer/componentarchive/index.html
+++ b/docs/cli-reference/transfer/componentarchive/index.html
@@ -3,8 +3,8 @@
 
-
Docs

componentarchive

Usage

ocm transfer componentarchive [<options>]  <source> <target>

Options

  -L, --copy-local-resources   transfer referenced local resources by-value
+
Docs

componentarchive

Usage

ocm transfer componentarchive [<options>]  <source> <target>

Options

  -L, --copy-local-resources   transfer referenced local resources by-value
   -V, --copy-resources         transfer referenced resources by-value
       --copy-sources           transfer referenced sources by-value
       --enforce                enforce transport as if target version were not present
diff --git a/docs/cli-reference/transfer/componentversions/index.html b/docs/cli-reference/transfer/componentversions/index.html
index db256158..548e54b0 100644
--- a/docs/cli-reference/transfer/componentversions/index.html
+++ b/docs/cli-reference/transfer/componentversions/index.html
@@ -3,8 +3,8 @@
 
-
Docs

componentversions

Usage

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

Options

  -B, --bom-file string             file name to write the component version BOM
+
Docs

componentversions

Usage

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

Options

  -B, --bom-file string             file name to write the component version BOM
   -c, --constraints constraints     version constraint
   -L, --copy-local-resources        transfer referenced local resources by-value
   -V, --copy-resources              transfer referenced resources by-value
diff --git a/docs/cli-reference/transfer/index.html b/docs/cli-reference/transfer/index.html
index b34dc7bc..7d786474 100644
--- a/docs/cli-reference/transfer/index.html
+++ b/docs/cli-reference/transfer/index.html
@@ -3,5 +3,5 @@
 
-
Docs

transfer

Usage

ocm transfer [<options>] <sub command> ...

Options

  -h, --help   help for transfer

See Also

Sub Commands
\ No newline at end of file +
Docs

transfer

Usage

ocm transfer [<options>] <sub command> ...

Options

  -h, --help   help for transfer

See Also

Sub Commands
\ No newline at end of file diff --git a/docs/cli-reference/verify/componentversions/index.html b/docs/cli-reference/verify/componentversions/index.html index 9d59b672..45e183df 100644 --- a/docs/cli-reference/verify/componentversions/index.html +++ b/docs/cli-reference/verify/componentversions/index.html @@ -3,8 +3,8 @@ -
Docs

componentversions

Usage

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

Options

      --                          enable verification store
+
Docs

componentversions

Usage

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

Options

      --                          enable verification store
       --ca-cert stringArray       additional root certificate authorities (for signing certificates)
   -c, --constraints constraints   version constraint
   -h, --help                      help for componentversions
diff --git a/docs/cli-reference/verify/index.html b/docs/cli-reference/verify/index.html
index 7a3305b9..a5373429 100644
--- a/docs/cli-reference/verify/index.html
+++ b/docs/cli-reference/verify/index.html
@@ -3,5 +3,5 @@
 
-
Docs

verify

Usage

ocm verify [<options>] <sub command> ...

Options

  -h, --help   help for verify

See Also

Sub Commands
\ No newline at end of file +
Docs

verify

Usage

ocm verify [<options>] <sub command> ...

Options

  -h, --help   help for verify

See Also

Sub Commands
\ No newline at end of file diff --git a/docs/component-descriptors/index.html b/docs/component-descriptors/index.html index 079a8bdf..3ee76651 100644 --- a/docs/component-descriptors/index.html +++ b/docs/component-descriptors/index.html @@ -3,5 +3,5 @@ -
Docs

Component Descriptors

\ No newline at end of file +
Docs

Component Descriptors

\ No newline at end of file diff --git a/docs/component-descriptors/index.xml b/docs/component-descriptors/index.xml index 4acbe64b..6b94ab48 100644 --- a/docs/component-descriptors/index.xml +++ b/docs/component-descriptors/index.xml @@ -1 +1 @@ -Component Descriptors on Open Component Modelhttps://ocm.software/docs/component-descriptors/Recent content in Component Descriptors on Open Component ModelHugoen© Copyright 2024, SAP SE and Open Component Model ContributorsTue, 17 Jan 2023 10:22:23 +0000Version 2https://ocm.software/docs/component-descriptors/version-2/Tue, 17 Jan 2023 10:22:20 +0000https://ocm.software/docs/component-descriptors/version-2/<p>The following is an example of a public-key-based signed component descriptor containing a resource, source and one component reference. It uses the <code>v2</code> schema (which is the default). There are no differences in the semantics between version v2 and v3. <code>meta.schemaVersion</code> is used as kind of moniker for different serializing/deserializing formats (<code>v3</code> has the format of Kubernetes resources).</p>Version 3https://ocm.software/docs/component-descriptors/version-3/Tue, 17 Jan 2023 10:22:23 +0000https://ocm.software/docs/component-descriptors/version-3/<p>The following is an example of a public-key-based signed component descriptor containing a resource, source and one component reference. It uses the <code>v3alpha1</code> schema. There are no differences in the semantics between version v2 and v3. <code>apiVersion</code> is used as kind of moniker for different serializing/deserializing formats (<code>v3</code> has the format of Kubernetes resources).</p> \ No newline at end of file +Component Descriptors on Open Component Modelhttps://ocm.software/docs/component-descriptors/Recent content in Component Descriptors on Open Component ModelHugoen© Copyright 2024, SAP SE and Open Component Model ContributorsTue, 17 Jan 2023 10:22:20 +0000Version 2https://ocm.software/docs/component-descriptors/version-2/Tue, 17 Jan 2023 10:22:20 +0000https://ocm.software/docs/component-descriptors/version-2/<p>The following is an example of a public-key-based signed component descriptor containing a resource, source and one component reference. It uses the default <code>v2</code> schema.</p> \ No newline at end of file diff --git a/docs/component-descriptors/sitemap.xml b/docs/component-descriptors/sitemap.xml index 82e1f2e0..b5265e84 100644 --- a/docs/component-descriptors/sitemap.xml +++ b/docs/component-descriptors/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/component-descriptors/version-2/2023-01-17T10:22:20+00:00monthly0.5https://ocm.software/docs/component-descriptors/version-3/2023-01-17T10:22:23+00:00monthly0.5 \ No newline at end of file +https://ocm.software/docs/component-descriptors/version-2/2023-01-17T10:22:20+00:00monthly0.5 \ No newline at end of file diff --git a/docs/component-descriptors/version-2/index.html b/docs/component-descriptors/version-2/index.html index 1808acf4..ab533f72 100644 --- a/docs/component-descriptors/version-2/index.html +++ b/docs/component-descriptors/version-2/index.html @@ -1,56 +1,94 @@ Version 2 | Open Component Model -
+
-
Docs

Version 2

The following is an example of a public-key-based signed component descriptor containing a resource, source and one component reference. It uses the v2 schema (which is the default). There are no differences in the semantics between version v2 and v3. meta.schemaVersion is used as kind of moniker for different serializing/deserializing formats (v3 has the format of Kubernetes resources).

This component is publicly available and can be inspected using the following command:

ocm componentversion get --repo ghcr.io/phoban01/ocm github.com/weaveworks/weave-gitops -oyaml
meta:
-  schemaVersion: v2 # component schema version
+
Docs

Version 2

The following is an example of a public-key-based signed component descriptor containing a resource, source and one component reference. It uses the default v2 schema.

The component is publicly available in the GitHub package repository and can be inspected using the following command:

ocm componentversion get --repo ghcr.io/phoban01/ocm github.com/weaveworks/weave-gitops -oyaml
meta:
+  # component schema version
+  schemaVersion: v2 
 component:
-  name: github.com/weaveworks/weave-gitops # name of the component
-  version: v1.0.0 # version of the component
-  provider: weaveworks # component provider information
-  repositoryContexts: # list of repository context the component version "lived" in, with the current one at the top 
+  # name of the component. Must start with URL-prefix that should be controlled
+  # by the owner of the component to avoid collisions
+  # regex: ^[a-z][-a-z0-9]*([.][a-z][-a-z0-9]*)*[.][a-z]{2,}(/[a-z][-a-z0-9_]*([.][a-z][-a-z0-9_]*)*)+$
+  name: github.com/weaveworks/weave-gitops 
+  # version of the component. Must adhere to “relaxed SemVer”
+  # major, minor (+ optional patch level) - optional v-prefix
+  # regex: ^[v]?(0|[1-9]\\d*)(?:\\.(0|[1-9]\\d*))?(?:\\.(0|[1-9]\\d*))?(?:-((?:0|[1-9]\\d*|\\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\\.(?:0|[1-9]\\d*|\\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\\+([0-9a-zA-Z-]+(?:\\.[0-9a-zA-Z-]+)*))?$
+
+  version: v1.0.0 
+  # component provider
+  provider: weaveworks 
+  # list of labels that can contain arbitrary metadata in form of K/V pairs
+  # labels can be added on component root, resource, source and reference level
+  labels:
+  - name: link-to-documentation
+    value: https://github.com/weaveworks/weave-gitops
+  # list of repository context the component version "lived" in,
+  # with the current one at the top
+  repositoryContexts:  
   - baseUrl: ghcr.io
     componentNameMapping: urlPath
     subPath: phoban01/ocm
     type: OCIRegistry
-  resources: # list of resources modelled by the component
-  - name: image # resource name
-    relation: external # resource location (external repository or internal to this repository)
-    type: ociImage # resource type
-    version: v0.14.1 # resource version
-    access: # metadata describing how to access the resource
-      type: ociArtifact # type of access information
+  # list of resources that describe the payload of the component
+  resources: 
+    # resource name
+  - name: image
+    # resource location (external repository or internal to this repository)
+    relation: external 
+    # resource type
+    type: ociImage 
+    # resource version. Must also adhere to “relaxed SemVer” (see `component.versio` above`)
+    version: v0.14.1
+    # metadata describing how to access the resource
+    access:
+      # type of access information
+      type: ociArtifact 
       imageReference: ghcr.io/weaveworks/wego-app:v0.14.1
-    digest: # signing metadata for the resource
+    # signing metadata for the resource (if component has been signed)
+    digest: 
       hashAlgorithm: SHA-256
       normalisationAlgorithm: ociArtifactDigest/v1
       value: efa2b9980ca2de65dc5a0c8cc05638b1a4b4ce8f6972dc08d0e805e5563ba5bb
-  sources: # list of sources relevant to this component
-  - name: weave-gitops # source name
-    type: git # source type
-    version: v0.14.1 # source version
-    access: # metadata describing how to access the source
+  # list of sources that describe the input for creating the resources
+  sources: 
+    # source name
+  - name: weave-gitops
+    # source type
+    type: git 
+    # source version. Must also adhere to “relaxed SemVer” (see `component.versio` above`)
+    version: v0.14.1 
+    # metadata describing how to access the source
+    access: 
       commit: 727513969553bfcc603e1c0ae1a75d79e4132b58
       ref: refs/tags/v0.14.1
       repoUrl: github.com/weaveworks/weave-gitops
       type: gitHub
-  componentReferences: # list of references to other components
-  - name: prometheus # reference name
-    version: v1.0.0 # reference version
-    componentName: cncf.io/prometheus # referenced component name
-    digest: # signing metadata for the referenced resource
+  # list of references to other components
+  componentReferences:
+  # reference name 
+  - name: prometheus 
+    # reference version
+    version: v1.0.0 
+    # referenced component name
+    componentName: cncf.io/prometheus 
+    # signing metadata for the referenced resource (if component has been signed)
+    digest: 
       hashAlgorithm: SHA-256
       normalisationAlgorithm: jsonNormalisation/v1
       value: 04eb20b6fd942860325caf7f4415d1acf287a1aabd9e4827719328ba25d6f801
-signatures: # list of signatures used for signing and verification
-- name: ww-dev # name of the signature
-  digest: # digest of the signature including the algorithm used
+# list of signatures used for signing and verification
+signatures: 
+  # name of the signature
+- name: ww-dev 
+  # digest of the signature including the algorithm used
+  digest: 
     hashAlgorithm: SHA-256
     normalisationAlgorithm: jsonNormalisation/v1
     value: 4faff7822616305ecd09284d7c3e74a64f2269dcc524a9cdf0db4b592b8cee6a
-  signature: # signature including the algorithm used
+  # signature including the algorithm used
+  signature: 
     algorithm: RSASSA-PSS
     mediaType: application/vnd.ocm.signature.rsa
-    value: 26468587671bdbd2166cf5f69829f090c10768511b15e804294fcb26e552654316c8f4851ed396f279ec99335e5f4b11cb043feb97f1f9a42115f4fda2d31ae8b481b7303b9a913d3a4b92d446fbee9ed487c93b09e513f3f68355040ec08454675e1f407422062abbd2681f70dd5488ad29020b30cfa7e001455c550458da96166bc3243c8426977d73352aface5323fb2b5a374e9c31b272a59c160b85631231c9fc2f23c032401b80fef937029a39111cee34470c61ae86cd4942553466411a5a116159fdcc10e50fe9360c5184028e72d1fe9c7315f26e15d7b4849f62d197501b8cc6b6f1b1391ecc2fc2fc0c1290d2554594505b25fa8f9bfb28c8df24
Next
Version 3
\ No newline at end of file + value: 26468587671bdbd2166cf5f69829f090c10768511b15e804294fcb26e552654316c8f4851ed396f279ec99335e5f4b11cb043feb97f1f9a42115f4fda2d31ae8b481b7303b9a913d3a4b92d446fbee9ed487c93b09e513f3f68355040ec08454675e1f407422062abbd2681f70dd5488ad29020b30cfa7e001455c550458da96166bc3243c8426977d73352aface5323fb2b5a374e9c31b272a59c160b85631231c9fc2f23c032401b80fef937029a39111cee34470c61ae86cd4942553466411a5a116159fdcc10e50fe9360c5184028e72d1fe9c7315f26e15d7b4849f62d197501b8cc6b6f1b1391ecc2fc2fc0c1290d2554594505b25fa8f9bfb28c8df24
Next
About the OCM Project
\ No newline at end of file diff --git a/docs/component-descriptors/version-3/index.html b/docs/component-descriptors/version-3/index.html deleted file mode 100644 index 6e864091..00000000 --- a/docs/component-descriptors/version-3/index.html +++ /dev/null @@ -1,58 +0,0 @@ -Version 3 | Open Component Model -
- -
Docs

Version 3

The following is an example of a public-key-based signed component descriptor containing a resource, source and one component reference. It uses the v3alpha1 schema. There are no differences in the semantics between version v2 and v3. apiVersion is used as kind of moniker for different serializing/deserializing formats (v3 has the format of Kubernetes resources).

This component is publicly available and can be inspected using the following command:

ocm componentversion get --repo ghcr.io/phoban01/ocm github.com/weaveworks/weave-gitops --scheme v3alpha1 -oyaml

Component Descriptor

apiVersion: ocm.software/v3alpha1 # component schema version
-kind: ComponentVersion
-metadata:
-  name: github.com/weaveworks/weave-gitops # name of the component
-  provider: # component provider information
-    name: weaveworks
-  version: v1.0.0 # version of the component
-repositoryContexts: # list of repository context the component version "lived" in, with the current one at the top 
-- baseUrl: ghcr.io
-  componentNameMapping: urlPath
-  subPath: phoban01/ocm
-  type: OCIRegistry
-spec:
-  resources: # list of resources modelled by the component
-  - name: image # resource name
-    relation: external # resource location (external repository or internal to this repository)
-    type: ociImage # resource type
-    version: v0.14.1 # resource version
-    access: # metadata describing how to access the resource
-      type: ociArtifact # type of accesss information
-      imageReference: ghcr.io/weaveworks/wego-app:v0.14.1 # oci image url
-    digest: # signing metadata for the resource
-      hashAlgorithm: SHA-256
-      normalisationAlgorithm: ociArtifactDigest/v1
-      value: efa2b9980ca2de65dc5a0c8cc05638b1a4b4ce8f6972dc08d0e805e5563ba5bb # the digest itself
-  sources: # list of sources relevant to this component
-  - name: weave-gitops # source name
-    type: git # source type
-    version: v0.14.1 # source version
-    access: # metadata describing how to access the source
-      type: gitHub #
-      ref: refs/tags/v0.14.1
-      repoUrl: github.com/weaveworks/weave-gitops
-      commit: 727513969553bfcc603e1c0ae1a75d79e4132b58
-  references: # list of references to other components
-  - name: prometheus # reference name
-    version: v1.0.0 # reference version
-    componentName: cncf.io/prometheus # referenced component name
-    digest: # signing metadata for the referenced resource
-      hashAlgorithm: SHA-256
-      normalisationAlgorithm: jsonNormalisation/v1
-      value: 04eb20b6fd942860325caf7f4415d1acf287a1aabd9e4827719328ba25d6f801
-signatures: # list of signatures used for signing and verification
-- name: ww-dev # name of the signature
-  digest: # digest of the signature including the algorithm used
-    hashAlgorithm: SHA-256
-    normalisationAlgorithm: jsonNormalisation/v1
-    value: 4faff7822616305ecd09284d7c3e74a64f2269dcc524a9cdf0db4b592b8cee6a
-  signature: # signature including the algorithm used
-    algorithm: RSASSA-PSS
-    mediaType: application/vnd.ocm.signature.rsa
-    value: 26468587671bdbd2166cf5f69829f090c10768511b15e804294fcb26e552654316c8f4851ed396f279ec99335e5f4b11cb043feb97f1f9a42115f4fda2d31ae8b481b7303b9a913d3a4b92d446fbee9ed487c93b09e513f3f68355040ec08454675e1f407422062abbd2681f70dd5488ad29020b30cfa7e001455c550458da96166bc3243c8426977d73352aface5323fb2b5a374e9c31b272a59c160b85631231c9fc2f23c032401b80fef937029a39111cee34470c61ae86cd4942553466411a5a116159fdcc10e50fe9360c5184028e72d1fe9c7315f26e15d7b4849f62d197501b8cc6b6f1b1391ecc2fc2fc0c1290d2554594505b25fa8f9bfb28c8df24
Prev
Version 2
Next
About the OCM Project
\ No newline at end of file diff --git a/docs/contribution/contributing-guideline/index.html b/docs/contribution/contributing-guideline/index.html index e3e1fac1..5c0d5593 100644 --- a/docs/contribution/contributing-guideline/index.html +++ b/docs/contribution/contributing-guideline/index.html @@ -3,8 +3,8 @@ -
Docs

Contributing Guideline

Welcome to the OCM community!

Thank you for taking the time to contribute to OCM.

DCO

By contributing to this project you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution.

We require all commits to be signed. By signing off with your signature, you certify that you wrote the patch or otherwise have the right to contribute the material by the rules of the DCO:

Signed-off-by: Jane Doe <jane.doe@example.com>

If your user.name and user.email are configured in your Git config, you can sign your commit automatically with git commit -s.

Support Channels

Before opening a new issue or submitting a Pull Request, make sure to search through the docs, open and closed issues, open and merged Pull Requests, and the Discussions board to check whether your question has been raised or answered already.

Please open an issue in any of the repositories in the open-component-model organisation if you wish to request a new feature or report a bug.

If you wish to propose or discuss a more involved feature or change to any of the OCM projects, you could start a new thread in the ocm Discussion Board. For example, this could be helpful if you wish to vet an idea before writing a feature request. It is a space to discuss in public with maintainers, contributors, users, and other interested parties. After reaching some form of consensus, the proposed changes can go through the pull request process where implementation details are reviewed, approved, or rejected by maintainers.

Ways to Contribute

We welcome all types of contributions, including:

  • New features
  • Bug reports/fixes
  • Reviewing/updating documentation
  • Refactoring
  • Backfilling tests
  • Joining discussions
  • Web design
  • Release management
  • Reviews
  • Board discussions

You may find it helpful to start a new thread in the ocm Discussion Board for questions, help requests, feature requests, or any other type of discussion about OCM. A maintainer will reach out to you as soon as possible.

Find an Issue

Take a look at the OCM issues to find out more about what is currently in the works and what is planned. +

Docs

Contributing Guideline

Welcome to the OCM community!

Thank you for taking the time to contribute to OCM.

DCO

By contributing to this project you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution.

We require all commits to be signed. By signing off with your signature, you certify that you wrote the patch or otherwise have the right to contribute the material by the rules of the DCO:

Signed-off-by: Jane Doe <jane.doe@example.com>

If your user.name and user.email are configured in your Git config, you can sign your commit automatically with git commit -s.

Support Channels

Before opening a new issue or submitting a Pull Request, make sure to search through the docs, open and closed issues, open and merged Pull Requests, and the Discussions board to check whether your question has been raised or answered already.

Please open an issue in any of the repositories in the open-component-model organisation if you wish to request a new feature or report a bug.

If you wish to propose or discuss a more involved feature or change to any of the OCM projects, you could start a new thread in the ocm Discussion Board. For example, this could be helpful if you wish to vet an idea before writing a feature request. It is a space to discuss in public with maintainers, contributors, users, and other interested parties. After reaching some form of consensus, the proposed changes can go through the pull request process where implementation details are reviewed, approved, or rejected by maintainers.

Ways to Contribute

We welcome all types of contributions, including:

  • New features
  • Bug reports/fixes
  • Reviewing/updating documentation
  • Refactoring
  • Backfilling tests
  • Joining discussions
  • Web design
  • Release management
  • Reviews
  • Board discussions

You may find it helpful to start a new thread in the ocm Discussion Board for questions, help requests, feature requests, or any other type of discussion about OCM. A maintainer will reach out to you as soon as possible.

Find an Issue

Take a look at the OCM issues to find out more about what is currently in the works and what is planned. If you find something that you are interested in picking up, please leave a comment and wait for a maintainer to give you the green light to claim it and start working on it.

If you would like to contribute but are unsure about where to start, feel free to let the maintainers know through the ocm Discussion Board and someone will reach out to you.

Local Development

Each project has its own setup for local development.

Submitting Pull Requests

Ready to contribute? Read and follow the sections below to get your contribution to the finish line.

In general all files of the project are created under Apache 2.0 license. The project uses the REUSE process and tooling that supports maintaining licensing information centrally in a .reuse/dep5 config file on repository level. This means that in general there SHOULD NOT be any license and copyright specifiy SPDX headers on file level. Only in cases where content is copied from sources that use a different license and already use headers like

// SPDX-FileCopyrightText: Copyright 2010 The Go Authors. All rights reserved.
 //
 // SPDX-License-Identifier: BSD-3-Clause

the headers of the source file should be kept and eventually aggregated with the Apache 2.0 license. Please check the REUSE FAQ for details.

Such files should be explicitly added as deviating from the .reuse/dep5 config file using the Files-Excluded field. Excluding the file /pkg/foo.go and pkg/bar.go from the general rule to add the Apache 2.0 license to all files, would look like this:

Files: **
diff --git a/docs/contribution/index.html b/docs/contribution/index.html
index 48985bb0..e13eb040 100644
--- a/docs/contribution/index.html
+++ b/docs/contribution/index.html
@@ -3,5 +3,5 @@
 
-
Docs

Contribute

\ No newline at end of file +
Docs

Contribute

\ No newline at end of file diff --git a/docs/contribution/security-guideline/index.html b/docs/contribution/security-guideline/index.html index 49951466..b4da9ed6 100644 --- a/docs/contribution/security-guideline/index.html +++ b/docs/contribution/security-guideline/index.html @@ -3,5 +3,5 @@ -
Docs

Security Guideline

Report a Vulnerability

Please do not report security vulnerabilities through public GitHub issues!

Instead, please report them via the SAP Trust Center at https://www.sap.com/about/trust-center/security/incident-management.html.

If you prefer to submit via email, please send an email to secure@sap.com. If possible, encrypt your message with the SAP PGP key; please download it from the SAP Trust Center.

Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:

  • The repository name or URL
  • Type of issue (buffer overflow, SQL injection, cross-site scripting, etc.)
  • Full paths of the source file(s) related to the manifestation of the issue
  • The location of the affected source code (tag/branch/commit or direct URL)
  • Any particular configuration required to reproduce the issue
  • Step-by-step instructions to reproduce the issue
  • Proof-of-concept or exploit code (if possible)
  • Impact of the issue, including how an attacker might exploit the issue

This information will help us triage your report more quickly

Further details may be found here: https://github.com/open-component-model/ocm/security/policy

Advisories

Advisories will be published directly on the affected repositories, e.g:

Prev
Contributing Guideline
Next
Credentials in an .ocmconfig file
\ No newline at end of file +
Docs

Security Guideline

Report a Vulnerability

Please do not report security vulnerabilities through public GitHub issues!

Instead, please report them via the SAP Trust Center at https://www.sap.com/about/trust-center/security/incident-management.html.

If you prefer to submit via email, please send an email to secure@sap.com. If possible, encrypt your message with the SAP PGP key; please download it from the SAP Trust Center.

Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:

  • The repository name or URL
  • Type of issue (buffer overflow, SQL injection, cross-site scripting, etc.)
  • Full paths of the source file(s) related to the manifestation of the issue
  • The location of the affected source code (tag/branch/commit or direct URL)
  • Any particular configuration required to reproduce the issue
  • Step-by-step instructions to reproduce the issue
  • Proof-of-concept or exploit code (if possible)
  • Impact of the issue, including how an attacker might exploit the issue

This information will help us triage your report more quickly

Further details may be found here: https://github.com/open-component-model/ocm/security/policy

Advisories

Advisories will be published directly on the affected repositories, e.g:

Prev
Contributing Guideline
Next
Credentials in an .ocmconfig file
\ No newline at end of file diff --git a/docs/controller/architecture/index.html b/docs/controller/architecture/index.html index 1f4ea857..ad80ae92 100644 --- a/docs/controller/architecture/index.html +++ b/docs/controller/architecture/index.html @@ -3,8 +3,8 @@ -
Docs

Architecture

This document explains the architecture of the OCM Kubernetes Controller Set (KCS). The purpose of the KCS is to enable the automated deployment of components using Kubernetes and Flux.

The following functions are provided as part of the KCS:

  • Replication: replication of components from one OCM repository to another
  • Signature Verification: verification of component signatures before resources are reconciled
  • Resource Reconciliation: individual resources can be extracted from a component and reconciled to machines internal or external to the cluster
  • Resource transformation: resource localization & configuration can be performed out of the box, with any other kind of modification supported via an extensible architecture
  • Component unpacking: multiple resources can be extracted from a component and transformed with a common set of user definable operations
  • Git synchronization: resources extracted from a component can be pushed to a git repository

One of the central design decisions underpinning KCS is that resources should be composable. To this end we have introduced the concept of Snapshots; snapshots are immutable, Flux-compatible, single layer OCI images containing a single OCM resource. Snapshots are stored in an in-cluster registry and in addition to making component resources accessible for transformation, they also can be used as a caching mechanism to reduce unnecessary calls to the source OCM registry.

Controllers

The KCS consists of the following controllers:

  • OCM controller
  • Replication controller
  • Git sync controller

OCM controller

The ocm-controller is responsible for the core work necessary to utilise resources from an OCM component in a Kubernetes cluster. This includes resolving ComponentDescriptor metadata for a particular component version, performing authentication to OCM repositories, retrieving artifacts from OCM repositories, making individual resources from the OCM component available within the cluster, performing localization and configuration.

Snapshots are used to pass resources between controllers and are stored in an in-cluster registry.

The ocm-controller consists of 5 sub-controllers:

Component Version Controller

The Component Version controller reconciles component versions from an OCI repository by fetching the component descriptor and any referenced component descriptors. The component version controller will also verify signatures for all the public keys provided. The Component Version controller does not fetch any resources other than component descriptors. It is used by downstream controllers to access component descriptors and to attest the validity of component signatures. Downstream controllers can look up a component descriptor via the status field of the component version resource.

sequenceDiagram +
Docs

Architecture

This document explains the architecture of the OCM Kubernetes Controller Set (KCS). The purpose of the KCS is to enable the automated deployment of components using Kubernetes and Flux.

The following functions are provided as part of the KCS:

  • Replication: replication of components from one OCM repository to another
  • Signature Verification: verification of component signatures before resources are reconciled
  • Resource Reconciliation: individual resources can be extracted from a component and reconciled to machines internal or external to the cluster
  • Resource transformation: resource localization & configuration can be performed out of the box, with any other kind of modification supported via an extensible architecture
  • Component unpacking: multiple resources can be extracted from a component and transformed with a common set of user definable operations
  • Git synchronization: resources extracted from a component can be pushed to a git repository

One of the central design decisions underpinning KCS is that resources should be composable. To this end we have introduced the concept of Snapshots; snapshots are immutable, Flux-compatible, single layer OCI images containing a single OCM resource. Snapshots are stored in an in-cluster registry and in addition to making component resources accessible for transformation, they also can be used as a caching mechanism to reduce unnecessary calls to the source OCM registry.

Controllers

The KCS consists of the following controllers:

  • OCM controller
  • Replication controller
  • Git sync controller

OCM controller

The ocm-controller is responsible for the core work necessary to utilise resources from an OCM component in a Kubernetes cluster. This includes resolving ComponentDescriptor metadata for a particular component version, performing authentication to OCM repositories, retrieving artifacts from OCM repositories, making individual resources from the OCM component available within the cluster, performing localization and configuration.

Snapshots are used to pass resources between controllers and are stored in an in-cluster registry.

The ocm-controller consists of 5 sub-controllers:

Component Version Controller

The Component Version controller reconciles component versions from an OCI repository by fetching the component descriptor and any referenced component descriptors. The component version controller will also verify signatures for all the public keys provided. The Component Version controller does not fetch any resources other than component descriptors. It is used by downstream controllers to access component descriptors and to attest the validity of component signatures. Downstream controllers can look up a component descriptor via the status field of the component version resource.

sequenceDiagram User->>Kubernetes API: submit ComponentVersion CR Kubernetes API-->>Component Version Controller: Component Version Created Event Component Version Controller->>OCM Repository: Find latest component matching semver diff --git a/docs/controller/controller-reference/api-reference/index.html b/docs/controller/controller-reference/api-reference/index.html index f6f6d28b..4f5d7263 100644 --- a/docs/controller/controller-reference/api-reference/index.html +++ b/docs/controller/controller-reference/api-reference/index.html @@ -3,5 +3,5 @@ -
Docs

API Reference

\ No newline at end of file +
Docs

API Reference

\ No newline at end of file diff --git a/docs/controller/controller-reference/api-reference/ocm-controller-api-v1/index.html b/docs/controller/controller-reference/api-reference/ocm-controller-api-v1/index.html index df1f913a..e2cef72e 100644 --- a/docs/controller/controller-reference/api-reference/ocm-controller-api-v1/index.html +++ b/docs/controller/controller-reference/api-reference/ocm-controller-api-v1/index.html @@ -7,8 +7,8 @@ -
Docs

OCM Controller API v1

Packages:

delivery.ocm.software/v1alpha1

Package v1alpha1 contains API Schema definitions for the delivery v1alpha1 API group

Resource Types:

    ComponentVersion

    ComponentVersion is the Schema for the ComponentVersions API.

    FieldDescription
    metadata
    Kubernetes meta/v1.ObjectMeta    		Refer to the Kubernetes API documentation for the fields of the +
    Docs

    OCM Controller API v1

    Packages:

    delivery.ocm.software/v1alpha1

    Package v1alpha1 contains API Schema definitions for the delivery v1alpha1 API group

    Resource Types:

      ComponentVersion

      ComponentVersion is the Schema for the ComponentVersions API.

      FieldDescription
      metadata
      Kubernetes meta/v1.ObjectMeta      		Refer to the Kubernetes API documentation for the fields of the metadata field.
      spec
      ComponentVersionSpec

      component
      string

      Component specifies the name of the ComponentVersion.

      version
      Version

      Version specifies the version information for the ComponentVersion.

      repository
      Repository

      Repository provides details about the OCI repository from which the component descriptor can be retrieved.

      interval
      Kubernetes meta/v1.Duration

      Interval specifies the interval at which the Repository will be checked for updates.

      verify
      []Signature      		(Optional)

      Verify specifies a list signatures that should be validated before the ComponentVersion is marked Verified.

      references
      ReferencesConfig      		(Optional)

      References specifies configuration for the handling of nested component references.

      suspend
      bool      		(Optional)

      Suspend can be used to temporarily pause the reconciliation of the ComponentVersion resource.

      serviceAccountName
      string      		(Optional)

      ServiceAccountName can be used to configure access to both destination and source repositories. diff --git a/docs/controller/controller-reference/api-reference/replication-controller-api-v1/index.html b/docs/controller/controller-reference/api-reference/replication-controller-api-v1/index.html index e620cffc..841cd58b 100644 --- a/docs/controller/controller-reference/api-reference/replication-controller-api-v1/index.html +++ b/docs/controller/controller-reference/api-reference/replication-controller-api-v1/index.html @@ -7,8 +7,8 @@ -

      Docs

      Replication Controller API v1

      Packages:

      delivery.ocm.software/v1alpha1

      Package v1alpha1 contains API Schema definitions for the delivery v1alpha1 API group

      Resource Types:

        ComponentSubscription

        ComponentSubscription is the Schema for the componentsubscriptions API

        FieldDescription
        metadata
        Kubernetes meta/v1.ObjectMeta        		Refer to the Kubernetes API documentation for the fields of the +
        Docs

        Replication Controller API v1

        Packages:

        delivery.ocm.software/v1alpha1

        Package v1alpha1 contains API Schema definitions for the delivery v1alpha1 API group

        Resource Types:

          ComponentSubscription

          ComponentSubscription is the Schema for the componentsubscriptions API

          FieldDescription
          metadata
          Kubernetes meta/v1.ObjectMeta          		Refer to the Kubernetes API documentation for the fields of the metadata field.
          spec
          ComponentSubscriptionSpec

          component
          string

          Component specifies the name of the Component that should be replicated.

          semver
          string          		(Optional)

          Semver specifies an optional semver constraint that is used to evaluate the component versions that should be replicated.

          source
          OCMRepository

          Source holds the OCM Repository details for the replication source.

          destination
          OCMRepository          		(Optional)

          Destination holds the destination or target OCM Repository details. The ComponentVersion will be transfered into this repository.

          interval
          Kubernetes meta/v1.Duration

          Interval is the reconciliation interval, i.e. at what interval shall a reconciliation happen. diff --git a/docs/controller/controller-reference/index.html b/docs/controller/controller-reference/index.html index 66f65d20..57f42d4f 100644 --- a/docs/controller/controller-reference/index.html +++ b/docs/controller/controller-reference/index.html @@ -3,5 +3,5 @@ -

          Docs

          Kubernetes Controllers

          \ No newline at end of file +
          Docs

          Kubernetes Controllers

          \ No newline at end of file diff --git a/docs/controller/controller-reference/ocm-controller/component-version/index.html b/docs/controller/controller-reference/ocm-controller/component-version/index.html index 27704fce..05cde158 100644 --- a/docs/controller/controller-reference/ocm-controller/component-version/index.html +++ b/docs/controller/controller-reference/ocm-controller/component-version/index.html @@ -5,8 +5,8 @@ -
          Docs

          Component Version

          The ComponentVersion API produces component descriptors for a specific component version.

          Example

          The following is an example of a ComponentVersion:

          apiVersion: delivery.ocm.software/v1alpha1
+
          Docs

          Component Version

          The ComponentVersion API produces component descriptors for a specific component version.

          Example

          The following is an example of a ComponentVersion:

          apiVersion: delivery.ocm.software/v1alpha1
 kind: ComponentVersion
 metadata:
   name: podinfo
diff --git a/docs/controller/controller-reference/ocm-controller/index.html b/docs/controller/controller-reference/ocm-controller/index.html
index 3778d75d..e6ca62a3 100644
--- a/docs/controller/controller-reference/ocm-controller/index.html
+++ b/docs/controller/controller-reference/ocm-controller/index.html
@@ -3,5 +3,5 @@
 
-
          Docs

          OCM Controller

          \ No newline at end of file +
          Docs

          OCM Controller

          \ No newline at end of file diff --git a/docs/controller/controller-reference/replication-controller/component-subscription/index.html b/docs/controller/controller-reference/replication-controller/component-subscription/index.html index 38a67e87..d35ef211 100644 --- a/docs/controller/controller-reference/replication-controller/component-subscription/index.html +++ b/docs/controller/controller-reference/replication-controller/component-subscription/index.html @@ -5,8 +5,8 @@ -
          Docs

          Component Subscription

          The ComponentSubscription API produces component descriptors for a specific component version.

          Example

          The following is an example of a ComponentSubscription:

          apiVersion: delivery.ocm.software/v1alpha1
+
          Docs

          Component Subscription

          The ComponentSubscription API produces component descriptors for a specific component version.

          Example

          The following is an example of a ComponentSubscription:

          apiVersion: delivery.ocm.software/v1alpha1
 kind: ComponentSubscription
 metadata:
   name: podinfo
diff --git a/docs/controller/controller-reference/replication-controller/index.html b/docs/controller/controller-reference/replication-controller/index.html
index 7dcf1c9d..aed80b9a 100644
--- a/docs/controller/controller-reference/replication-controller/index.html
+++ b/docs/controller/controller-reference/replication-controller/index.html
@@ -7,8 +7,8 @@
 
-
          Docs

          Replication Controller

          OCM Controller API reference v1alpha1

          Packages:

          delivery.ocm.software/v1alpha1

          Package v1alpha1 contains API Schema definitions for the delivery v1alpha1 API group

          Resource Types:

            Component

            Component gathers together reconciled information about a component.

            FieldDescription
            name
            string
            version
            string
            registry
            Registry

            ComponentSubscription

            ComponentSubscription is the Schema for the componentsubscriptions API

            FieldDescription
            metadata
            Kubernetes meta/v1.ObjectMeta            		Refer to the Kubernetes API documentation for the fields of the +
            Docs

            Replication Controller

            OCM Controller API reference v1alpha1

            Packages:

            delivery.ocm.software/v1alpha1

            Package v1alpha1 contains API Schema definitions for the delivery v1alpha1 API group

            Resource Types:

              Component

              Component gathers together reconciled information about a component.

              FieldDescription
              name
              string
              version
              string
              registry
              Registry

              ComponentSubscription

              ComponentSubscription is the Schema for the componentsubscriptions API

              FieldDescription
              metadata
              Kubernetes meta/v1.ObjectMeta              		Refer to the Kubernetes API documentation for the fields of the metadata field.
              spec
              ComponentSubscriptionSpec

              interval
              Kubernetes meta/v1.Duration

              Interval is the reconciliation interval, i.e. at what interval shall a reconciliation happen. This is used to requeue objects for reconciliation in case of success as well as already reconciling objects.

              source
              OCMRepository
              destination
              OCMRepository
              component
              string
              serviceAccountName
              string              		(Optional)

              ServiceAccountName can be used to configure access to both destination and source repositories. If service account is defined, it’s usually redundant to define access to either source or destination, but diff --git a/docs/controller/index.html b/docs/controller/index.html index 72d64042..49d9bae1 100644 --- a/docs/controller/index.html +++ b/docs/controller/index.html @@ -3,5 +3,5 @@ -

              Docs

              OCM Controllers

              \ No newline at end of file +
              Docs

              OCM Controllers

              \ No newline at end of file diff --git a/docs/controller/installation/index.html b/docs/controller/installation/index.html index 81157f92..7104ba50 100644 --- a/docs/controller/installation/index.html +++ b/docs/controller/installation/index.html @@ -3,8 +3,8 @@ -
              Docs

              Installation

              ocm-controller

              The ocm-controller can be installed using the OCM CLI:

              ocm controller install

              This command will install the ocm-controller in the kubernetes cluster specified by the current KUBECONFIG context.

              The following flags are available:

              Flags:
+
              Docs

              Installation

              ocm-controller

              The ocm-controller can be installed using the OCM CLI:

              ocm controller install

              This command will install the ocm-controller in the kubernetes cluster specified by the current KUBECONFIG context.

              The following flags are available:

              Flags:
   -u, --base-url string          the base url to the ocm-controller's release page (default "https://github.com/open-component-model/ocm-controller/releases")
   -c, --controller-name string   name of the controller that's used for status check (default "ocm-controller")
   -d, --dry-run                  if enabled, prints the downloaded manifest file
diff --git a/docs/examples/credentials-in-an-.ocmconfig-file/index.html b/docs/examples/credentials-in-an-.ocmconfig-file/index.html
index 1fafd6b8..18400231 100644
--- a/docs/examples/credentials-in-an-.ocmconfig-file/index.html
+++ b/docs/examples/credentials-in-an-.ocmconfig-file/index.html
@@ -3,8 +3,8 @@
 
-
              Docs

              Credentials in an .ocmconfig file

              Overview

              The OCM command line client can be configured by supplying it with a configuration file. By default, the CLI looks for configuration in $HOME/.ocmconfig, if it exists.

              The configuration file can be used in particular to specify the credentials, which are required for the CLI to be able to access the artifact repositories referenced in CLI commands.

              Examples

              This page contains basic examples of credentials configuration for a few most common artifact repository types. The examples below are complete .ocmconfig files, not snippets.

              For comprehensive documentation on the credentials topic, including usage of certificates or HashiCorp Vault, execute the command ocm credential-handling.

              Repositories and Consumers

              In the examples below, some configuration is located under configurations[0].repositories, and some other under configurations[0].consumers. This chapter explains the difference between repositories and consumers, which is potentially not as obvious as one could think.

              In this context, repository is a place where credentials can be stored, i.e., it is a credentials repository. For example, Docker’s config.json can store multiple credentials, and in that sense the file serves as a repository that can store and provide credentials. That is why its location is configured under repositories. Other examples of credentials repositories can be the NPM’s .npmrc file or a HashiCorp Vault instance.

              A consumer is something the credentials are required for. For example, if you need to configure credentials that are required to log in to an OCI registry, one could say that the registry will be consuming these credentials, i.e., the registry is a credentials consumer. That is why it is configured under consumers.

              Reuse Credentials Configured for Docker

              This .ocmconfig file will tell the OCM CLI to use credentials configuration from Docker’s config.json file.

              type: generic.config.ocm.software/v1
+
              Docs

              Credentials in an .ocmconfig file

              Overview

              The OCM command line client can be configured by supplying it with a configuration file. By default, the CLI looks for configuration in $HOME/.ocmconfig, if it exists.

              The configuration file can be used in particular to specify the credentials, which are required for the CLI to be able to access the artifact repositories referenced in CLI commands.

              Examples

              This page contains basic examples of credentials configuration for a few most common artifact repository types. The examples below are complete .ocmconfig files, not snippets.

              For comprehensive documentation on the credentials topic, including usage of certificates or HashiCorp Vault, execute the command ocm credential-handling.

              Repositories and Consumers

              In the examples below, some configuration is located under configurations[0].repositories, and some other under configurations[0].consumers. This chapter explains the difference between repositories and consumers, which is potentially not as obvious as one could think.

              In this context, repository is a place where credentials can be stored, i.e., it is a credentials repository. For example, Docker’s config.json can store multiple credentials, and in that sense the file serves as a repository that can store and provide credentials. That is why its location is configured under repositories. Other examples of credentials repositories can be the NPM’s .npmrc file or a HashiCorp Vault instance.

              A consumer is something the credentials are required for. For example, if you need to configure credentials that are required to log in to an OCI registry, one could say that the registry will be consuming these credentials, i.e., the registry is a credentials consumer. That is why it is configured under consumers.

              Reuse Credentials Configured for Docker

              This .ocmconfig file will tell the OCM CLI to use credentials configuration from Docker’s config.json file.

              type: generic.config.ocm.software/v1
 configurations:
   - type: credentials.config.ocm.software
     repositories:
diff --git a/docs/examples/index.html b/docs/examples/index.html
index 917ddf71..107ba15e 100644
--- a/docs/examples/index.html
+++ b/docs/examples/index.html
@@ -3,5 +3,5 @@
 
-
              Docs

              Examples

              \ No newline at end of file +
              Docs

              Examples

              \ No newline at end of file diff --git a/docs/examples/secure-software-delivery-with-flux-and-ocm/index.html b/docs/examples/secure-software-delivery-with-flux-and-ocm/index.html index 067ad597..ce1b3947 100644 --- a/docs/examples/secure-software-delivery-with-flux-and-ocm/index.html +++ b/docs/examples/secure-software-delivery-with-flux-and-ocm/index.html @@ -5,8 +5,8 @@ -
              Docs

              Secure software delivery with Flux and OCM

              The source code for the demo can be found at https://github.com/open-component-model/demo-secure-delivery. +

              Docs

              Secure software delivery with Flux and OCM

              The source code for the demo can be found at https://github.com/open-component-model/demo-secure-delivery. A video guide can be found here.

              Fully guided walkthrough

              workflow

              This walkthrough deploys a full end-to-end scenario demonstrating how OCM and Flux can be employed to continuously deploy applications in air-gapped environments.

              The demo environment consists of Gitea, Tekton, Flux and the OCM controller.

              To be able to show that provider and consumer are really disconnected, two distinct Gitea organizations are created:

              Software Provider

              The provider organization contains a repository which models the podinfo application. When a new release is created a Tekton pipeline will be triggered that builds the OCM component and pushes it to the software provider’s OCI registry.

              Software Consumer

              The software consumer organization models an air-gapped scenario where applications are deployed from a secure OCI registry rather than directly from an arbitrary public upstream source.

              The software consumer organization contains a repository named ocm-applications. During the setup of the demo a PR is created which contains a set of Kubernetes manifests required to deploy the OCM component published by the software provider.

              Once this pull request is merged the Flux machinery will deploy podinfo component. Capacitor can be used to understand the state of the cluster.

              Walkthrough

              Instructions are provided to guide you through the process of deploying the demo environment, cutting a release for “podinfo,” verifying the release automation, installing the component, viewing the Capacitor GitOps dashboard, accessing the deployed application, applying configuration changes, monitoring the application update, and cutting a new release with updated features.

              1. Setup demo environment

              To deploy the demo environment execute the following:

              make run

              Once the environment has been created, login to Gitea using the following credentials:

              username: ocm-admin
 password: password

              2. Cut a release for podinfo

              Next navigate to: https://gitea.ocm.dev/software-provider/podinfo-component/releases and click “New Release”.

              Enter “v1.0.0” for both the tag name and release name, and then click “Publish Release”.

              release

              3. Verify the release

              Once the release is published, navigate to https://ci.ocm.dev/#/namespaces/tekton-pipelines/pipelineruns and follow the progress of the release automation.

              ci

              4. Install the Component

              When the release pipeline has been completed we can install the component. Navigate to https://gitea.ocm.dev/software-consumer/ocm-applications/pulls/1 and merge the pull request.

              install

              5. View the Capacitor Dashboard

              After certificates are created the Capacitor component and the dashboard will be accessible at https://capacitor.ocm.dev. Give it a minute to spin up…

              capacitor

              5. View the application

              We can view the podinfo Helm release that’s been deployed in the default namespace: https://capacitor.ocm.dev/

              We can also view the running application at https://podinfo.ocm.dev

              podinfo

              6. Apply configuration

              The application can be configured using the parameters exposed in values.yaml. Now that podinfo is deployed we can tweak a few parameters. Navigate to https://gitea.ocm.dev/software-consumer/ocm-applications/_edit/main/values.yaml

              configure

              and add the following:

              podinfo:
diff --git a/docs/getting-started/getting-started-with-ocm/create-a-component-version/index.html b/docs/getting-started/getting-started-with-ocm/create-a-component-version/index.html
index cc4c443b..0674d9d3 100644
--- a/docs/getting-started/getting-started-with-ocm/create-a-component-version/index.html
+++ b/docs/getting-started/getting-started-with-ocm/create-a-component-version/index.html
@@ -1,16 +1,17 @@
 Create a Component Version | Open Component Model
-
              
+
              
 
-
              Docs
              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 is also the entity used to transfer components between component repositories. A CTF archive may contain any number of component versions. It may also be pushed to an OCM repository.
              Note that a CTF archive itself is also an OCM repository, so it can be used as source or target for component transfer operations.
              The command ocm add componentversions
-directly creates a component version from a component-constructor.yaml file and stores it in a 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:
              mkdir /tmp/helloworld
-cd /tmp/helloworld
              Now we download the podinfo Helm Chart that we want to use as local resource and extract it:
              helm repo add podinfo https://stefanprodan.github.io/podinfo
-helm pull --untar podinfo/podinfo
              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). As mentioned before our example component should contain a Helm Chart and a Docker image:
              # specify a schema to validate the configuration and get auto-completion in your editor
+
              Docs
              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:
              mkdir /tmp/helloworld
+cd /tmp/helloworld
              Now we download the podinfo Helm Chart that we want to use as local resource and extract it:
              helm repo add podinfo https://stefanprodan.github.io/podinfo
+helm pull --untar podinfo/podinfo
              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:
              # specify a schema to validate the configuration and get auto-completion in your editor
 # yaml-language-server: $schema=https://ocm.software/schemas/configuration-schema.yaml
 components:
 - name: github.com/acme.org/helloworld
+  # version needs to follow "relaxed" SemVer
   version: 1.0.0
   provider:
     name: acme.org
@@ -30,21 +31,22 @@
         imageReference: gcr.io/google_containers/echoserver:1.10
              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 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:
              ocm add componentversions --create --file ctf-hello-world component-constructor.yaml
                processing component-constructor.yaml...
+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:
              ocm add componentversions --create --file ctf-hello-world component-constructor.yaml
                processing component-constructor.yaml...
     processing document 1...
       processing index 1
   found 1 component
   adding component github.com/acme.org/helloworld:1.0.0...
     adding resource helmChart: "name"="mychart","version"="<componentversion>"...
     adding resource ociArtifact: "name"="image","version"="1.0.0"...
              What happened?
              The command creates the CTF archive (option --create) and adds the listed components
-with the described resources.
                ctf-hello-world/
+with the described resources.
                ctf-hello-world/
   ├── artifact-index.json
   └── blobs
       ├── sha256.125cf912d0f67b2b49e4170e684638a05a12f2fcfbdf3571e38a016273620b54
       ├── sha256.1cb2098e31e319df7243490464b48a8af138389abe9522c481ebc27dede4277b
       ├── sha256.974e652250ffaba57b820c462ce603fc1028a608b0fa09caef227f9e0167ce09
       └── sha256.d442bdf33825bace6bf08529b6f00cf0aacc943f3be6130325e1eb4a5dfae3a5
              The transport archive’s contents can be found in artifact-index.json. This file
-contains the list of component version artifacts to be transported.
              jq . ${CTF_ARCHIVE}/artifact-index.json
              {
+contains the list of component version artifacts to be transported.
              jq . ${CTF_ARCHIVE}/artifact-index.json
              {
   "schemaVersion": 1,
   "artifacts": [
     {
@@ -53,7 +55,7 @@
       "digest": "sha256:d3cf4858f5387eaea194b7e40b7f6eb23460a658ad4005c5745361978897e043"
     }
   ]
-}
              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:
              jq . ${CTF_ARCHIVE}/blobs/sha256.d3cf4858f5387eaea194b7e40b7f6eb23460a658ad4005c5745361978897e043
              {
+}
              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:
              jq . ${CTF_ARCHIVE}/blobs/sha256.d3cf4858f5387eaea194b7e40b7f6eb23460a658ad4005c5745361978897e043
              {
   "schemaVersion": 2,
   "mediaType": "application/vnd.oci.image.manifest.v1+json",
   "config": {
@@ -73,7 +75,7 @@
       "size": 16122
     }
   ]
-}
              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:
              tar xvf ${CTF_ARCHIVE}/blobs/sha256.4ab29c8acb0c8b002a5037e6d9edf2d657222da76fee2a10f38d65ecd981d0c6 -O - component-descriptor.yaml
              meta:
+}
              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:
              tar xvf ${CTF_ARCHIVE}/blobs/sha256.4ab29c8acb0c8b002a5037e6d9edf2d657222da76fee2a10f38d65ecd981d0c6 -O - component-descriptor.yaml
              meta:
   schemaVersion: v2
 component:
   name: github.com/acme/helloworld
diff --git a/docs/getting-started/getting-started-with-ocm/display-and-examine-component-versions/index.html b/docs/getting-started/getting-started-with-ocm/display-and-examine-component-versions/index.html
index aeeba682..4499a00b 100644
--- a/docs/getting-started/getting-started-with-ocm/display-and-examine-component-versions/index.html
+++ b/docs/getting-started/getting-started-with-ocm/display-and-examine-component-versions/index.html
@@ -3,9 +3,9 @@
 
-
              Docs
              Display and Examine Component Versions
              List Component Versions
              To show a component stored in an OCM repository or CTF archive (which itself is an OCM repository), the ocm get componentversion command can be used:
              ocm get componentversion ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0
                COMPONENT                      VERSION PROVIDER
-  ocm.software/toi/demo/helmdemo 0.12.0  ocm.software
              To see the component descriptor of the displayed component version, use the output format option -o yaml:
              ocm get cv ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 -o yaml
              component:
+
              Docs
              Display and Examine Component Versions
              List Component Versions
              To show a component stored in an OCM repository or CTF archive (which itself is an OCM repository), the ocm get componentversion command can be used:
              ocm get componentversion ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0
                COMPONENT                      VERSION PROVIDER
+  ocm.software/toi/demo/helmdemo 0.12.0  ocm.software
              To see the component descriptor of the displayed component version, use the output format option -o yaml:
              ocm get cv ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 -o yaml
              component:
   componentReferences:
   - componentName: ocm.software/toi/installers/helminstaller
     name: installer
@@ -41,12 +41,12 @@
     relation: local
     type: helmChart
     version: 0.12.0
-...
              To refer to the content of a component repository, the component name can be appended to the repository specification separated by // (you can also use the --repo option to specifiy the repository).
              In the example above, ghcr.io/open-component-model/ocm is the OCM repository, whereas ocm.software/toi/demo/helmdemo is the component stored in this component repository.
              Optionally, a specific version can be appended, separated by a colon (:). If no version is specified, all component versions will be displayed.
              With the option --recursive, it is possible to show the complete component version, including the component versions it references.
              ocm get cv ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 --recursive
                REFERENCEPATH                         COMPONENT                                 VERSION PROVIDER     IDENTITY
+...
              To refer to the content of a component repository, the component name can be appended to the repository specification separated by // (you can also use the --repo option to specifiy the repository).
              In the example above, ghcr.io/open-component-model/ocm is the OCM repository, whereas ocm.software/toi/demo/helmdemo is the component stored in this component repository.
              Optionally, a specific version can be appended, separated by a colon (:). If no version is specified, all component versions will be displayed.
              With the option --recursive, it is possible to show the complete component version, including the component versions it references.
              ocm get cv ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 --recursive
                REFERENCEPATH                         COMPONENT                                 VERSION PROVIDER     IDENTITY
                                         ocm.software/toi/demo/helmdemo            0.12.0  ocm.software
-  ocm.software/toi/demo/helmdemo:0.12.0 ocm.software/toi/installers/helminstaller 0.12.0  ocm.software "name"="installer"
              To get a tree view, add the option -o tree:
              ocm get cv ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 --recursive -o tree
                NESTING COMPONENT                                 VERSION PROVIDER     IDENTITY
+  ocm.software/toi/demo/helmdemo:0.12.0 ocm.software/toi/installers/helminstaller 0.12.0  ocm.software "name"="installer"
              To get a tree view, add the option -o tree:
              ocm get cv ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 --recursive -o tree
                NESTING COMPONENT                                 VERSION PROVIDER     IDENTITY
   └─ ⊗    ocm.software/toi/demo/helmdemo            0.12.0  ocm.software
-     └─   ocm.software/toi/installers/helminstaller 0.12.0  ocm.software "name"="installer"
              As mentioned before a CTF archive itself is an OCM repository, so we can execute the same commands on a CTF archive. So, let’s get the information about the component github.com/acme.org/helloworld we created in the previous step and that we stored in the CTF archive /tmp/helloworld/ctf-hello-world:
              ocm get cv /tmp/helloworld/ctf-hello-world//github.com/acme.org/helloworld:1.0.0
                COMPONENT                       VERSION  PROVIDER
-  github.com/acme.org/helloworld  0.1.0    ocm.software
              List the Resources of a Component Version
              To list the resources found in a component version tree, the command ocm get resources can be used:
              ocm get resources ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 --recursive -o tree
                COMPONENT                                       NAME           VERSION IDENTITY TYPE        RELATION
+     └─   ocm.software/toi/installers/helminstaller 0.12.0  ocm.software "name"="installer"
              As mentioned before a CTF archive itself is an OCM repository, so we can execute the same commands on a CTF archive. So, let’s get the information about the component github.com/acme.org/helloworld we created in the previous step and that we stored in the CTF archive /tmp/helloworld/ctf-hello-world:
              ocm get cv /tmp/helloworld/ctf-hello-world//github.com/acme.org/helloworld:1.0.0
                COMPONENT                       VERSION  PROVIDER
+  github.com/acme.org/helloworld  0.1.0    ocm.software
              List the Resources of a Component Version
              To list the resources found in a component version tree, the command ocm get resources can be used:
              ocm get resources ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 --recursive -o tree
                COMPONENT                                       NAME           VERSION IDENTITY TYPE        RELATION
   └─ ocm.software/toi/demo/helmdemo                              0.12.0
      ├─                                           chart          0.12.0           helmChart   local
      ├─                                           config-example 0.12.0           yaml        local
@@ -55,12 +55,12 @@
      ├─                                           package        0.12.0           toiPackage  local
      └─ ocm.software/toi/installers/helminstaller installer      0.12.0
         ├─                                        toiexecutor    0.12.0           toiExecutor local
-        └─                                        toiimage       0.12.0           ociImage    local
              Download the Resources of a Component Version
              Use the ocm download command to download resources such as component versions, individual resources or artifacts:
              ocm download resource ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 chart -O helmchart.tgz
                helmchart.tgz: 4707 byte(s) written
              Because it is stored as OCI artifact in an OCI registry, the filesystem format used for OCI artifacts is the blob format.
              What happened?
              The file helmchart.tgz was downloaded.
              tar xvf helmchart.tgz
                x index.json
+        └─                                        toiimage       0.12.0           ociImage    local
              Download the Resources of a Component Version
              Use the ocm download command to download resources such as component versions, individual resources or artifacts:
              ocm download resource ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 chart -O helmchart.tgz
                helmchart.tgz: 4707 byte(s) written
              Because it is stored as OCI artifact in an OCI registry, the filesystem format used for OCI artifacts is the blob format.
              What happened?
              The file helmchart.tgz was downloaded.
              tar xvf helmchart.tgz
                x index.json
   x oci-layout
   x blobs
   x blobs/sha256.a9dd654eed17e786b5c5445e8bc48f3a47371c2efe392a53a3fbecd9e942b696
   x blobs/sha256.c8017985866ceb44c2426a4ad9a429d6aec1f6818cb6dccbf964623139c1d1d5
-  x blobs/sha256.ea8e5b44cd1aff1f3d9377d169ad795be20fbfcd58475a62341ed8fb74d4788c
              $ jq . index.json
              {
+  x blobs/sha256.ea8e5b44cd1aff1f3d9377d169ad795be20fbfcd58475a62341ed8fb74d4788c
              $ jq . index.json
              {
   "schemaVersion": 2,
   "mediaType": "application/vnd.oci.image.index.v1+json",
   "manifests": [
@@ -80,7 +80,7 @@
 }
              Download with Download Handlers
              To use a format more suitable for the content technology, enable the usage
 of download handlers.
              If a download handler is available for the artifact type and the
 blob media type used to store the blob in the OCM repository, it will convert the blob format
-into a more suitable format:
              ocm download resource -d ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 chart -O helmchart.tgz
                helmchart.tgz: 3763 byte(s) written
              What happened?
              The downloaded archive is now a regular Helm Chart archive:
              tar tvf helmchart.tgz
                -rw-r--r--  0 0      0         136 Jul 19 16:32 echoserver/Chart.yaml
+into a more suitable format:
              ocm download resource -d ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 chart -O helmchart.tgz
                helmchart.tgz: 3763 byte(s) written
              What happened?
              The downloaded archive is now a regular Helm Chart archive:
              tar tvf helmchart.tgz
                -rw-r--r--  0 0      0         136 Jul 19 16:32 echoserver/Chart.yaml
   -rw-r--r--  0 0      0        1842 Jul 19 16:32 echoserver/values.yaml
   -rw-r--r--  0 0      0        1755 Jul 19 16:32 echoserver/templates/NOTES.txt
   -rw-r--r--  0 0      0        1802 Jul 19 16:32 echoserver/templates/_helpers.tpl
@@ -90,7 +90,7 @@
   -rw-r--r--  0 0      0         367 Jul 19 16:32 echoserver/templates/service.yaml
   -rw-r--r--  0 0      0         324 Jul 19 16:32 echoserver/templates/serviceaccount.yaml
   -rw-r--r--  0 0      0         385 Jul 19 16:32 echoserver/templates/tests/test-connection.yaml
-  -rw-r--r--  0 0      0         349 Jul 19 16:32 echoserver/.helmignore
              Download an Image
              For example, for OCI images, the OCI format is more suitable:
              ocm download resource ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 image -O image.tgz
                image.tgz: 46181313 byte(s) written
              What happened?
              The file image.tgz was downloaded.
              tar xvf image.tgz
                x index.json
+  -rw-r--r--  0 0      0         349 Jul 19 16:32 echoserver/.helmignore
              Download an Image
              For example, for OCI images, the OCI format is more suitable:
              ocm download resource ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 image -O image.tgz
                image.tgz: 46181313 byte(s) written
              What happened?
              The file image.tgz was downloaded.
              tar xvf image.tgz
                x index.json
   x oci-layout
   x blobs
   x blobs/sha256.06679f57dba70a6875e4ae5843ba2483ecab6ec48182ca8720ddc5b1863bad52
@@ -104,7 +104,7 @@
   x blobs/sha256.bc391bffe5907b0eaa04e96fd638784f77d39f1feb7fbe438a1dae0af2675205
   x blobs/sha256.cb5c1bddd1b5665e1867a7fa1b5fa843a47ee433bbb75d4293888b71def53229
   x blobs/sha256.d5157969118932d522396fe278eb722551751c7aa7473e6d3f03e821a74ee8ec
-  x blobs/sha256.e0962580d8254d0b1ef35006d7e2319eb4870e63dc1f9573d2406c7c47d442d2
              jq . index.json
              {
+  x blobs/sha256.e0962580d8254d0b1ef35006d7e2319eb4870e63dc1f9573d2406c7c47d442d2
              jq . index.json
              {
   "schemaVersion": 2,
   "mediaType": "application/vnd.oci.image.index.v1+json",
   "manifests": [
@@ -123,7 +123,7 @@
   }
 }
              Download an Executable
              The Open Component Model allows to publish platform-specific executables. In this case, the platform
 specification is used by convention as extra identity for the artifacts that are contained in the component
-version.
              Example:
              ocm get componentversion ghcr.io/open-component-model/ocm//ocm.software/ocmcli:0.1.0-dev -o yaml
              ...
+version.
              Example:
              ocm get componentversion ghcr.io/open-component-model/ocm//ocm.software/ocmcli:0.1.0-dev -o yaml
              ...
     resources:
     - name: ocmcli
       extraIdentity:
@@ -150,16 +150,16 @@
 ...
              Note that the resources shown above have the same name and type executable but a different extra-identity. If a
 component version complies to this convention, executables can directly be downloaded for the specified
 platform with the use of the -x option. If only one executable is contained in the component version, the
-resource name can be omitted. Example:
              ocm download resource -x --latest ghcr.io/open-component-model/ocm//ocm.software/ocmcli
                ocm: 83369938 byte(s) written
              What happened?
              file ocm
                ocm: Mach-O 64-bit executable arm64
              With the option --latest, the latest matching component version is used for download. With the
+resource name can be omitted. Example:
              ocm download resource -x --latest ghcr.io/open-component-model/ocm//ocm.software/ocmcli
                ocm: 83369938 byte(s) written
              What happened?
              file ocm
                ocm: Mach-O 64-bit executable arm64
              With the option --latest, the latest matching component version is used for download. With the
 option --constraints, version constraints can be configured. For example: --constraints 0.1.x
 will select all patch versions of 0.1. Together with --latest, the latest patch version is
 selected.
              The option -x enables the executable download handler, which provides the x-bit of the downloaded
-files. Additionally, it filters all matching resources for executables and the correct platform.
              Download a Full Component Version
              Download entire component versions using the ocm download componentversion command:
              ocm download componentversions ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 -O helloworld
                helloworld: downloaded
              The result is a CTF archive. This can then be modified using the ocm add ... commands shown earlier.
              What happened?
              The component version was downloaded.
              tree helloworld
                helloworld/
+files. Additionally, it filters all matching resources for executables and the correct platform.
              Download a Full Component Version
              Download entire component versions using the ocm download componentversion command:
              ocm download componentversions ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 -O helloworld
                helloworld: downloaded
              The result is a CTF archive. This can then be modified using the ocm add ... commands shown earlier.
              What happened?
              The component version was downloaded.
              tree helloworld
                helloworld/
   ├── blobs
   │   ├── sha256.87cef1e2233bf5591030ac854e2556fbe6a00a28bb5640e25a9cb69ece519c5a
   │   ├── sha256.8a2fe6af4ce56249094622c9d618e24b4cfb461a7dfa6a42cce31749189bc499
   │   └── sha256.e790920a11de2016de64225280efcf062e14b767955f7508de64fd5192e3fb3a
-  └── component-descriptor.yaml
              Download OCI Artifacts
              Download OCI artifacts from an OCI registry, such as OCI images, with the ocm download artifacts command:
              ocm download artifact ghcr.io/open-component-model/ocm-controller:v0.24.0 -O ocm-controller
                ocm-controller: downloaded
              What happened?
              The OCI image echoserver was downloaded.
              tree echoserver
                ocm-controller/
+  └── component-descriptor.yaml
              Download OCI Artifacts
              Download OCI artifacts from an OCI registry, such as OCI images, with the ocm download artifacts command:
              ocm download artifact ghcr.io/open-component-model/ocm-controller:v0.24.0 -O ocm-controller
                ocm-controller: downloaded
              What happened?
              The OCI image echoserver was downloaded.
              tree echoserver
                ocm-controller/
   ├── blobs
   │   ├── sha256.05d57e68048827c243cd477025f96064df9f4d83b8639ed04306f0647c9cfe78
   │   ├── sha256.0f8b424aa0b96c1c388a5fd4d90735604459256336853082afb61733438872b5
diff --git a/docs/getting-started/getting-started-with-ocm/index.html b/docs/getting-started/getting-started-with-ocm/index.html
index 01eed282..a7485ed8 100644
--- a/docs/getting-started/getting-started-with-ocm/index.html
+++ b/docs/getting-started/getting-started-with-ocm/index.html
@@ -3,5 +3,5 @@
 
-
              Docs
              First Steps with OCM
              
\ No newline at end of file
+
              Docs
              First Steps with OCM
              
\ No newline at end of file
diff --git a/docs/getting-started/getting-started-with-ocm/index.xml b/docs/getting-started/getting-started-with-ocm/index.xml
index 4edc9640..b761ca33 100644
--- a/docs/getting-started/getting-started-with-ocm/index.xml
+++ b/docs/getting-started/getting-started-with-ocm/index.xml
@@ -1,6 +1,6 @@
 First Steps with OCM on Open Component Modelhttps://ocm.software/docs/getting-started/getting-started-with-ocm/Recent content in First Steps with OCM on Open Component ModelHugoen© Copyright 2024, SAP SE and Open Component Model ContributorsMon, 13 Mar 2023 09:38:41 +0100Prerequisiteshttps://ocm.software/docs/getting-started/getting-started-with-ocm/prerequisites/Mon, 13 Mar 2023 09:38:41 +0100https://ocm.software/docs/getting-started/getting-started-with-ocm/prerequisites/<p>This and the following chapters walk you through some basic steps to get started with OCM concepts and the OCM CLI.
 You will learn how to create a component version, display and examine the component, and how to transport and sign it.</p>Create a Component Versionhttps://ocm.software/docs/getting-started/getting-started-with-ocm/create-a-component-version/Mon, 13 Mar 2023 09:38:41 +0100https://ocm.software/docs/getting-started/getting-started-with-ocm/create-a-component-version/<h2 id="creating-and-storing-component-versions">Creating and Storing Component Versions</h2>
-<p>Component Versions are created using a <code>component-constructor.yaml</code> 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.</p>Display and Examine Component Versionshttps://ocm.software/docs/getting-started/getting-started-with-ocm/display-and-examine-component-versions/Mon, 13 Mar 2023 09:38:41 +0100https://ocm.software/docs/getting-started/getting-started-with-ocm/display-and-examine-component-versions/<h2 id="list-component-versions">List Component Versions</h2>
+<p>Component Versions are created using a <code>component-constructor.yaml</code> 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.</p>Display and Examine Component Versionshttps://ocm.software/docs/getting-started/getting-started-with-ocm/display-and-examine-component-versions/Mon, 13 Mar 2023 09:38:41 +0100https://ocm.software/docs/getting-started/getting-started-with-ocm/display-and-examine-component-versions/<h2 id="list-component-versions">List Component Versions</h2>
 <p>To show a component stored in an OCM repository or CTF archive (which itself is an OCM repository), the <a href="https://github.com/open-component-model/ocm/blob/main/docs/reference/ocm_get_componentversions.md"><code>ocm get componentversion</code></a> command can be used:</p>Transport OCM Component Versionshttps://ocm.software/docs/getting-started/getting-started-with-ocm/transport-ocm-component-versions/Mon, 13 Mar 2023 09:38:41 +0100https://ocm.software/docs/getting-started/getting-started-with-ocm/transport-ocm-component-versions/<p>The section <a href="https://ocm.software/docs/getting-started/getting-started-with-ocm/create-a-component-version#bundle-composed-components">Bundle Composed Components</a> explained how to bundle multiple component version into a transport archive.</p>
 <p>During the transfer, it is possible to include component references as local blobs. It is also possible to include references in a recursive way.</p>Sign Component Versionshttps://ocm.software/docs/getting-started/getting-started-with-ocm/sign-component-versions/Mon, 13 Mar 2023 09:38:41 +0100https://ocm.software/docs/getting-started/getting-started-with-ocm/sign-component-versions/<p>Component versions can be signed to ensure integrity along a transport chain.</p>
 <p>Signing requires a key pair, a signature, and, optionally, an issuer, as well as an algorithm and a
diff --git a/docs/getting-started/getting-started-with-ocm/prerequisites/index.html b/docs/getting-started/getting-started-with-ocm/prerequisites/index.html
index 391e7b37..49e69638 100644
--- a/docs/getting-started/getting-started-with-ocm/prerequisites/index.html
+++ b/docs/getting-started/getting-started-with-ocm/prerequisites/index.html
@@ -3,8 +3,8 @@
 
-
              Docs
              Prerequisites
              This and the following chapters walk you through some basic steps to get started with OCM concepts and the OCM CLI.
+
              Docs
              Prerequisites
              This and the following chapters walk you through some basic steps to get started with OCM concepts and the OCM CLI.
 You will learn how to create a component version, display and examine the component, and how to transport and sign it.
              To follow the steps described in this section, you will need to:
              Install the OCM Command Line Interface (CLI)
              The CLI is used to interact with component versions and registries. Install it like described in Installing the OCM CLI.
              Obtain Access to an OCM Repository
              This can be any OCI registry for which you have write permission (e.g., GitHub Packages). An OCM repository based on an OCI registry is identified by a leading OCI repository prefix. For example: ghcr.io/<YOUR-ORG>/ocm.
              Obtain Credentials for the CLI to Access the OCM Repository
              Using the Docker Configuration File
              The easiest way to do this is to reuse your Docker configuration json file.
              To do this, create a file named .ocmconfig in your home directory with the following content:
              type: generic.config.ocm.software/v1
 configurations:
 - type: credentials.config.ocm.software
diff --git a/docs/getting-started/getting-started-with-ocm/sign-component-versions/index.html b/docs/getting-started/getting-started-with-ocm/sign-component-versions/index.html
index 8a97a5e5..2224a2b5 100644
--- a/docs/getting-started/getting-started-with-ocm/sign-component-versions/index.html
+++ b/docs/getting-started/getting-started-with-ocm/sign-component-versions/index.html
@@ -5,8 +5,8 @@
 
-
              Docs
              Sign Component Versions
              Component versions can be signed to ensure integrity along a transport chain.
              Signing requires a key pair, a signature, and, optionally, an issuer, as well as an algorithm and a
+
              Docs
              Sign Component Versions
              Component versions can be signed to ensure integrity along a transport chain.
              Signing requires a key pair, a signature, and, optionally, an issuer, as well as an algorithm and a
 name for the signature.
              A component version can have multiple signatures with different names. A normalization of the
 component version is used for signing. See Signing Process and Normalization for more details.
 Currently, only signing according to the
diff --git a/docs/getting-started/getting-started-with-ocm/transport-ocm-component-versions/index.html b/docs/getting-started/getting-started-with-ocm/transport-ocm-component-versions/index.html
index c88eb3dc..6d366757 100644
--- a/docs/getting-started/getting-started-with-ocm/transport-ocm-component-versions/index.html
+++ b/docs/getting-started/getting-started-with-ocm/transport-ocm-component-versions/index.html
@@ -5,8 +5,8 @@
 
-
              Docs
              Transport OCM Component Versions
              The section Bundle Composed Components explained how to bundle multiple component version into a transport archive.
              During the transfer, it is possible to include component references as local blobs. It is also possible to include references in a recursive way.
              Here is an example of a recursive transfer from one OCI registry to another, which includes resources and references:
              ocm transfer componentversion --recursive --copy-resources ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 another-registry/
                transferring version "ocm.software/toi/demo/helmdemo:0.12.0"...
+
              Docs
              Transport OCM Component Versions
              The section Bundle Composed Components explained how to bundle multiple component version into a transport archive.
              During the transfer, it is possible to include component references as local blobs. It is also possible to include references in a recursive way.
              Here is an example of a recursive transfer from one OCI registry to another, which includes resources and references:
              ocm transfer componentversion --recursive --copy-resources ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 another-registry/
                transferring version "ocm.software/toi/demo/helmdemo:0.12.0"...
     transferring version "ocm.software/toi/installers/helminstaller:0.12.0"...
     ...resource 0 toiimage[ociImage](ocm.software/toi/installers/helminstaller/helminstaller:0.12.0)...
     ...resource 1 toiexecutor[toiExecutor]...
diff --git a/docs/getting-started/index.html b/docs/getting-started/index.html
index 8cd45dab..1f8f498d 100644
--- a/docs/getting-started/index.html
+++ b/docs/getting-started/index.html
@@ -3,5 +3,5 @@
 
-
              Docs
              Getting Started
              
\ No newline at end of file
+
              Docs
              Getting Started
              
\ No newline at end of file
diff --git a/docs/getting-started/installing-the-ocm-cli/index.html b/docs/getting-started/installing-the-ocm-cli/index.html
index 2a6ce45c..4921b9ab 100644
--- a/docs/getting-started/installing-the-ocm-cli/index.html
+++ b/docs/getting-started/installing-the-ocm-cli/index.html
@@ -3,8 +3,8 @@
 
-
              Docs
              Installing the OCM CLI
              Overview
              You can install the latest release of the OCM CLI from any of the following sources (more details below):
              Bash
              To install with bash for macOS or Linux, execute the following command:
              curl -s https://ocm.software/install.sh | sudo bash
              Install using Homebrew
              # Homebrew (macOS and Linux)
+
              Docs
              Installing the OCM CLI
              Overview
              You can install the latest release of the OCM CLI from any of the following sources (more details below):
              Bash
              To install with bash for macOS or Linux, execute the following command:
              curl -s https://ocm.software/install.sh | sudo bash
              Install using Homebrew
              # Homebrew (macOS and Linux)
 brew install open-component-model/tap/ocm
              Install using Nix (with Flakes)
              # Nix (macOS, Linux, and Windows)
 # ad hoc cmd execution
 nix run github:open-component-model/ocm -- --help
diff --git a/docs/index.html b/docs/index.html
index 8bf0c6a3..b1d0c3ce 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -3,5 +3,5 @@
 
-
              Docs
              Docs
              
\ No newline at end of file
+
              Docs
              Docs
              
\ No newline at end of file
diff --git a/docs/overview/about/index.html b/docs/overview/about/index.html
index 982c613a..c971f55a 100644
--- a/docs/overview/about/index.html
+++ b/docs/overview/about/index.html
@@ -3,5 +3,5 @@
 
-
              Docs
              About the OCM Project
              The Open Component Model (OCM) project provides an open standard for describing software artifacts and lifecycle metadata, with the purpose to securely deliver and deploy software products. It facilitates asynchronous handling of various lifecycle management processes, such as compliance checks, security scans, deployments, and more, in a decoupled and streamlined manner. OCM provides the ability to deliver software securely, consistently, and compliantly across cloud, on-prem, hybrid and air-gapped environments.
              OCM use cases
              Below are the main projects, but please also check out the others in our Github org.
              • OCM Specification - The ocm-spec repository contains the OCM specification, which provides a formal description of OCM and its format to describe software artifacts and a storage layer to persist those and make them accessible from remote.
              • OCM Core Library - The ocm core library contains an API for interacting with OCM elements. A guided tour on how to work with the library can be found here.
              • OCM CLI - With the ocm command line interface end users can interact with OCM elements, helping them create component versions and embed them in CI and CD processes. Examples can be found in this Makefile.
              • OCM Controller - The ocm-controllers are designed to enable the automated deployment of software using the Open Component Model and Flux.
              • OCM Website - The ocm-website you are currently visiting. It is built using Hugo and hosted on Github Pages.
              Prev
              Version 3
              Next
              Benefits of OCM
              
\ No newline at end of file
+
              Docs
              About the OCM Project
              The Open Component Model (OCM) project provides an open standard for describing software artifacts and lifecycle metadata, with the purpose to securely deliver and deploy software products. It facilitates asynchronous handling of various lifecycle management processes, such as compliance checks, security scans, deployments, and more, in a decoupled and streamlined manner. OCM provides the ability to deliver software securely, consistently, and compliantly across cloud, on-prem, hybrid and air-gapped environments.
              OCM use cases
              Below are the main projects, but please also check out the others in our Github org.
              • OCM Specification - The ocm-spec repository contains the OCM specification, which provides a formal description of OCM and its format to describe software artifacts and a storage layer to persist those and make them accessible from remote.
              • OCM Core Library - The ocm core library contains an API for interacting with OCM elements. A guided tour on how to work with the library can be found here.
              • OCM CLI - With the ocm command line interface end users can interact with OCM elements, helping them create component versions and embed them in CI and CD processes. Examples can be found in this Makefile.
              • OCM Controller - The ocm-controllers are designed to enable the automated deployment of software using the Open Component Model and Flux.
              • OCM Website - The ocm-website you are currently visiting. It is built using Hugo and hosted on Github Pages.
              Prev
              Version 2
              Next
              Benefits of OCM
              
\ No newline at end of file
diff --git a/docs/overview/benefits-of-ocm/index.html b/docs/overview/benefits-of-ocm/index.html
index 7f467ac4..64830be6 100644
--- a/docs/overview/benefits-of-ocm/index.html
+++ b/docs/overview/benefits-of-ocm/index.html
@@ -3,5 +3,5 @@
 
-
              Docs
              Benefits of OCM
              In today’s cloud era, enterprises still grapple with tools and processes rooted in outdated on-premises and monolithic thinking. Ad-hoc, fragmented toolsets are used across software lifecycle processes, severely impacting the ability to deliver software securely, consistently, and compliantly across cloud, on-prem, hybrid and air-gapped environments.
              Overly complex, bespoke CI/CD pipelines and the lack of automation across the whole lifecyle process create a tedious, error-prone, and ineffective approach to managing software at scale. This operational nightmare is compounded by the absence of a standardized way to describe software components and their associated technical artifacts.
              Requirements Towards a Modern Software Component Model
              Immutable and Unique Component Identity
              A crucial requirement is the ability to assign an immutable and globally unique Component Identity to each software component. This identifier acts as a “correlation ID,” allowing all lifecycle management processes, such as security compliance and vulnerability scanning, to correlate their outputs to a single, identifiable software component.
              Artifact Descriptions with Location Information
              The model should facilitate the description of all technical artifacts required for deploying a specific version of a software component. This list, termed a “Software Bill of Delivery” (SBoD), outlines only the artifacts needed for successful deployment. Additionally, the description must encompass the technical access location from which each artifact can be retrieved.
              Separation of Component Identity and Artifact Location
              In certain environments, artifacts are required to be stored in local registries, mandating the copying of technical artifacts into these target environments. This is especially true for private or air-gapped scenarios where retrieving artifacts from their original location is not feasible due to restricted or non-existent internet access or compliance reasons. To address this, the model must enable the separation of a software component’s immutable ID from the current location of its technical artifacts. The Component Identity must remain stable across all boundaries and system environments, while the artifact locations should be changeable.
              Technology-Agnostic
              At its core, the model must be technology-agnostic, capable of supporting not only modern containerized cloud products but also legacy software. Many larger companies operate hybrid landscapes comprising modern cloud-native products running on cloud infrastructures and legacy applications that have not yet transitioned (or may never transition) to the public cloud or be containerized. To cater to such scenarios, it is crucial for the software component model to handle both cloud-native and legacy software, necessitating complete agnosticism regarding the technologies used by the described software components and their artifacts.
              Extensibility
              The model should be designed with extensibility in mind, enabling straightforward adaptation to future trends and technologies without constantly impacting the tools and processes employed for software lifecycle management.
              Signing
              The model should provide out-of-the-box support for signing and verification processes. This capability allows consumers of software components to verify that the delivered components have not been tampered with. Importantly, the signing and verification support must account for the possibility that the technical artifact locations may change over time, implying that these specific locations should not be part of the signing process.
              Network Effects
              Components described using OCM are primed for secure consumption and immediate integration into higher-level components (or products). The ability to link to trusted and already attested components can facilitate adoption across different teams within an organization, directly improving efficiency (akin to the proficiency of package models like Maven or npm). Moreover, with other parties also describing components using OCM, commercial contracts can cover the necessary technical trust outside the organization, simplifying the secure import and compliant re-use of these components. OCM envisions fostering a network effect across the industry.
              OCM: Streamlining Software Lifecycle Management
              The Open Component Model (OCM) is the much-needed life-raft for organizations drowning in software lifecycle management complexity. By establishing a standardized way to describe software components and their artifacts, OCM tackles the core issues plaguing enterprises. By linking additional metadata using OCM’s identities, it facilitates asynchronous handling of various lifecycle management processes, such as compliance checks, security scans, deployments, and more, in a decoupled and streamlined manner.
              OCM as Enabler for asynchronous Lifecycle Management Processes
              • Unique Component Identities: OCM assigns an immutable, globally unique ID to each component, enabling seamless correlation across all lifecycle tools and processes like a “compliance dashboard”.
              • Software Bill of Delivery: OCM enables the precise specification of all technical artifacts required for delivering a software component. This compilation, termed a “Software Bill of Delivery” (SBoD), comprehensively lists the necessary artifacts along with their corresponding location information to facilitate seamless access.
              • Stable IDs, Changing Artifact Locations: OCM cleanly separates the immutable component ID from the changeable artifact locations, essential for hybrid/private environments.
              • Technology Agnosticism: Being agnostic to implementation technologies like container images, NPM packages or binaries, OCM effortlessly handles both cloud-native and legacy apps.
              • Future-Proof Extensibility: OCM’s extensible design allows simple adaptation to emerging trends without disrupting existing tooling.
              • Trusted Signatures: Built-in signing and verification ensure artifact integrity even as artifact locations change over time.
              With OCM, a “single source of truth” is established for all software artifacts across the lifecycle. Compliance checks, security scans, deployments, and more become streamlined operations anchored to OCM’s standardized component definitions.
              Moreover, by fostering component reuse within and across organizations, OCM unlocks powerful network effects akin to package managers, boosting productivity, and simplifying commercial software consumption.
              In essence, OCM is the missing link that finally empowers organizations to tame the software lifecycle beast through a consistent, location-agnostic way to identify, access, exchange and verify software artifacts at scale.
              Prev
              About the OCM Project
              Next
              Important Terms
              
\ No newline at end of file
+
              Docs
              Benefits of OCM
              In today’s cloud era, enterprises still grapple with tools and processes rooted in outdated on-premises and monolithic thinking. Ad-hoc, fragmented toolsets are used across software lifecycle processes, severely impacting the ability to deliver software securely, consistently, and compliantly across cloud, on-prem, hybrid and air-gapped environments.
              Overly complex, bespoke CI/CD pipelines and the lack of automation across the whole lifecyle process create a tedious, error-prone, and ineffective approach to managing software at scale. This operational nightmare is compounded by the absence of a standardized way to describe software components and their associated technical artifacts.
              Requirements Towards a Modern Software Component Model
              Immutable and Unique Component Identity
              A crucial requirement is the ability to assign an immutable and globally unique Component Identity to each software component. This identifier acts as a “correlation ID,” allowing all lifecycle management processes, such as security compliance and vulnerability scanning, to correlate their outputs to a single, identifiable software component.
              Artifact Descriptions with Location Information
              The model should facilitate the description of all technical artifacts required for deploying a specific version of a software component. This list, termed a “Software Bill of Delivery” (SBoD), outlines only the artifacts needed for successful deployment. Additionally, the description must encompass the technical access location from which each artifact can be retrieved.
              Separation of Component Identity and Artifact Location
              In certain environments, artifacts are required to be stored in local registries, mandating the copying of technical artifacts into these target environments. This is especially true for private or air-gapped scenarios where retrieving artifacts from their original location is not feasible due to restricted or non-existent internet access or compliance reasons. To address this, the model must enable the separation of a software component’s immutable ID from the current location of its technical artifacts. The Component Identity must remain stable across all boundaries and system environments, while the artifact locations should be changeable.
              Technology-Agnostic
              At its core, the model must be technology-agnostic, capable of supporting not only modern containerized cloud products but also legacy software. Many larger companies operate hybrid landscapes comprising modern cloud-native products running on cloud infrastructures and legacy applications that have not yet transitioned (or may never transition) to the public cloud or be containerized. To cater to such scenarios, it is crucial for the software component model to handle both cloud-native and legacy software, necessitating complete agnosticism regarding the technologies used by the described software components and their artifacts.
              Extensibility
              The model should be designed with extensibility in mind, enabling straightforward adaptation to future trends and technologies without constantly impacting the tools and processes employed for software lifecycle management.
              Signing
              The model should provide out-of-the-box support for signing and verification processes. This capability allows consumers of software components to verify that the delivered components have not been tampered with. Importantly, the signing and verification support must account for the possibility that the technical artifact locations may change over time, implying that these specific locations should not be part of the signing process.
              Network Effects
              Components described using OCM are primed for secure consumption and immediate integration into higher-level components (or products). The ability to link to trusted and already attested components can facilitate adoption across different teams within an organization, directly improving efficiency (akin to the proficiency of package models like Maven or npm). Moreover, with other parties also describing components using OCM, commercial contracts can cover the necessary technical trust outside the organization, simplifying the secure import and compliant re-use of these components. OCM envisions fostering a network effect across the industry.
              OCM: Streamlining Software Lifecycle Management
              The Open Component Model (OCM) is the much-needed life-raft for organizations drowning in software lifecycle management complexity. By establishing a standardized way to describe software components and their artifacts, OCM tackles the core issues plaguing enterprises. By linking additional metadata using OCM’s identities, it facilitates asynchronous handling of various lifecycle management processes, such as compliance checks, security scans, deployments, and more, in a decoupled and streamlined manner.
              OCM as Enabler for asynchronous Lifecycle Management Processes
              • Unique Component Identities: OCM assigns an immutable, globally unique ID to each component, enabling seamless correlation across all lifecycle tools and processes like a “compliance dashboard”.
              • Software Bill of Delivery: OCM enables the precise specification of all technical artifacts required for delivering a software component. This compilation, termed a “Software Bill of Delivery” (SBoD), comprehensively lists the necessary artifacts along with their corresponding location information to facilitate seamless access.
              • Stable IDs, Changing Artifact Locations: OCM cleanly separates the immutable component ID from the changeable artifact locations, essential for hybrid/private environments.
              • Technology Agnosticism: Being agnostic to implementation technologies like container images, NPM packages or binaries, OCM effortlessly handles both cloud-native and legacy apps.
              • Future-Proof Extensibility: OCM’s extensible design allows simple adaptation to emerging trends without disrupting existing tooling.
              • Trusted Signatures: Built-in signing and verification ensure artifact integrity even as artifact locations change over time.
              With OCM, a “single source of truth” is established for all software artifacts across the lifecycle. Compliance checks, security scans, deployments, and more become streamlined operations anchored to OCM’s standardized component definitions.
              Moreover, by fostering component reuse within and across organizations, OCM unlocks powerful network effects akin to package managers, boosting productivity, and simplifying commercial software consumption.
              In essence, OCM is the missing link that finally empowers organizations to tame the software lifecycle beast through a consistent, location-agnostic way to identify, access, exchange and verify software artifacts at scale.
              Prev
              About the OCM Project
              Next
              Important Terms
              
\ No newline at end of file
diff --git a/docs/overview/important-terms/index.html b/docs/overview/important-terms/index.html
index 472fa6e6..c4806624 100644
--- a/docs/overview/important-terms/index.html
+++ b/docs/overview/important-terms/index.html
@@ -3,5 +3,5 @@
 
-
              Docs
              Important Terms
              As the Open Component Model (OCM) revolves around components, it is essential to establish a common understanding of the fundamental terminology employed throughout this website. The following section provides concise definitions of key terms, laying the groundwork for the documentation and tutorials that follow.
              For a comprehensive exploration of every aspect of this topic, please refer to the OCM Specification OCM Specification and its Glossary.
              Components in OCM
              The concept of a Component can vary widely, often defined with very specific views on granularity or other technical attributes. OCM takes a different approach, focusing on the intended purpose and overall meaning of components.
              In OCM, Components group a set of semantically related Component Versions. Each Component Version is uniquely and globally identified by a Component Identity and can reference other Components. A Component Version can also contain Artifacts and a formal description on how to access them. These Artifacts come in two categories: resources, which describe the payload (e.g.,OCI images), and sources, which describe the input for creating resources (e.g., source code).
              OCM Coordinates
              OCM Coordinates are used to reference OCM Component Versions and Artifacts within OCM Component Versions. Coordinates referring to an OCM Component Version are also called Component Identity, whereas relative Coordinates referring to an artifact are called Artifact Identity. Component Identities are globally unique and may be used to refer to full Component Versions. Artifact Identities are always relative to a Component Version and may only be used in conjunction with a Component Identity.
              In detail:
              Component Identity
              • Component Name: Identifies a component. Must start with URL-prefix that should be controlled by the owner of the component to avoid collisions.
              • Component Version: If used with a Component name, identifies a specific Component Version. Must adhere to “relaxed SemVer” (major, minor (+ optional patch level) - optional v-prefix).
              Artifact Identity
              Within a Component Version, all Artifacts must have a unique identity. Every Source Identity or Resource Identity always includes a name that typically expresses the intended purpose.
              Artifacts may also have additional extraIdentity attributes that contribute to their identities. extraIdentity attributes are string-to-string maps.
              Examples
              Assuming there is a component named example.org/my-component with two versions, 1.2.3 and 1.3.0, declaring a resource with the name my-resource, the following OCM Coordinates can be used to reference different elements:
              • example.org/my-component: all versions of the component (1.2.3 + 1.3.0)
              • example.org/my-component:1.2.3: version 1.2.3 of the component
              • example.org/my-component:1.2.3:resource/my-resource: my-resource as declared by the component version
              Prev
              Benefits of OCM
              Next
              Specification
              
\ No newline at end of file
+
              Docs
              Important Terms
              As the Open Component Model (OCM) revolves around components, it is essential to establish a common understanding of the fundamental terminology employed throughout this website. The following section provides concise definitions of key terms, laying the groundwork for the documentation and tutorials that follow.
              For a comprehensive exploration of every aspect of this topic, please refer to the OCM Specification OCM Specification and its Glossary.
              Components in OCM
              The concept of a Component can vary widely, often defined with very specific views on granularity or other technical attributes. OCM takes a different approach, focusing on the intended purpose and overall meaning of components.
              In OCM, Components group a set of semantically related Component Versions. Each Component Version is uniquely and globally identified by a Component Identity and can reference other Components. A Component Version can also contain Artifacts and a formal description on how to access them. These Artifacts come in two categories: resources, which describe the payload (e.g.,OCI images), and sources, which describe the input for creating resources (e.g., source code).
              OCM Coordinates
              OCM Coordinates are used to reference OCM Component Versions and Artifacts within OCM Component Versions. Coordinates referring to an OCM Component Version are also called Component Identity, whereas relative Coordinates referring to an artifact are called Artifact Identity. Component Identities are globally unique and may be used to refer to full Component Versions. Artifact Identities are always relative to a Component Version and may only be used in conjunction with a Component Identity.
              In detail:
              Component Identity
              • Component Name: Identifies a component. Must start with URL-prefix that should be controlled by the owner of the component to avoid collisions.
              • Component Version: If used with a Component name, identifies a specific Component Version. Must adhere to “relaxed SemVer” (major, minor (+ optional patch level) - optional v-prefix).
              Artifact Identity
              Within a Component Version, all Artifacts must have a unique identity. Every Source Identity or Resource Identity always includes a name that typically expresses the intended purpose.
              Artifacts may also have additional extraIdentity attributes that contribute to their identities. extraIdentity attributes are string-to-string maps.
              Examples
              Assuming there is a component named example.org/my-component with two versions, 1.2.3 and 1.3.0, declaring a resource with the name my-resource, the following OCM Coordinates can be used to reference different elements:
              • example.org/my-component: all versions of the component (1.2.3 + 1.3.0)
              • example.org/my-component:1.2.3: version 1.2.3 of the component
              • example.org/my-component:1.2.3:resource/my-resource: my-resource as declared by the component version
              Prev
              Benefits of OCM
              Next
              Specification
              
\ No newline at end of file
diff --git a/docs/overview/index.html b/docs/overview/index.html
index b275a024..a19cbce7 100644
--- a/docs/overview/index.html
+++ b/docs/overview/index.html
@@ -3,5 +3,5 @@
 
-
              Docs
              Overview
              
\ No newline at end of file
+
              Docs
              Overview
              
\ No newline at end of file
diff --git a/docs/overview/specification/index.html b/docs/overview/specification/index.html
index bf421681..7ed4fd9a 100644
--- a/docs/overview/specification/index.html
+++ b/docs/overview/specification/index.html
@@ -3,5 +3,5 @@
 
-
              Docs
              Specification
              Where to find the OCM specification
              The most up-to-date version of the OCM specification offers you a deep insight to all technical details of the Open Component Model and explains all elements the model OCM is based on.
              Prev
              Important Terms
              Next
              Installing the OCM CLI
              
\ No newline at end of file
+
              Docs
              Specification
              Where to find the OCM specification
              The most up-to-date version of the OCM specification offers you a deep insight to all technical details of the Open Component Model and explains all elements the model OCM is based on.
              Prev
              Important Terms
              Next
              Installing the OCM CLI
              
\ No newline at end of file
diff --git a/docs/overview/specification/schema-v2.html b/docs/overview/specification/schema-v2.html
index 5807e0ce..eb7646d7 100644
--- a/docs/overview/specification/schema-v2.html
+++ b/docs/overview/specification/schema-v2.html
@@ -8148,6 +8148,6 @@ 
              
 
              
 
     
 
\ No newline at end of file
diff --git a/docs/overview/specification/schema-v3alpha1.html b/docs/overview/specification/schema-v3alpha1.html
deleted file mode 100644
index 27e7bb52..00000000
--- a/docs/overview/specification/schema-v3alpha1.html
+++ /dev/null
@@ -1,7120 +0,0 @@
-
-
-
-
-
-    
-    
-    
-    
-	
-    
-    
-    
-    Schema Docs
-
-
              
-            
-            
-        
              
-
-    
              Type: object
              
-
              OCM Component Descriptor v3 schema
              
-              
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    apiVersion
              Type: enum (of string)
              
-
              
-            
              Must be one of:
              
-            
              • "ocm.gardener.cloud/v3alpha1"
              • "ocm.software/v3alpha1"
              
-            
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    kind
              Type: const
              
-Specific value: "ComponentVersion"
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    metadata
              Type: object
              
-
              component version metadata
              
-              
-
-     No Additional Properties
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    metadata
-        
-            
-        
-    name
              Type: string
              
-
-
-    Must match regular expression: ^[a-z][-a-z0-9]*([.][a-z][-a-z0-9]*)*[.][a-z]{2,}(/[a-z][-a-z0-9_]*([.][a-z][-a-z0-9_]*)*)+$
-        
-
-        
-        
              Must be at most 255 characters long
              
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    metadata
-        
-            
-        
-    version
              Type: string
              
-
-
-    Must match regular expression: ^[v]?(0|[1-9]\d*)(?:\.(0|[1-9]\d*))?(?:\.(0|[1-9]\d*))?(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    metadata
-        
-            
-        
-    labels
              Type: array
              
-
-
-    
-        
-
-        
-        
-
-         No Additional Items
              Each item of this array must be:
              
-    
              
-        
              
-            
-
-    
              root
-        
-            
-        
-    metadata
-        
-            
-        
-    labels
-        
-            
-        
-    label
              Type: object
              
-
-
-     No Additional Properties
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    metadata
-        
-            
-        
-    labels
-        
-            
-        
-    labels items
-        
-            
-        
-    name
              Type: string
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    metadata
-        
-            
-        
-    labels
-        
-            
-        
-    labels items
-        
-            
-        
-    value
              Type: object
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    metadata
-        
-            
-        
-    labels
-        
-            
-        
-    labels items
-        
-            
-        
-    version
              Type: object
              
-Must match regular expression: ^v[0-9]+$
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    metadata
-        
-            
-        
-    labels
-        
-            
-        
-    labels items
-        
-            
-        
-    signature
              Type: boolean
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-        
              
-    
              
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    metadata
-        
-            
-        
-    provider
              Type: object
              
-
-
-     No Additional Properties
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    metadata
-        
-            
-        
-    provider
-        
-            
-        
-    name
              Type: string
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    metadata
-        
-            
-        
-    provider
-        
-            
-        
-    labels
              Type: array
              
-Same definition as labels
-            
              
-        
              
-    
              
-
              
-            
              
-        
              
-    
              
-
              
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    repositoryContexts
              Type: array
              
-
-        
-
-        
-        
-
-         No Additional Items
              Each item of this array must be:
              
-    
              
-        
              
-            
-
-    
              root
-        
-            
-        
-    repositoryContexts
-        
-            
-        
-    repositoryContexts items

              
-
              
-  
-
              
-
              
-            
-
-    
              root
-        
-            
-        
-    repositoryContexts
-        
-            
-        
-    repositoryContexts items
-        
-            
-        
-    anyOf
-        
-            
-        
-    ociRepositoryContext
              Type: object
              
-
-
-    
              
-  
-
              
-
              
-            
-
-    
              root
-        
-            
-        
-    repositoryContexts
-        
-            
-        
-    repositoryContexts items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    allOf
-        
-            
-        
-    repositoryContext
              Type: object
              
-
-
-    
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    repositoryContexts
-        
-            
-        
-    repositoryContexts items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    allOf
-        
-            
-        
-    item 0
-        
-            
-        
-    type
              Type: string
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-        
              
-            
-
-    
              root
-        
-            
-        
-    repositoryContexts
-        
-            
-        
-    repositoryContexts items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    allOf
-        
-            
-        
-    item 1
              Type: object
              
-
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    repositoryContexts
-        
-            
-        
-    repositoryContexts items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    allOf
-        
-            
-        
-    item 1
-        
-            
-        
-    baseUrl
              Type: string
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    repositoryContexts
-        
-            
-        
-    repositoryContexts items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    allOf
-        
-            
-        
-    item 1
-        
-            
-        
-    componentNameMapping
              Type: enum (of string)
              
-
              
-            
              Must be one of:
              
-            
              • "urlPath"
              • "sha256-digest"
              
-            
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    repositoryContexts
-        
-            
-        
-    repositoryContexts items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    allOf
-        
-            
-        
-    item 1
-        
-            
-        
-    type
              Type: enum (of string)
              
-
              
-            
              Must be one of:
              
-            
              • "ociRegistry"
              • "OCIRegistry"
              
-            
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-        
              
-        
-
-        
-        
-
-        
-        
              
-        
-
-        
-        
-
-        
-        
              
-    
              
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
              Type: object
              
-
              specification of the content of a component versiont
              
-              
-
-     No Additional Properties
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    sources
              Type: array
              
-
-        
-
-        
-        
-
-         No Additional Items
              Each item of this array must be:
              
-    
              
-        
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    sources
-        
-            
-        
-    sourceDefinition
              Type: object
              
-
-
-    
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    sources
-        
-            
-        
-    sources items
-        
-            
-        
-    name
              Type: string
              
-
-
-    Must match regular expression: ^[a-z0-9]([-_+a-z0-9]*[a-z0-9])?$
-        
-
-        
-        
              Must be at least 2 characters long
              
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    sources
-        
-            
-        
-    sources items
-        
-            
-        
-    extraIdentity
              Type: object
              
-
-
-    
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    sources
-        
-            
-        
-    sources items
-        
-            
-        
-    version
              Type: string
              
-Same definition as version
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    sources
-        
-            
-        
-    sources items
-        
-            
-        
-    type
              Type: string
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    sources
-        
-            
-        
-    sources items
-        
-            
-        
-    labels
              Type: array
              
-Same definition as labels
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    sources
-        
-            
-        
-    sources items
-        
-            
-        
-    access

              
-
              
-  
-
              
-
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    sources
-        
-            
-        
-    sources items
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    access
              Type: object
              
-
              base type for accesses (for extensions)
              
-              
-
-    
-        
              
-    
              The following properties are required:
              
-    
              • type
              
-    
              
-
-        
-        
-
-        
-        
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    sources
-        
-            
-        
-    sources items
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    githubAccess
              Type: object
              
-
-
-    
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    sources
-        
-            
-        
-    sources items
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    type
              Type: enum (of string)
              
-
              
-            
              Must be one of:
              
-            
              • "github"
              
-            
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    sources
-        
-            
-        
-    sources items
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    repoUrl
              Type: string
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    sources
-        
-            
-        
-    sources items
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    ref
              Type: string
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    sources
-        
-            
-        
-    sources items
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    commit
              Type: string
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-        
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    sources
-        
-            
-        
-    sources items
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    httpAccess
              Type: object
              
-
-
-    
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    sources
-        
-            
-        
-    sources items
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 2
-        
-            
-        
-    type
              Type: enum (of string)
              
-
              
-            
              Must be one of:
              
-            
              • "http"
              
-            
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    sources
-        
-            
-        
-    sources items
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 2
-        
-            
-        
-    url
              Type: string
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-        
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-        
              
-    
              
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    references
              Type: array
              
-
-        
-
-        
-        
-
-         No Additional Items
              Each item of this array must be:
              
-    
              
-        
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    references
-        
-            
-        
-    reference
              Type: object
              
-
              a reference to a component
              
-              
-
-     No Additional Properties
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    references
-        
-            
-        
-    references items
-        
-            
-        
-    componentName
              Type: string
              
-Same definition as name
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    references
-        
-            
-        
-    references items
-        
-            
-        
-    name
              Type: string
              
-
-
-    Must match regular expression: ^[a-z0-9]([-_+a-z0-9]*[a-z0-9])?$
-        
-
-        
-        
              Must be at least 2 characters long
              
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    references
-        
-            
-        
-    references items
-        
-            
-        
-    extraIdentity
              Type: object
              
-Same definition as extraIdentity
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    references
-        
-            
-        
-    references items
-        
-            
-        
-    version
              Type: string
              
-Same definition as version
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    references
-        
-            
-        
-    references items
-        
-            
-        
-    labels
              Type: array
              
-Same definition as labels
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    references
-        
-            
-        
-    references items
-        
-            
-        
-    digest

              
-
              
-  
-
              
-
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    references
-        
-            
-        
-    references items
-        
-            
-        
-    digest
-        
-            
-        
-    oneOf
-        
-            
-        
-    item 0
              Type: null
              
-
-        
-
-        
-        
-
-        
-        
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    references
-        
-            
-        
-    references items
-        
-            
-        
-    digest
-        
-            
-        
-    oneOf
-        
-            
-        
-    digestSpec
              Type: object
              
-
-
-     No Additional Properties
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    references
-        
-            
-        
-    references items
-        
-            
-        
-    digest
-        
-            
-        
-    oneOf
-        
-            
-        
-    item 1
-        
-            
-        
-    hashAlgorithm
              Type: string
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    references
-        
-            
-        
-    references items
-        
-            
-        
-    digest
-        
-            
-        
-    oneOf
-        
-            
-        
-    item 1
-        
-            
-        
-    normalisationAlgorithm
              Type: string
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    references
-        
-            
-        
-    references items
-        
-            
-        
-    digest
-        
-            
-        
-    oneOf
-        
-            
-        
-    item 1
-        
-            
-        
-    value
              Type: string
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-        
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-        
              
-    
              
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
              Type: array
              
-
-        
-
-        
-        
-
-         No Additional Items
              Each item of this array must be:
              
-    
              
-        
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items

              
-
              
-  
-
              
-
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    resourceType
              Type: object
              
-
              base type for resources
              
-              
-
-    
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    name
              Type: string
              
-
-
-    Must match regular expression: ^[a-z0-9]([-_+a-z0-9]*[a-z0-9])?$
-        
-
-        
-        
              Must be at least 2 characters long
              
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    extraIdentity
              Type: object
              
-Same definition as extraIdentity
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    version
              Type: string
              
-Same definition as version
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    type
              Type: string
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    srcRefs
              Type: array
              
-
-        
-
-        
-        
-
-         No Additional Items
              Each item of this array must be:
              
-    
              
-        
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    srcRefs
-        
-            
-        
-    srcRef
              Type: object
              
-
              a reference to a (component-local) source
              
-              
-
-    
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    srcRefs
-        
-            
-        
-    srcRefs items
-        
-            
-        
-    identitySelector
              Type: object
              
-Same definition as extraIdentity
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    srcRefs
-        
-            
-        
-    srcRefs items
-        
-            
-        
-    labels
              Type: array
              
-Same definition as labels
-            
              
-        
              
-    
              
-
              
-        
              
-    
              
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    relation
              Type: enum (of string)
              
-
              
-            
              Must be one of:
              
-            
              • "local"
              • "external"
              
-            
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    labels
              Type: array
              
-Same definition as labels
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    access

              
-
              
-  
-
              
-
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    access
              Type: object
              
-
              base type for accesses (for extensions)
              
-              Same definition as spec_sources_items_access_anyOf_i0
-        
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    ociBlobAccess
              Type: object
              
-
-
-    
-        
              
-    
              The following properties are required:
              
-    
              • layer
              
-    
              
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    type
              Type: enum (of string)
              
-
              
-            
              Must be one of:
              
-            
              • "ociBlob"
              
-            
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    ref
              Type: string
              
-
              A oci reference to the manifest
              
-              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    mediaType
              Type: string
              
-
              The media type of the object this access refers to
              
-              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    digest
              Type: string
              
-
              The digest of the targeted content
              
-              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    size
              Type: number
              
-
              The size in bytes of the blob
              
-              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-        
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    localFilesystemBlobAccess
              Type: object
              
-
-
-    
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 2
-        
-            
-        
-    type
              Type: enum (of string)
              
-
              
-            
              Must be one of:
              
-            
              • "localFilesystemBlob"
              
-            
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 2
-        
-            
-        
-    filename
              Type: string
              
-
              filename of the blob that is located in the "blobs" directory
              
-              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-        
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    localOciBlobAccess
              Type: object
              
-
-
-    
-        
              
-    
              The following properties are required:
              
-    
              • filename
              
-    
              
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 3
-        
-            
-        
-    type
              Type: enum (of string)
              
-
              
-            
              Must be one of:
              
-            
              • "localOciBlob"
              
-            
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    access
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 3
-        
-            
-        
-    digest
              Type: string
              
-
              digest of the layer within the current component descriptor
              
-              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-        
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    digest

              
-
              
-  
-
              
-
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    digest
-        
-            
-        
-    oneOf
-        
-            
-        
-    item 0
              Type: null
              
-
-        
-
-        
-        
-
-        
-        
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 0
-        
-            
-        
-    digest
-        
-            
-        
-    oneOf
-        
-            
-        
-    digestSpec
              Type: object
              
-Same definition as spec_references_items_digest_oneOf_i1
-        
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-        
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    ociImageResource
              Type: object
              
-
-
-    
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    name
              Type: string
              
-
-
-    Must match regular expression: ^[a-z0-9]([-_+a-z0-9]*[a-z0-9])?$
-        
-
-        
-        
              Must be at least 2 characters long
              
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    extraIdentity
              Type: object
              
-Same definition as extraIdentity
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    version
              Type: string
              
-Same definition as version
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    type
              Type: enum (of string)
              
-
              
-            
              Must be one of:
              
-            
              • "ociImage"
              
-            
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    labels
              Type: array
              
-Same definition as labels
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    access
              Type: object
              
-
-
-    
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    access
-        
-            
-        
-    type
              Type: enum (of string)
              
-
              
-            
              Must be one of:
              
-            
              • "ociRegistry"
              
-            
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    access
-        
-            
-        
-    imageReference
              Type: string
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    digest

              
-
              
-  
-
              
-
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    digest
-        
-            
-        
-    oneOf
-        
-            
-        
-    item 0
              Type: null
              
-
-        
-
-        
-        
-
-        
-        
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 1
-        
-            
-        
-    digest
-        
-            
-        
-    oneOf
-        
-            
-        
-    digestSpec
              Type: object
              
-Same definition as spec_references_items_digest_oneOf_i1
-        
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-        
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    genericResource
              Type: object
              
-
-
-     No Additional Properties
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 2
-        
-            
-        
-    name
              Type: string
              
-
-
-    Must match regular expression: ^[a-z0-9]([-_+a-z0-9]*[a-z0-9])?$
-        
-
-        
-        
              Must be at least 2 characters long
              
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 2
-        
-            
-        
-    extraIdentity
              Type: object
              
-Same definition as extraIdentity
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 2
-        
-            
-        
-    version
              Type: string
              
-Same definition as version
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 2
-        
-            
-        
-    type
              Type: enum (of string)
              
-
              
-            
              Must be one of:
              
-            
              • "generic"
              
-            
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 2
-        
-            
-        
-    labels
              Type: array
              
-Same definition as labels
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 2
-        
-            
-        
-    access
              Type: object
              
-
-
-    
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 2
-        
-            
-        
-    access
-        
-            
-        
-    type
              Type: enum (of string)
              
-
              
-            
              Must be one of:
              
-            
              • "generic"
              
-            
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 2
-        
-            
-        
-    digest

              
-
              
-  
-
              
-
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 2
-        
-            
-        
-    digest
-        
-            
-        
-    oneOf
-        
-            
-        
-    item 0
              Type: null
              
-
-        
-
-        
-        
-
-        
-        
              
-            
-
-    
              root
-        
-            
-        
-    spec
-        
-            
-        
-    resources
-        
-            
-        
-    resources items
-        
-            
-        
-    anyOf
-        
-            
-        
-    item 2
-        
-            
-        
-    digest
-        
-            
-        
-    oneOf
-        
-            
-        
-    digestSpec
              Type: object
              
-Same definition as spec_references_items_digest_oneOf_i1
-        
              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-        
              
-        
-
-        
-        
-
-        
-        
              
-    
              
-            
              
-        
              
-    
              
-
              
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    signatures
              Type: array
              
-
-        
-
-        
-        
-
-         No Additional Items
              Each item of this array must be:
              
-    
              
-        
              
-            
-
-    
              root
-        
-            
-        
-    signatures
-        
-            
-        
-    signature
              Type: object
              
-
-
-     No Additional Properties
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    signatures
-        
-            
-        
-    signatures items
-        
-            
-        
-    name
              Type: string
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    signatures
-        
-            
-        
-    signatures items
-        
-            
-        
-    signature
              Type: object
              
-
-
-     No Additional Properties
-        
-
-        
-        
-
-        
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    signatures
-        
-            
-        
-    signatures items
-        
-            
-        
-    signature
-        
-            
-        
-    algorithm
              Type: string
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    signatures
-        
-            
-        
-    signatures items
-        
-            
-        
-    signature
-        
-            
-        
-    value
              Type: string
              
-
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-
              
-    
              
-        
              
-            
              
-                
-            
              
-        
              
-
-        
              
-            
              
-
-    
              root
-        
-            
-        
-    signatures
-        
-            
-        
-    signatures items
-        
-            
-        
-    signature
-        
-            
-        
-    mediaType
              Type: string
              
-
              The media type of the signature value
              
-              
-        
-
-        
-        
-
-        
-            
              
-        
              
-    
              
-
              
-            
              
-        
              
-    
              
-
              
-        
              
-    
              
-            
              
-        
              
-    
              
-
              
-
-    
-
\ No newline at end of file
diff --git a/docs/roadmap/index.html b/docs/roadmap/index.html
index 4f89aab6..fef9c281 100644
--- a/docs/roadmap/index.html
+++ b/docs/roadmap/index.html
@@ -3,5 +3,5 @@
 
-
              Docs
              Roadmap
              
\ No newline at end of file
+
              Docs

              Roadmap

              \ No newline at end of file diff --git a/docs/roadmap/our-roadmap/index.html b/docs/roadmap/our-roadmap/index.html index 5d7933e1..1263b058 100644 --- a/docs/roadmap/our-roadmap/index.html +++ b/docs/roadmap/our-roadmap/index.html @@ -3,5 +3,5 @@ -
              Docs

              Our Roadmap

              You can checkout the Project Roadmap on GitHub which is based on issues and PRs from the OCM project repository.

              roadmap

              Prev
              Secure software delivery with Flux and OCM
              Next
              How to get Support
              \ No newline at end of file +
              Docs

              Our Roadmap

              You can checkout the Project Roadmap on GitHub which is based on issues and PRs from the OCM project repository.

              roadmap

              Prev
              Secure software delivery with Flux and OCM
              Next
              How to get Support
              \ No newline at end of file diff --git a/docs/sitemap.xml b/docs/sitemap.xml index 891d2ef1..c5be4eee 100644 --- a/docs/sitemap.xml +++ b/docs/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/overview/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/getting-started/2023-11-07T11:45:27+00:00monthly0.5https://ocm.software/docs/controller/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/component-descriptors/2023-01-17T10:22:05+00:00monthly0.5https://ocm.software/docs/tutorials/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/examples/2023-11-07T11:45:27+00:00monthly0.5https://ocm.software/docs/roadmap/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/support/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/contribution/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/cli-reference/monthly0.5https://ocm.software/docs/overview/about/monthly0.5https://ocm.software/docs/overview/benefits-of-ocm/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/overview/important-terms/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/overview/specification/monthly0.5https://ocm.software/docs/getting-started/installing-the-ocm-cli/monthly0.5https://ocm.software/docs/getting-started/getting-started-with-ocm/2023-03-13T09:38:41+01:00monthly0.5https://ocm.software/docs/controller/architecture/2023-10-20T11:24:41+01:00monthly0.5https://ocm.software/docs/controller/installation/2023-06-27T16:16:48+01:00monthly0.5https://ocm.software/docs/controller/controller-reference/2022-01-25T14:40:56+01:00monthly0.5https://ocm.software/docs/component-descriptors/version-2/2023-01-17T10:22:20+00:00monthly0.5https://ocm.software/docs/component-descriptors/version-3/2023-01-17T10:22:23+00:00monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/2024-07-10T08:48:23+00:00monthly0.5https://ocm.software/docs/tutorials/best-practices/2023-03-13T12:00:26+01:00monthly0.5https://ocm.software/docs/tutorials/build-deploy-infrastructure-via-helm-charts-with-ocm/2024-03-19T10:36:48+01:00monthly0.5https://ocm.software/docs/tutorials/structuring-and-deploying-software-products-with-ocm/monthly0.5https://ocm.software/docs/tutorials/input-and-access-types/monthly0.5https://ocm.software/docs/examples/secure-software-delivery-with-flux-and-ocm/2023-11-07T11:45:27+00:00monthly0.5https://ocm.software/docs/examples/credentials-in-an-.ocmconfig-file/2024-09-04T13:54:01+02:00monthly0.5https://ocm.software/docs/roadmap/our-roadmap/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/support/how-to-get-support/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/support/community/2022-08-12T10:38:22+01:00monthly0.5https://ocm.software/docs/contribution/contributing-guideline/monthly0.5https://ocm.software/docs/contribution/security-guideline/2022-08-12T10:38:22+01:00monthly0.5https://ocm.software/docs/cli-reference/add/monthly0.5https://ocm.software/docs/cli-reference/check/monthly0.5https://ocm.software/docs/cli-reference/clean/monthly0.5https://ocm.software/docs/cli-reference/create/monthly0.5https://ocm.software/docs/cli-reference/describe/monthly0.5https://ocm.software/docs/cli-reference/download/monthly0.5https://ocm.software/docs/cli-reference/get/monthly0.5https://ocm.software/docs/cli-reference/help/monthly0.5https://ocm.software/docs/cli-reference/list/monthly0.5https://ocm.software/docs/cli-reference/set/monthly0.5https://ocm.software/docs/cli-reference/show/monthly0.5https://ocm.software/docs/cli-reference/sign/monthly0.5https://ocm.software/docs/cli-reference/transfer/monthly0.5https://ocm.software/docs/cli-reference/verify/monthly0.5 \ No newline at end of file +https://ocm.software/docs/overview/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/getting-started/2023-11-07T11:45:27+00:00monthly0.5https://ocm.software/docs/controller/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/component-descriptors/2023-01-17T10:22:05+00:00monthly0.5https://ocm.software/docs/tutorials/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/examples/2023-11-07T11:45:27+00:00monthly0.5https://ocm.software/docs/roadmap/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/support/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/contribution/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/cli-reference/monthly0.5https://ocm.software/docs/overview/about/monthly0.5https://ocm.software/docs/overview/benefits-of-ocm/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/overview/important-terms/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/overview/specification/monthly0.5https://ocm.software/docs/getting-started/installing-the-ocm-cli/monthly0.5https://ocm.software/docs/getting-started/getting-started-with-ocm/2023-03-13T09:38:41+01:00monthly0.5https://ocm.software/docs/controller/architecture/2023-10-20T11:24:41+01:00monthly0.5https://ocm.software/docs/controller/installation/2023-06-27T16:16:48+01:00monthly0.5https://ocm.software/docs/controller/controller-reference/2022-01-25T14:40:56+01:00monthly0.5https://ocm.software/docs/component-descriptors/version-2/2023-01-17T10:22:20+00:00monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/2024-07-10T08:48:23+00:00monthly0.5https://ocm.software/docs/tutorials/best-practices/2023-03-13T12:00:26+01:00monthly0.5https://ocm.software/docs/tutorials/build-deploy-infrastructure-via-helm-charts-with-ocm/2024-03-19T10:36:48+01:00monthly0.5https://ocm.software/docs/tutorials/structuring-and-deploying-software-products-with-ocm/monthly0.5https://ocm.software/docs/tutorials/input-and-access-types/monthly0.5https://ocm.software/docs/examples/secure-software-delivery-with-flux-and-ocm/2023-11-07T11:45:27+00:00monthly0.5https://ocm.software/docs/examples/credentials-in-an-.ocmconfig-file/2024-09-04T13:54:01+02:00monthly0.5https://ocm.software/docs/roadmap/our-roadmap/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/support/how-to-get-support/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/support/community/2022-08-12T10:38:22+01:00monthly0.5https://ocm.software/docs/contribution/contributing-guideline/monthly0.5https://ocm.software/docs/contribution/security-guideline/2022-08-12T10:38:22+01:00monthly0.5https://ocm.software/docs/cli-reference/add/monthly0.5https://ocm.software/docs/cli-reference/check/monthly0.5https://ocm.software/docs/cli-reference/clean/monthly0.5https://ocm.software/docs/cli-reference/create/monthly0.5https://ocm.software/docs/cli-reference/describe/monthly0.5https://ocm.software/docs/cli-reference/download/monthly0.5https://ocm.software/docs/cli-reference/get/monthly0.5https://ocm.software/docs/cli-reference/help/monthly0.5https://ocm.software/docs/cli-reference/list/monthly0.5https://ocm.software/docs/cli-reference/set/monthly0.5https://ocm.software/docs/cli-reference/show/monthly0.5https://ocm.software/docs/cli-reference/sign/monthly0.5https://ocm.software/docs/cli-reference/transfer/monthly0.5https://ocm.software/docs/cli-reference/verify/monthly0.5 \ No newline at end of file diff --git a/docs/support/community/index.html b/docs/support/community/index.html index dd59ef0c..fd7f7b4a 100644 --- a/docs/support/community/index.html +++ b/docs/support/community/index.html @@ -3,5 +3,5 @@ -
              Docs

              The OCM Community

              GitHub

              You can stay updated with OCM’s latest advancements, join our active conversations, and delve into our enhancement proposals on each project’s GitHub issues page specifically for OCM.

              If you’re just starting with OCM, we recommend beginning with the ‘good first issue’ label in our repositories.

              Ready to contribute directly to OCM? Whether adding code, writing tests, or assisting with our documentation, please adhere to the guidelines provided in the ‘contributing’ documentation of the relevant OCM repository.

              Slack

              Join #open-component-model on Kubernetes Slack and talk to us and other community members.

              Kubernetes Slack Membership

              If you aren’t already a member on the Kubernetes Slack workspace, please request an invitation.

              Our team is passionate about delving into diverse deployment processes, exploring patterns, aiding in design, and troubleshooting issues. Who knows? Your inquiry might inspire the development of the next OCM feature!

              Community Meetings

              The OCM team holds regular community meetings to discuss new developments in the project and any topics of interest to the Open Component Model community. Please monitor the OCM slack channel for announcement notices.

              Please consult our community documentation for more details about the Open Component Model Community.

              Prev
              How to get Support
              Next
              Contributing Guideline
              \ No newline at end of file +
              Docs

              The OCM Community

              GitHub

              You can stay updated with OCM’s latest advancements, join our active conversations, and delve into our enhancement proposals on each project’s GitHub issues page specifically for OCM.

              If you’re just starting with OCM, we recommend beginning with the ‘good first issue’ label in our repositories.

              Ready to contribute directly to OCM? Whether adding code, writing tests, or assisting with our documentation, please adhere to the guidelines provided in the ‘contributing’ documentation of the relevant OCM repository.

              Slack

              Join #open-component-model on Kubernetes Slack and talk to us and other community members.

              Kubernetes Slack Membership

              If you aren’t already a member on the Kubernetes Slack workspace, please request an invitation.

              Our team is passionate about delving into diverse deployment processes, exploring patterns, aiding in design, and troubleshooting issues. Who knows? Your inquiry might inspire the development of the next OCM feature!

              Community Meetings

              The OCM team holds regular community meetings to discuss new developments in the project and any topics of interest to the Open Component Model community. Please monitor the OCM slack channel for announcement notices.

              Please consult our community documentation for more details about the Open Component Model Community.

              Prev
              How to get Support
              Next
              Contributing Guideline
              \ No newline at end of file diff --git a/docs/support/how-to-get-support/index.html b/docs/support/how-to-get-support/index.html index 25f8fbfa..3a897298 100644 --- a/docs/support/how-to-get-support/index.html +++ b/docs/support/how-to-get-support/index.html @@ -3,5 +3,5 @@ -
              Docs

              How to get Support

              We are here to help you with any questions you have about OCM. Here are a few ways to get support:

              1. Make sure you’ve read the basic documentation:
              2. Check the Glossary of the OCM specification for definitions of terms.
              3. Ask a question in the OCM Slack Channel in the Kubernetes Workspace.
              4. Check and read existing issues in the OCM repositories, report a bug, or request a new feature.
              Prev
              Our Roadmap
              Next
              The OCM Community
              \ No newline at end of file +
              Docs

              How to get Support

              We are here to help you with any questions you have about OCM. Here are a few ways to get support:

              1. Make sure you’ve read the basic documentation:
              2. Check the Glossary of the OCM specification for definitions of terms.
              3. Ask a question in the OCM Slack Channel in the Kubernetes Workspace.
              4. Check and read existing issues in the OCM repositories, report a bug, or request a new feature.
              Prev
              Our Roadmap
              Next
              The OCM Community
              \ No newline at end of file diff --git a/docs/support/index.html b/docs/support/index.html index 1bccd853..be48cef3 100644 --- a/docs/support/index.html +++ b/docs/support/index.html @@ -3,5 +3,5 @@ -
              Docs

              Support

              \ No newline at end of file +
              Docs

              Support

              \ No newline at end of file diff --git a/docs/tutorials/best-practices/index.html b/docs/tutorials/best-practices/index.html index e3aff004..63e2d81f 100644 --- a/docs/tutorials/best-practices/index.html +++ b/docs/tutorials/best-practices/index.html @@ -3,8 +3,8 @@ -
              Docs

              Best Practices

              This chapter contains guidelines for common scenarios how to work with the Open Component Model, focusing on using CI/CD, build and publishing processes.

              Use Public Schema for Validation and Auto-Completion of Component Descriptors

              The Open Component Model (OCM) provides a public schema to validate and offer auto-completion of component constructor files +

              Docs

              Best Practices

              This chapter contains guidelines for common scenarios how to work with the Open Component Model, focusing on using CI/CD, build and publishing processes.

              Use Public Schema for Validation and Auto-Completion of Component Descriptors

              The Open Component Model (OCM) provides a public schema to validate and offer auto-completion of component constructor files used to create component descriptors. This schema is available at https://ocm.software/schemas/configuration-schema.yaml.

              To use this schema in your IDE, you can add the following line to your component constructor file:

              # yaml-language-server: $schema=https://ocm.software/schemas/configuration-schema.yaml

              This line tells the YAML language server to use the OCM schema for validation and auto-completion.

              Separate Build and Publish Processes

              Traditional automated builds often have unrestricted internet access, which can lead to several challenges in enterprise environments:

              • Limited control over downloaded artifacts
              • Potential unavailability of required resources
              • Security risks associated with write permissions to external repositories

              Best practice: Implement a two-step process: a) Build: Create artifacts in a controlled environment, using local mirrors when possible. diff --git a/docs/tutorials/build-deploy-infrastructure-via-helm-charts-with-ocm/index.html b/docs/tutorials/build-deploy-infrastructure-via-helm-charts-with-ocm/index.html index 130a7ad6..79f5857b 100644 --- a/docs/tutorials/build-deploy-infrastructure-via-helm-charts-with-ocm/index.html +++ b/docs/tutorials/build-deploy-infrastructure-via-helm-charts-with-ocm/index.html @@ -3,8 +3,8 @@ -

              Docs

              Build & Deploy Infrastructure via Helm Charts with OCM

              Introduction

              Let’s illustrate a very simple “Hello World” example application and show how to leverage OCM to build an application component containing a Helm Chart and an OCI Image and deploy it to a local kind k8s cluster. +

              Docs

              Build & Deploy Infrastructure via Helm Charts with OCM

              Introduction

              Let’s illustrate a very simple “Hello World” example application and show how to leverage OCM to build an application component containing a Helm Chart and an OCI Image and deploy it to a local kind k8s cluster. The topics ocm localization and configuration are NOT part of this very simple example, but is covered in other tutorials.

              As base we use the podinfo application from Stefan Prodan’s Github repo. All files can be found here.

              At the end of the tutorial you will have created one OCM component for your business application podinfo. This component will be composed using the OCM guidelines and consist of multiple resources, alongside an OCI image and a Helm chart.

              For building multiple components in one shot the “all-in-one” mechanism becomes handy.

              Requirements

              Building the Application Component Using OCM

              First we build an OCM component which contains Helm Charts in different kind of formats. This 101 guide explains all possible formats a HelmChart resource can have in OCM, but in reality you’ll just pick the one most appropriate to you.

              Prepare Helm Charts

              We are leveraging Kubernetes deployments which often use Helm charts. The OCM specification supports Helm charts as artifact type. For this simple example, we will re-use existing open source community Helm charts.

              The OCM CLI supports referencing Helm charts stored in an OCI registry or Helm chart repositories, as well as local archives or folders. The preferred option is to store Helm charts in an OCI registry or Helm repository, as this allows for easy sharing and versioning of the Helm charts.

              Helm charts can be embedded in the component archive in four different ways:

              1. referenced in OCI registry
              2. referenced in Helm repository
              3. as local *.tgz file
              4. as local folder containing a Helm Chart file

              To demonstrate No. 3. and 4. we need a Helm chart on our local machine. For the sake of the this simplified guide, we download and unpack an already existing open source Helm chart for podinfo. In a real world application, this would be your own Helm chart. You will most likely store your own Helm charts within a git repository and leverage a CI/CD pipeline to build *.tgz Helm chart files in order to push them to your OCI registry or Helm repository.

              Downloading Helm charts can easily be achieved using the Helm CLI:

              helm repo add <repo-name> <helm-chart-repo-url>
diff --git a/docs/tutorials/index.html b/docs/tutorials/index.html
index a1f1c539..722bf3f9 100644
--- a/docs/tutorials/index.html
+++ b/docs/tutorials/index.html
@@ -3,5 +3,5 @@
 
-
              Docs

              Tutorials

              \ No newline at end of file +
              Docs

              Tutorials

              \ No newline at end of file diff --git a/docs/tutorials/input-and-access-types/index.html b/docs/tutorials/input-and-access-types/index.html index 2688bcb3..5c32a830 100644 --- a/docs/tutorials/input-and-access-types/index.html +++ b/docs/tutorials/input-and-access-types/index.html @@ -3,8 +3,8 @@ -
              Docs

              Input and Access Types

              Overview

              The Open Component Model spec supports multiple methods how to add resources to a component version. There are two different ways to add content: Input Type and Access Type.

              An Input type adds content by value, along with the component descriptor and stores it in the same target repository where the component is stored. After pushing the content to the target registry this always resolves to the attribute

              relation: local

              in a component descriptor.

              An Access Type just adds content by reference to an external location, e.g., an OCI registry. It is a kind of pointer in a component descriptor. It resolves to the attribute

              relation: external

              in a component descriptor.

              The following input types are supported:

              • binary
              • dir
              • docker
              • dockermulti
              • file
              • helm
              • ociImage
              • spiff
              • utf-8

              Please use the latest ocm-cli to check available input types:

              ocm add resources --help | grep ' - Input type' | sort -f

              The following list of access types is supported:

              • gitHub
              • localBlob
              • ociArtifact
              • ociBlob
              • s3

              Please use the latest ocm-cli to check available access types:

              ocm ocm-accessmethods | grep '  - Access type' | sort -f

              Not all access and input types can be combined in useful ways with all artifact types. But the OCM specification does not define any restrictions on possible combinations.

              The following sections give an overview and typical usage examples for access and input types. It does not describe the full list of possible fields and their meaning. For a complete list of attributes, please see the command reference. The examples below are meant to be used in a component that looks like this:

              - name: github.com/open-component-model/megacomponent
+
              Docs

              Input and Access Types

              Overview

              The Open Component Model spec supports multiple methods how to add resources to a component version. There are two different ways to add content: Input Type and Access Type.

              An Input type adds content by value, along with the component descriptor and stores it in the same target repository where the component is stored. After pushing the content to the target registry this always resolves to the attribute

              relation: local

              in a component descriptor.

              An Access Type just adds content by reference to an external location, e.g., an OCI registry. It is a kind of pointer in a component descriptor. It resolves to the attribute

              relation: external

              in a component descriptor.

              The following input types are supported:

              • binary
              • dir
              • docker
              • dockermulti
              • file
              • helm
              • ociImage
              • spiff
              • utf-8

              Please use the latest ocm-cli to check available input types:

              ocm add resources --help | grep ' - Input type' | sort -f

              The following list of access types is supported:

              • gitHub
              • localBlob
              • ociArtifact
              • ociBlob
              • s3

              Please use the latest ocm-cli to check available access types:

              ocm ocm-accessmethods | grep '  - Access type' | sort -f

              Not all access and input types can be combined in useful ways with all artifact types. But the OCM specification does not define any restrictions on possible combinations.

              The following sections give an overview and typical usage examples for access and input types. It does not describe the full list of possible fields and their meaning. For a complete list of attributes, please see the command reference. The examples below are meant to be used in a component that looks like this:

              - name: github.com/open-component-model/megacomponent
   version: 0.1.0

              Input Types

              binary

              Allows to define resources with binary content being base64 encoded. Should only be used for smaller blobs.

                resources:
   - name: noticeencoded
     type : blob
diff --git a/docs/tutorials/ocm-and-gitops/air-gapped-gitops-with-ocm-flux/index.html b/docs/tutorials/ocm-and-gitops/air-gapped-gitops-with-ocm-flux/index.html
index 13865211..ad31e313 100644
--- a/docs/tutorials/ocm-and-gitops/air-gapped-gitops-with-ocm-flux/index.html
+++ b/docs/tutorials/ocm-and-gitops/air-gapped-gitops-with-ocm-flux/index.html
@@ -3,8 +3,8 @@
 
-
              Docs

              Air-gapped GitOps with OCM & Flux

              Introduction

              In this guide, we will show you how the tools provided by OCM make it possible to automate your air-gapped deployments.

              Air-gapped can mean different things depending on the context. For this guide, we’ll assume it means your deployment artifacts are stored in a private registry protected by the security controls at your organization. Your applications only have access to this private registry and little to no public internet access.

              We’ll take the same podinfo component that we deployed in the Deploy Applications with OCM & GitOps guide but this time we will use the OCM CLI to transfer the component to our own registry. The application will then be deployed from this “private” registry. This, of course, mimics a real-world air-gap scenario. In practice, there could be many layers of security between the two registries; however, the mechanics are ultimately the same.

              Table of Contents

              Requirements

              Component Content

              The podinfo component contains three resources:

              • a container image for podinfo
              • a kubernetes deployment manifest for podinfo
              • a configuration file read by the ocm-controller

              We can list these resources using the ocm CLI:

              ocm get resources ghcr.io/phoban01//phoban.io/podinfo -c v6.3.5
+
              Docs

              Air-gapped GitOps with OCM & Flux

              Introduction

              In this guide, we will show you how the tools provided by OCM make it possible to automate your air-gapped deployments.

              Air-gapped can mean different things depending on the context. For this guide, we’ll assume it means your deployment artifacts are stored in a private registry protected by the security controls at your organization. Your applications only have access to this private registry and little to no public internet access.

              We’ll take the same podinfo component that we deployed in the Deploy Applications with OCM & GitOps guide but this time we will use the OCM CLI to transfer the component to our own registry. The application will then be deployed from this “private” registry. This, of course, mimics a real-world air-gap scenario. In practice, there could be many layers of security between the two registries; however, the mechanics are ultimately the same.

              Table of Contents

              Requirements

              Component Content

              The podinfo component contains three resources:

              • a container image for podinfo
              • a kubernetes deployment manifest for podinfo
              • a configuration file read by the ocm-controller

              We can list these resources using the ocm CLI:

              ocm get resources ghcr.io/phoban01//phoban.io/podinfo -c v6.3.5
 
 NAME       VERSION IDENTITY TYPE      RELATION
 config     6.3.5            PlainText local
diff --git a/docs/tutorials/ocm-and-gitops/deploying-applications-with-ocm-gitops/index.html b/docs/tutorials/ocm-and-gitops/deploying-applications-with-ocm-gitops/index.html
index a9fc119b..4c776b5b 100644
--- a/docs/tutorials/ocm-and-gitops/deploying-applications-with-ocm-gitops/index.html
+++ b/docs/tutorials/ocm-and-gitops/deploying-applications-with-ocm-gitops/index.html
@@ -3,8 +3,8 @@
 
-
              Docs

              Deploying Applications with OCM & GitOps

              Introduction

              This tutorial will demonstrate how to get started deploying applications using the Open Component Model & Flux.

              In this guide, we will leverage Flux and the ocm-controller to deploy an existing component to a Kubernetes cluster. Specifically, we will deploy the phoban.io/podinfo component that contains the resources needed to launch the podinfo application.

              Here’s a diagram showing what we’ll be building:

              deploy-app-with-gitops

              As you can see, we’ll add some manifests to a git repository that will be deployed by Flux. These will, in turn, deploy a resource from an OCM repository, in this case, a Deployment of the podinfo microservice.

              If you’d like to learn how to build a component, then check out our Getting Started guide.

              Table of Contents

              Requirements

              Environment Setup

              First of all, let’s create a cluster using kind:

              kind create cluster

              With the cluster created, we can now bootstrap Flux to automate the deployment of our component. Flux can create a repository and clone it to our local environment by running the following shell command:

              export GITHUB_REPOSITORY=podinfo-flux-repo
+
              Docs

              Deploying Applications with OCM & GitOps

              Introduction

              This tutorial will demonstrate how to get started deploying applications using the Open Component Model & Flux.

              In this guide, we will leverage Flux and the ocm-controller to deploy an existing component to a Kubernetes cluster. Specifically, we will deploy the phoban.io/podinfo component that contains the resources needed to launch the podinfo application.

              Here’s a diagram showing what we’ll be building:

              deploy-app-with-gitops

              As you can see, we’ll add some manifests to a git repository that will be deployed by Flux. These will, in turn, deploy a resource from an OCM repository, in this case, a Deployment of the podinfo microservice.

              If you’d like to learn how to build a component, then check out our Getting Started guide.

              Table of Contents

              Requirements

              Environment Setup

              First of all, let’s create a cluster using kind:

              kind create cluster

              With the cluster created, we can now bootstrap Flux to automate the deployment of our component. Flux can create a repository and clone it to our local environment by running the following shell command:

              export GITHUB_REPOSITORY=podinfo-flux-repo
 
 flux bootstrap github \
   --owner $GITHUB_USER \
diff --git a/docs/tutorials/ocm-and-gitops/gitops-driven-configuration-of-ocm-applications/index.html b/docs/tutorials/ocm-and-gitops/gitops-driven-configuration-of-ocm-applications/index.html
index d93b7e1c..47bcbc97 100644
--- a/docs/tutorials/ocm-and-gitops/gitops-driven-configuration-of-ocm-applications/index.html
+++ b/docs/tutorials/ocm-and-gitops/gitops-driven-configuration-of-ocm-applications/index.html
@@ -3,8 +3,8 @@
 
-
              Docs

              GitOps Driven Configuration of OCM Applications

              Introduction

              This guide is the final part of our series exploring OCM, the ocm-controller, and how to drive GitOps processes using OCM as the source of truth.

              Check out the previous guides if you haven’t already:

              In this guide we will pick-up where we left off in the air-gapped example.

              We have successfully transferred a component to our private environment and deployed it using the ocm-controller. However, the Kubernetes Deployment for podinfo is failing because it does not have permission to access our private container images.

              Let’s fix that.

              Table of Contents

              Requirements

              Component Content Recap

              We saw previously that the podinfo component contains three resources:

              • podinfo container image
              • kubernetes deployment manifest for podinfo
              • configuration file read by the ocm-controller

              We can list these resources using the ocm CLI:

              ocm get resources ghcr.io/phoban01//phoban.io/podinfo -c v6.3.5
+
              Docs

              GitOps Driven Configuration of OCM Applications

              Introduction

              This guide is the final part of our series exploring OCM, the ocm-controller, and how to drive GitOps processes using OCM as the source of truth.

              Check out the previous guides if you haven’t already:

              In this guide we will pick-up where we left off in the air-gapped example.

              We have successfully transferred a component to our private environment and deployed it using the ocm-controller. However, the Kubernetes Deployment for podinfo is failing because it does not have permission to access our private container images.

              Let’s fix that.

              Table of Contents

              Requirements

              Component Content Recap

              We saw previously that the podinfo component contains three resources:

              • podinfo container image
              • kubernetes deployment manifest for podinfo
              • configuration file read by the ocm-controller

              We can list these resources using the ocm CLI:

              ocm get resources ghcr.io/phoban01//phoban.io/podinfo -c v6.3.5
 
 NAME       VERSION IDENTITY TYPE      RELATION
 config     6.3.5            PlainText local
diff --git a/docs/tutorials/ocm-and-gitops/index.html b/docs/tutorials/ocm-and-gitops/index.html
index 25698522..d17c10fe 100644
--- a/docs/tutorials/ocm-and-gitops/index.html
+++ b/docs/tutorials/ocm-and-gitops/index.html
@@ -3,5 +3,5 @@
 
-
              Docs

              OCM and GitOps

              \ No newline at end of file +
              Docs

              OCM and GitOps

              \ No newline at end of file diff --git a/docs/tutorials/structuring-and-deploying-software-products-with-ocm/index.html b/docs/tutorials/structuring-and-deploying-software-products-with-ocm/index.html index 6cacc7fe..5fbff307 100644 --- a/docs/tutorials/structuring-and-deploying-software-products-with-ocm/index.html +++ b/docs/tutorials/structuring-and-deploying-software-products-with-ocm/index.html @@ -3,8 +3,8 @@ -
              Docs

              Structuring and Deploying Software Products with OCM

              Introduction

              In this specification software products are comprised of logical units called components. A component version consists of a set of technical artifacts (e.g., Docker images, Helm charts, binaries, configuration data, etc.). Such artifacts are called resources in this specification. Resources are usually built from something, e.g., code in a git repo. Those are named sources in this specification.

              OCM introduces a Component Descriptor for every component version that +

              Docs

              Structuring and Deploying Software Products with OCM

              Introduction

              In this specification software products are comprised of logical units called components. A component version consists of a set of technical artifacts (e.g., Docker images, Helm charts, binaries, configuration data, etc.). Such artifacts are called resources in this specification. Resources are usually built from something, e.g., code in a git repo. Those are named sources in this specification.

              OCM introduces a Component Descriptor for every component version that describes the resources, sources, and other component versions belonging to a particular component version and how to access them.

              Usually, however, real-life applications are composed of multiple components. For example, an application might consist of a frontend, a backend, a database, and a web server. diff --git a/index.xml b/index.xml index 7bde7f2d..bf5ead8c 100644 --- a/index.xml +++ b/index.xml @@ -1,6 +1,7 @@ -Open Component Modelhttps://ocm.software/Recent content on Open Component ModelHugoen© Copyright 2024, SAP SE and Open Component Model ContributorsMon, 13 Mar 2023 09:38:41 +0100Version 2https://ocm.software/docs/component-descriptors/version-2/Tue, 17 Jan 2023 10:22:20 +0000https://ocm.software/docs/component-descriptors/version-2/<p>The following is an example of a public-key-based signed component descriptor containing a resource, source and one component reference. It uses the <code>v2</code> schema (which is the default). There are no differences in the semantics between version v2 and v3. <code>meta.schemaVersion</code> is used as kind of moniker for different serializing/deserializing formats (<code>v3</code> has the format of Kubernetes resources).</p>Version 3https://ocm.software/docs/component-descriptors/version-3/Tue, 17 Jan 2023 10:22:23 +0000https://ocm.software/docs/component-descriptors/version-3/<p>The following is an example of a public-key-based signed component descriptor containing a resource, source and one component reference. It uses the <code>v3alpha1</code> schema. There are no differences in the semantics between version v2 and v3. <code>apiVersion</code> is used as kind of moniker for different serializing/deserializing formats (<code>v3</code> has the format of Kubernetes resources).</p>About the OCM Projecthttps://ocm.software/docs/overview/about/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/overview/about/<p>The Open Component Model (OCM) project provides an open standard for describing software artifacts and lifecycle metadata, with the purpose to securely deliver and deploy software products. It facilitates asynchronous handling of various lifecycle management processes, such as compliance checks, security scans, deployments, and more, in a decoupled and streamlined manner. OCM provides the ability to deliver software securely, consistently, and compliantly across cloud, on-prem, hybrid and air-gapped environments.</p>Benefits of OCMhttps://ocm.software/docs/overview/benefits-of-ocm/Tue, 06 Oct 2020 08:48:23 +0000https://ocm.software/docs/overview/benefits-of-ocm/<p>In today&rsquo;s cloud era, enterprises still grapple with tools and processes rooted in outdated on-premises and monolithic thinking. Ad-hoc, fragmented toolsets are used across software lifecycle processes, severely impacting the ability to deliver software securely, consistently, and compliantly across cloud, on-prem, hybrid and air-gapped environments.</p>Important Termshttps://ocm.software/docs/overview/important-terms/Tue, 06 Oct 2020 08:48:23 +0000https://ocm.software/docs/overview/important-terms/<p>As the Open Component Model (OCM) revolves around components, it is essential to establish a common understanding of the fundamental terminology employed throughout this website. The following section provides concise definitions of key terms, laying the groundwork for the documentation and tutorials that follow.</p>Specificationhttps://ocm.software/docs/overview/specification/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/overview/specification/<h2 id="where-to-find-the-ocm-specification">Where to find the OCM specification</h2> +Open Component Modelhttps://ocm.software/Recent content on Open Component ModelHugoen© Copyright 2024, SAP SE and Open Component Model ContributorsMon, 13 Mar 2023 09:38:41 +0100Version 2https://ocm.software/docs/component-descriptors/version-2/Tue, 17 Jan 2023 10:22:20 +0000https://ocm.software/docs/component-descriptors/version-2/<p>The following is an example of a public-key-based signed component descriptor containing a resource, source and one component reference. It uses the default <code>v2</code> schema.</p>About the OCM Projecthttps://ocm.software/docs/overview/about/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/overview/about/<p>The Open Component Model (OCM) project provides an open standard for describing software artifacts and lifecycle metadata, with the purpose to securely deliver and deploy software products. It facilitates asynchronous handling of various lifecycle management processes, such as compliance checks, security scans, deployments, and more, in a decoupled and streamlined manner. OCM provides the ability to deliver software securely, consistently, and compliantly across cloud, on-prem, hybrid and air-gapped environments.</p>Benefits of OCMhttps://ocm.software/docs/overview/benefits-of-ocm/Tue, 06 Oct 2020 08:48:23 +0000https://ocm.software/docs/overview/benefits-of-ocm/<p>In today&rsquo;s cloud era, enterprises still grapple with tools and processes rooted in outdated on-premises and monolithic thinking. Ad-hoc, fragmented toolsets are used across software lifecycle processes, severely impacting the ability to deliver software securely, consistently, and compliantly across cloud, on-prem, hybrid and air-gapped environments.</p>Important Termshttps://ocm.software/docs/overview/important-terms/Tue, 06 Oct 2020 08:48:23 +0000https://ocm.software/docs/overview/important-terms/<p>As the Open Component Model (OCM) revolves around components, it is essential to establish a common understanding of the fundamental terminology employed throughout this website. The following section provides concise definitions of key terms, laying the groundwork for the documentation and tutorials that follow.</p>Specificationhttps://ocm.software/docs/overview/specification/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/overview/specification/<h2 id="where-to-find-the-ocm-specification">Where to find the OCM specification</h2> <p>The most up-to-date version of the <a href="https://github.com/open-component-model/ocm-spec/blob/main/README.md">OCM specification</a> offers you a deep insight to all technical details of the Open Component Model and explains all elements the model OCM is based on.</p>Installing the OCM CLIhttps://ocm.software/docs/getting-started/installing-the-ocm-cli/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/getting-started/installing-the-ocm-cli/<h2 id="overview">Overview</h2> <p>You can install the latest release of the OCM CLI from any of the following sources (more details below):</p>Prerequisiteshttps://ocm.software/docs/getting-started/getting-started-with-ocm/prerequisites/Mon, 13 Mar 2023 09:38:41 +0100https://ocm.software/docs/getting-started/getting-started-with-ocm/prerequisites/<p>This and the following chapters walk you through some basic steps to get started with OCM concepts and the OCM CLI. You will learn how to create a component version, display and examine the component, and how to transport and sign it.</p>Create a Component Versionhttps://ocm.software/docs/getting-started/getting-started-with-ocm/create-a-component-version/Mon, 13 Mar 2023 09:38:41 +0100https://ocm.software/docs/getting-started/getting-started-with-ocm/create-a-component-version/<h2 id="creating-and-storing-component-versions">Creating and Storing Component Versions</h2> -<p>Component Versions are created using a <code>component-constructor.yaml</code> 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.</p>Display and Examine Component Versionshttps://ocm.software/docs/getting-started/getting-started-with-ocm/display-and-examine-component-versions/Mon, 13 Mar 2023 09:38:41 +0100https://ocm.software/docs/getting-started/getting-started-with-ocm/display-and-examine-component-versions/<h2 id="list-component-versions">List Component Versions</h2> -<p>To show a component stored in an OCM repository or CTF archive (which itself is an OCM repository), the <a href="https://github.com/open-component-model/ocm/blob/main/docs/reference/ocm_get_componentversions.md"><code>ocm get componentversion</code></a> command can be used:</p> \ No newline at end of file +<p>Component Versions are created using a <code>component-constructor.yaml</code> 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.</p>Display and Examine Component Versionshttps://ocm.software/docs/getting-started/getting-started-with-ocm/display-and-examine-component-versions/Mon, 13 Mar 2023 09:38:41 +0100https://ocm.software/docs/getting-started/getting-started-with-ocm/display-and-examine-component-versions/<h2 id="list-component-versions">List Component Versions</h2> +<p>To show a component stored in an OCM repository or CTF archive (which itself is an OCM repository), the <a href="https://github.com/open-component-model/ocm/blob/main/docs/reference/ocm_get_componentversions.md"><code>ocm get componentversion</code></a> command can be used:</p>Transport OCM Component Versionshttps://ocm.software/docs/getting-started/getting-started-with-ocm/transport-ocm-component-versions/Mon, 13 Mar 2023 09:38:41 +0100https://ocm.software/docs/getting-started/getting-started-with-ocm/transport-ocm-component-versions/<p>The section <a href="https://ocm.software/docs/getting-started/getting-started-with-ocm/create-a-component-version#bundle-composed-components">Bundle Composed Components</a> explained how to bundle multiple component version into a transport archive.</p> +<p>During the transfer, it is possible to include component references as local blobs. It is also possible to include references in a recursive way.</p> \ No newline at end of file diff --git a/search-index.json b/search-index.json index 866df951..69e55ac2 100644 --- a/search-index.json +++ b/search-index.json @@ -1 +1 @@ -[{"content":"The following is an example of a public-key-based signed component descriptor containing a resource, source and one component reference. It uses the v2 schema (which is the default). There are no differences in the semantics between version v2 and v3. meta.schemaVersion is used as kind of moniker for different serializing/deserializing formats (v3 has the format of Kubernetes resources).\nThis component is publicly available and can be inspected using the following command:\nocm componentversion get --repo ghcr.io/phoban01/ocm github.com/weaveworks/weave-gitops -oyaml\rmeta: schemaVersion: v2 # component schema version component: name: github.com/weaveworks/weave-gitops # name of the component version: v1.0.0 # version of the component provider: weaveworks # component provider information repositoryContexts: # list of repository context the component version \u0026#34;lived\u0026#34; in, with the current one at the top - baseUrl: ghcr.io componentNameMapping: urlPath subPath: phoban01/ocm type: OCIRegistry resources: # list of resources modelled by the component - name: image # resource name relation: external # resource location (external repository or internal to this repository) type: ociImage # resource type version: v0.14.1 # resource version access: # metadata describing how to access the resource type: ociArtifact # type of access information imageReference: ghcr.io/weaveworks/wego-app:v0.14.1 digest: # signing metadata for the resource hashAlgorithm: SHA-256 normalisationAlgorithm: ociArtifactDigest/v1 value: efa2b9980ca2de65dc5a0c8cc05638b1a4b4ce8f6972dc08d0e805e5563ba5bb sources: # list of sources relevant to this component - name: weave-gitops # source name type: git # source type version: v0.14.1 # source version access: # metadata describing how to access the source commit: 727513969553bfcc603e1c0ae1a75d79e4132b58 ref: refs/tags/v0.14.1 repoUrl: github.com/weaveworks/weave-gitops type: gitHub componentReferences: # list of references to other components - name: prometheus # reference name version: v1.0.0 # reference version componentName: cncf.io/prometheus # referenced component name digest: # signing metadata for the referenced resource hashAlgorithm: SHA-256 normalisationAlgorithm: jsonNormalisation/v1 value: 04eb20b6fd942860325caf7f4415d1acf287a1aabd9e4827719328ba25d6f801 signatures: # list of signatures used for signing and verification - name: ww-dev # name of the signature digest: # digest of the signature including the algorithm used hashAlgorithm: SHA-256 normalisationAlgorithm: jsonNormalisation/v1 value: 4faff7822616305ecd09284d7c3e74a64f2269dcc524a9cdf0db4b592b8cee6a signature: # signature including the algorithm used algorithm: RSASSA-PSS mediaType: application/vnd.ocm.signature.rsa value: 26468587671bdbd2166cf5f69829f090c10768511b15e804294fcb26e552654316c8f4851ed396f279ec99335e5f4b11cb043feb97f1f9a42115f4fda2d31ae8b481b7303b9a913d3a4b92d446fbee9ed487c93b09e513f3f68355040ec08454675e1f407422062abbd2681f70dd5488ad29020b30cfa7e001455c550458da96166bc3243c8426977d73352aface5323fb2b5a374e9c31b272a59c160b85631231c9fc2f23c032401b80fef937029a39111cee34470c61ae86cd4942553466411a5a116159fdcc10e50fe9360c5184028e72d1fe9c7315f26e15d7b4849f62d197501b8cc6b6f1b1391ecc2fc2fc0c1290d2554594505b25fa8f9bfb28c8df24\r","date":"2023-01-17","id":0,"permalink":"/docs/component-descriptors/version-2/","summary":"\u003cp\u003eThe following is an example of a public-key-based signed component descriptor containing a resource, source and one component reference. It uses the \u003ccode\u003ev2\u003c/code\u003e schema (which is the default). There are no differences in the semantics between version v2 and v3. \u003ccode\u003emeta.schemaVersion\u003c/code\u003e is used as kind of moniker for different serializing/deserializing formats (\u003ccode\u003ev3\u003c/code\u003e has the format of Kubernetes resources).\u003c/p\u003e","tags":[],"title":"Version 2"},{"content":"The following is an example of a public-key-based signed component descriptor containing a resource, source and one component reference. It uses the v3alpha1 schema. There are no differences in the semantics between version v2 and v3. apiVersion is used as kind of moniker for different serializing/deserializing formats (v3 has the format of Kubernetes resources).\nThis component is publicly available and can be inspected using the following command:\nocm componentversion get --repo ghcr.io/phoban01/ocm github.com/weaveworks/weave-gitops --scheme v3alpha1 -oyaml\rComponent Descriptor apiVersion: ocm.software/v3alpha1 # component schema version kind: ComponentVersion metadata: name: github.com/weaveworks/weave-gitops # name of the component provider: # component provider information name: weaveworks version: v1.0.0 # version of the component repositoryContexts: # list of repository context the component version \u0026#34;lived\u0026#34; in, with the current one at the top - baseUrl: ghcr.io componentNameMapping: urlPath subPath: phoban01/ocm type: OCIRegistry spec: resources: # list of resources modelled by the component - name: image # resource name relation: external # resource location (external repository or internal to this repository) type: ociImage # resource type version: v0.14.1 # resource version access: # metadata describing how to access the resource type: ociArtifact # type of accesss information imageReference: ghcr.io/weaveworks/wego-app:v0.14.1 # oci image url digest: # signing metadata for the resource hashAlgorithm: SHA-256 normalisationAlgorithm: ociArtifactDigest/v1 value: efa2b9980ca2de65dc5a0c8cc05638b1a4b4ce8f6972dc08d0e805e5563ba5bb # the digest itself sources: # list of sources relevant to this component - name: weave-gitops # source name type: git # source type version: v0.14.1 # source version access: # metadata describing how to access the source type: gitHub # ref: refs/tags/v0.14.1 repoUrl: github.com/weaveworks/weave-gitops commit: 727513969553bfcc603e1c0ae1a75d79e4132b58 references: # list of references to other components - name: prometheus # reference name version: v1.0.0 # reference version componentName: cncf.io/prometheus # referenced component name digest: # signing metadata for the referenced resource hashAlgorithm: SHA-256 normalisationAlgorithm: jsonNormalisation/v1 value: 04eb20b6fd942860325caf7f4415d1acf287a1aabd9e4827719328ba25d6f801 signatures: # list of signatures used for signing and verification - name: ww-dev # name of the signature digest: # digest of the signature including the algorithm used hashAlgorithm: SHA-256 normalisationAlgorithm: jsonNormalisation/v1 value: 4faff7822616305ecd09284d7c3e74a64f2269dcc524a9cdf0db4b592b8cee6a signature: # signature including the algorithm used algorithm: RSASSA-PSS mediaType: application/vnd.ocm.signature.rsa value: 26468587671bdbd2166cf5f69829f090c10768511b15e804294fcb26e552654316c8f4851ed396f279ec99335e5f4b11cb043feb97f1f9a42115f4fda2d31ae8b481b7303b9a913d3a4b92d446fbee9ed487c93b09e513f3f68355040ec08454675e1f407422062abbd2681f70dd5488ad29020b30cfa7e001455c550458da96166bc3243c8426977d73352aface5323fb2b5a374e9c31b272a59c160b85631231c9fc2f23c032401b80fef937029a39111cee34470c61ae86cd4942553466411a5a116159fdcc10e50fe9360c5184028e72d1fe9c7315f26e15d7b4849f62d197501b8cc6b6f1b1391ecc2fc2fc0c1290d2554594505b25fa8f9bfb28c8df24\r","date":"2023-01-17","id":1,"permalink":"/docs/component-descriptors/version-3/","summary":"\u003cp\u003eThe following is an example of a public-key-based signed component descriptor containing a resource, source and one component reference. It uses the \u003ccode\u003ev3alpha1\u003c/code\u003e schema. There are no differences in the semantics between version v2 and v3. \u003ccode\u003eapiVersion\u003c/code\u003e is used as kind of moniker for different serializing/deserializing formats (\u003ccode\u003ev3\u003c/code\u003e has the format of Kubernetes resources).\u003c/p\u003e","tags":[],"title":"Version 3"},{"content":"","date":"2024-07-10","id":2,"permalink":"/docs/tutorials/ocm-and-gitops/","summary":"","tags":[],"title":"OCM and GitOps"},{"content":"","date":"2020-10-06","id":3,"permalink":"/docs/overview/","summary":"","tags":[],"title":"Overview"},{"content":"The Open Component Model (OCM) project provides an open standard for describing software artifacts and lifecycle metadata, with the purpose to securely deliver and deploy software products. It facilitates asynchronous handling of various lifecycle management processes, such as compliance checks, security scans, deployments, and more, in a decoupled and streamlined manner. OCM provides the ability to deliver software securely, consistently, and compliantly across cloud, on-prem, hybrid and air-gapped environments.\nBelow are the main projects, but please also check out the others in our Github org.\nOCM Specification - The ocm-spec repository contains the OCM specification, which provides a formal description of OCM and its format to describe software artifacts and a storage layer to persist those and make them accessible from remote. OCM Core Library - The ocm core library contains an API for interacting with OCM elements. A guided tour on how to work with the library can be found here. OCM CLI - With the ocm command line interface end users can interact with OCM elements, helping them create component versions and embed them in CI and CD processes. Examples can be found in this Makefile. OCM Controller - The ocm-controllers are designed to enable the automated deployment of software using the Open Component Model and Flux. OCM Website - The ocm-website you are currently visiting. It is built using Hugo and hosted on Github Pages. ","date":"0001-01-01","id":4,"permalink":"/docs/overview/about/","summary":"\u003cp\u003eThe Open Component Model (OCM) project provides an open standard for describing software artifacts and lifecycle metadata, with the purpose to securely deliver and deploy software products. It facilitates asynchronous handling of various lifecycle management processes, such as compliance checks, security scans, deployments, and more, in a decoupled and streamlined manner. OCM provides the ability to deliver software securely, consistently, and compliantly across cloud, on-prem, hybrid and air-gapped environments.\u003c/p\u003e","tags":[],"title":"About the OCM Project"},{"content":"In today\u0026rsquo;s cloud era, enterprises still grapple with tools and processes rooted in outdated on-premises and monolithic thinking. Ad-hoc, fragmented toolsets are used across software lifecycle processes, severely impacting the ability to deliver software securely, consistently, and compliantly across cloud, on-prem, hybrid and air-gapped environments.\nOverly complex, bespoke CI/CD pipelines and the lack of automation across the whole lifecyle process create a tedious, error-prone, and ineffective approach to managing software at scale. This operational nightmare is compounded by the absence of a standardized way to describe software components and their associated technical artifacts.\nRequirements Towards a Modern Software Component Model Immutable and Unique Component Identity A crucial requirement is the ability to assign an immutable and globally unique Component Identity to each software component. This identifier acts as a \u0026ldquo;correlation ID,\u0026rdquo; allowing all lifecycle management processes, such as security compliance and vulnerability scanning, to correlate their outputs to a single, identifiable software component.\nArtifact Descriptions with Location Information The model should facilitate the description of all technical artifacts required for deploying a specific version of a software component. This list, termed a \u0026ldquo;Software Bill of Delivery\u0026rdquo; (SBoD), outlines only the artifacts needed for successful deployment. Additionally, the description must encompass the technical access location from which each artifact can be retrieved.\nSeparation of Component Identity and Artifact Location In certain environments, artifacts are required to be stored in local registries, mandating the copying of technical artifacts into these target environments. This is especially true for private or air-gapped scenarios where retrieving artifacts from their original location is not feasible due to restricted or non-existent internet access or compliance reasons. To address this, the model must enable the separation of a software component\u0026rsquo;s immutable ID from the current location of its technical artifacts. The Component Identity must remain stable across all boundaries and system environments, while the artifact locations should be changeable.\nTechnology-Agnostic At its core, the model must be technology-agnostic, capable of supporting not only modern containerized cloud products but also legacy software. Many larger companies operate hybrid landscapes comprising modern cloud-native products running on cloud infrastructures and legacy applications that have not yet transitioned (or may never transition) to the public cloud or be containerized. To cater to such scenarios, it is crucial for the software component model to handle both cloud-native and legacy software, necessitating complete agnosticism regarding the technologies used by the described software components and their artifacts.\nExtensibility The model should be designed with extensibility in mind, enabling straightforward adaptation to future trends and technologies without constantly impacting the tools and processes employed for software lifecycle management.\nSigning The model should provide out-of-the-box support for signing and verification processes. This capability allows consumers of software components to verify that the delivered components have not been tampered with. Importantly, the signing and verification support must account for the possibility that the technical artifact locations may change over time, implying that these specific locations should not be part of the signing process.\nNetwork Effects Components described using OCM are primed for secure consumption and immediate integration into higher-level components (or products). The ability to link to trusted and already attested components can facilitate adoption across different teams within an organization, directly improving efficiency (akin to the proficiency of package models like Maven or npm). Moreover, with other parties also describing components using OCM, commercial contracts can cover the necessary technical trust outside the organization, simplifying the secure import and compliant re-use of these components. OCM envisions fostering a network effect across the industry.\nOCM: Streamlining Software Lifecycle Management The Open Component Model (OCM) is the much-needed life-raft for organizations drowning in software lifecycle management complexity. By establishing a standardized way to describe software components and their artifacts, OCM tackles the core issues plaguing enterprises. By linking additional metadata using OCM’s identities, it facilitates asynchronous handling of various lifecycle management processes, such as compliance checks, security scans, deployments, and more, in a decoupled and streamlined manner.\nUnique Component Identities: OCM assigns an immutable, globally unique ID to each component, enabling seamless correlation across all lifecycle tools and processes like a \u0026ldquo;compliance dashboard\u0026rdquo;.\nSoftware Bill of Delivery: OCM enables the precise specification of all technical artifacts required for delivering a software component. This compilation, termed a \u0026ldquo;Software Bill of Delivery\u0026rdquo; (SBoD), comprehensively lists the necessary artifacts along with their corresponding location information to facilitate seamless access.\nStable IDs, Changing Artifact Locations: OCM cleanly separates the immutable component ID from the changeable artifact locations, essential for hybrid/private environments.\nTechnology Agnosticism: Being agnostic to implementation technologies like container images, NPM packages or binaries, OCM effortlessly handles both cloud-native and legacy apps.\nFuture-Proof Extensibility: OCM\u0026rsquo;s extensible design allows simple adaptation to emerging trends without disrupting existing tooling.\nTrusted Signatures: Built-in signing and verification ensure artifact integrity even as artifact locations change over time.\nWith OCM, a \u0026ldquo;single source of truth\u0026rdquo; is established for all software artifacts across the lifecycle. Compliance checks, security scans, deployments, and more become streamlined operations anchored to OCM\u0026rsquo;s standardized component definitions.\nMoreover, by fostering component reuse within and across organizations, OCM unlocks powerful network effects akin to package managers, boosting productivity, and simplifying commercial software consumption.\nIn essence, OCM is the missing link that finally empowers organizations to tame the software lifecycle beast through a consistent, location-agnostic way to identify, access, exchange and verify software artifacts at scale.\n","date":"2020-10-06","id":5,"permalink":"/docs/overview/benefits-of-ocm/","summary":"\u003cp\u003eIn today\u0026rsquo;s cloud era, enterprises still grapple with tools and processes rooted in outdated on-premises and monolithic thinking. Ad-hoc, fragmented toolsets are used across software lifecycle processes, severely impacting the ability to deliver software securely, consistently, and compliantly across cloud, on-prem, hybrid and air-gapped environments.\u003c/p\u003e","tags":[],"title":"Benefits of OCM"},{"content":"As the Open Component Model (OCM) revolves around components, it is essential to establish a common understanding of the fundamental terminology employed throughout this website. The following section provides concise definitions of key terms, laying the groundwork for the documentation and tutorials that follow.\nFor a comprehensive exploration of every aspect of this topic, please refer to the OCM Specification OCM Specification and its Glossary.\nComponents in OCM The concept of a Component can vary widely, often defined with very specific views on granularity or other technical attributes. OCM takes a different approach, focusing on the intended purpose and overall meaning of components.\nIn OCM, Components group a set of semantically related Component Versions. Each Component Version is uniquely and globally identified by a Component Identity and can reference other Components. A Component Version can also contain Artifacts and a formal description on how to access them. These Artifacts come in two categories: resources, which describe the payload (e.g.,OCI images), and sources, which describe the input for creating resources (e.g., source code).\nOCM Coordinates OCM Coordinates are used to reference OCM Component Versions and Artifacts within OCM Component Versions. Coordinates referring to an OCM Component Version are also called Component Identity, whereas relative Coordinates referring to an artifact are called Artifact Identity. Component Identities are globally unique and may be used to refer to full Component Versions. Artifact Identities are always relative to a Component Version and may only be used in conjunction with a Component Identity.\nIn detail:\nComponent Identity Component Name: Identifies a component. Must start with URL-prefix that should be controlled by the owner of the component to avoid collisions. Component Version: If used with a Component name, identifies a specific Component Version. Must adhere to \u0026ldquo;relaxed SemVer\u0026rdquo; (major, minor (+ optional patch level) - optional v-prefix). Artifact Identity Within a Component Version, all Artifacts must have a unique identity. Every Source Identity or Resource Identity always includes a name that typically expresses the intended purpose.\nArtifacts may also have additional extraIdentity attributes that contribute to their identities. extraIdentity attributes are string-to-string maps.\nExamples Assuming there is a component named example.org/my-component with two versions, 1.2.3 and 1.3.0, declaring a resource with the name my-resource, the following OCM Coordinates can be used to reference different elements:\nexample.org/my-component: all versions of the component (1.2.3 + 1.3.0) example.org/my-component:1.2.3: version 1.2.3 of the component example.org/my-component:1.2.3:resource/my-resource: my-resource as declared by the component version ","date":"2020-10-06","id":6,"permalink":"/docs/overview/important-terms/","summary":"\u003cp\u003eAs the Open Component Model (OCM) revolves around components, it is essential to establish a common understanding of the fundamental terminology employed throughout this website. The following section provides concise definitions of key terms, laying the groundwork for the documentation and tutorials that follow.\u003c/p\u003e","tags":[],"title":"Important Terms"},{"content":"Where to find the OCM specification The most up-to-date version of the OCM specification offers you a deep insight to all technical details of the Open Component Model and explains all elements the model OCM is based on.\n","date":"0001-01-01","id":7,"permalink":"/docs/overview/specification/","summary":"\u003ch2 id=\"where-to-find-the-ocm-specification\"\u003eWhere to find the OCM specification\u003c/h2\u003e\n\u003cp\u003eThe most up-to-date version of the \u003ca href=\"https://github.com/open-component-model/ocm-spec/blob/main/README.md\"\u003eOCM specification\u003c/a\u003e offers you a deep insight to all technical details of the Open Component Model and explains all elements the model OCM is based on.\u003c/p\u003e","tags":[],"title":"Specification"},{"content":"","date":"2023-11-07","id":8,"permalink":"/docs/getting-started/","summary":"","tags":[],"title":"Getting Started"},{"content":"Overview You can install the latest release of the OCM CLI from any of the following sources (more details below):\nHomebrew Nix AUR Docker Podman GitHub Releases Bash To install with bash for macOS or Linux, execute the following command:\ncurl -s https://ocm.software/install.sh | sudo bash\rInstall using Homebrew # Homebrew (macOS and Linux) brew install open-component-model/tap/ocm\rInstall using Nix (with Flakes) # Nix (macOS, Linux, and Windows) # ad hoc cmd execution nix run github:open-component-model/ocm -- --help nix run github:open-component-model/ocm#helminstaller -- --help # install development version nix profile install github:open-component-model/ocm # or release \u0026lt;version\u0026gt; nix profile install github:open-component-model/ocm/\u0026lt;version\u0026gt; #check installation nix profile list | grep ocm # optionally, open a new shell and verify that cmd completion works ocm --help\rsee: Flakes\nInstall from AUR (Arch Linux User Repository) git-url: https://aur.archlinux.org/ocm-cli.git package-url: https://aur.archlinux.org/packages/ocm-cli\n# if not using a helper util git clone https://aur.archlinux.org/ocm-cli.git cd ocm-cli makepkg -i\rAUR Documentation\nInstall using Docker / Podman podman run -t ghcr.io/open-component-model/ocm:latest --help\rBuild and Run It Yourself podman build -t ocm . podman run --rm -t ocm --loglevel debug --help\ror interactively:\npodman run --rm -it ocm /bin/sh\rYou can pass in the following arguments to override the predefined defaults:\nGO_VERSION: The golang version to be used for compiling. ALPINE_VERSION: The alpine version to be used as the base image. GO_PROXY: Your go proxy to be used for fetching dependencies. Please check hub.docker.com for possible version combinations.\npodman build -t ocm --build-arg GO_VERSION=1.22 --build-arg ALPINE_VERSION=3.19 --build-arg GO_PROXY=https://proxy.golang.org .\ron MS Windows using Chocolatey choco install ocm-cli\rsee: chocolatey community package: ocm-cli\nusing winget winget install ocm-cli\rsee: microsoft/winget-pkgs: Open-Component-Model\nBuilding from Source Prerequisites git golang make Installation Process Clone the open-component-model/ocm repo:\ngit clone https://github.com/open-component-model/ocm\rEnter the repository directory (cd ocm/) and install the cli using make:\nmake install\rPlease note that the OCM CLI is installed in your go/bin directory, so you might need to add this directory to your PATH.\nVerify the installation:\nocm version\r","date":"0001-01-01","id":9,"permalink":"/docs/getting-started/installing-the-ocm-cli/","summary":"\u003ch2 id=\"overview\"\u003eOverview\u003c/h2\u003e\n\u003cp\u003eYou can install the latest release of the OCM CLI from any of the following sources (more details below):\u003c/p\u003e","tags":[],"title":"Installing the OCM CLI"},{"content":"","date":"2023-03-13","id":10,"permalink":"/docs/getting-started/getting-started-with-ocm/","summary":"","tags":[],"title":"First Steps with OCM"},{"content":"This and the following chapters walk you through some basic steps to get started with OCM concepts and the OCM CLI. You will learn how to create a component version, display and examine the component, and how to transport and sign it.\nTo follow the steps described in this section, you will need to:\nInstall the OCM Command Line Interface (CLI) The CLI is used to interact with component versions and registries. Install it like described in Installing the OCM CLI.\nObtain Access to an OCM Repository This can be any OCI registry for which you have write permission (e.g., GitHub Packages). An OCM repository based on an OCI registry is identified by a leading OCI repository prefix. For example: ghcr.io/\u0026lt;YOUR-ORG\u0026gt;/ocm.\nObtain Credentials for the CLI to Access the OCM Repository Using the Docker Configuration File The easiest way to do this is to reuse your Docker configuration json file.\nTo do this, create a file named .ocmconfig in your home directory with the following content:\ntype: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software repositories: - repository: type: DockerConfig/v1 # The path to the Docker configuration file dockerConfigFile: \u0026#34;~/.docker/config.json\u0026#34; propagateConsumerIdentity: true - type: attributes.config.ocm.software attributes: cache: ~/.ocm/cache\rUsing Basic Authentication Alternatively, you can use basic authentication. Create a file named .ocmconfig in your home directory with the following content:\ntype: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software consumers: - identity: type: ociRegistry hostname: \u0026lt;YOUR-REGISTRY\u0026gt;/\u0026lt;YOUR-REPO\u0026gt; # e.g. ghcr.io/acme/acme credentials: - type: Credentials properties: username: \u0026lt;YOUR-USERNAME\u0026gt; password: \u0026lt;YOUR-PASSWORD\u0026gt;\rMore information on the credentials topic can be seen by running the OCM CLI help topic command ocm credential-handling and in this guide with many examples for different repository types.\n","date":"2023-03-13","id":11,"permalink":"/docs/getting-started/getting-started-with-ocm/prerequisites/","summary":"\u003cp\u003eThis and the following chapters walk you through some basic steps to get started with OCM concepts and the OCM CLI.\nYou will learn how to create a component version, display and examine the component, and how to transport and sign it.\u003c/p\u003e","tags":[],"title":"Prerequisites"},{"content":"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.\nComponent Versions are locally stored in archives using the Common Transfer Format (CTF). A CTF archive is also the entity used to transfer components between component repositories. A CTF archive may contain any number of component versions. It may also be pushed to an OCM repository.\nNote that a CTF archive itself is also an OCM repository, so it can be used as source or target for component transfer operations.\nThe command ocm add componentversions directly creates a component version from a component-constructor.yaml file and stores it in a CTF archive.\nCreate 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.\nWe start by creating a test folder where we execute all required steps for this example and navigating into it:\nmkdir /tmp/helloworld cd /tmp/helloworld\rNow we download the podinfo Helm Chart that we want to use as local resource and extract it:\nhelm repo add podinfo https://stefanprodan.github.io/podinfo helm pull --untar podinfo/podinfo\rCreate 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). As mentioned before our example component should contain a Helm Chart and a Docker image:\n# specify a schema to validate the configuration and get auto-completion in your editor # yaml-language-server: $schema=https://ocm.software/schemas/configuration-schema.yaml components: - name: github.com/acme.org/helloworld version: 1.0.0 provider: name: acme.org resources: # local Helm chart resource - name: mychart type: helmChart input: type: helm path: ./podinfo # remote image resource - name: image type: ociArtifact version: 1.0.0 access: type: ociArtifact imageReference: gcr.io/google_containers/echoserver:1.10\rA resource is described either by its access information to a remote repository or by locally provided resources.\nFor remote access, the field access is used to describe the access method. The type field is used to specify the kind of access.\nIf 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.\nAvailable access and input types are described here.\nFor more complex scenarios, the description files might use variable substitution (templating), see Best Practices.\nAdd Component Version to CTF archive To store our component version 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:\nocm add componentversions --create --file ctf-hello-world component-constructor.yaml\rprocessing component-constructor.yaml... processing document 1... processing index 1 found 1 component adding component github.com/acme.org/helloworld:1.0.0... adding resource helmChart: \u0026#34;name\u0026#34;=\u0026#34;mychart\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;\u0026lt;componentversion\u0026gt;\u0026#34;... adding resource ociArtifact: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;1.0.0\u0026#34;...\rWhat happened? The command creates the CTF archive (option --create) and adds the listed components with the described resources.\nctf-hello-world/ ├── artifact-index.json └── blobs ├── sha256.125cf912d0f67b2b49e4170e684638a05a12f2fcfbdf3571e38a016273620b54 ├── sha256.1cb2098e31e319df7243490464b48a8af138389abe9522c481ebc27dede4277b ├── sha256.974e652250ffaba57b820c462ce603fc1028a608b0fa09caef227f9e0167ce09 └── sha256.d442bdf33825bace6bf08529b6f00cf0aacc943f3be6130325e1eb4a5dfae3a5\rThe transport archive\u0026rsquo;s contents can be found in artifact-index.json. This file contains the list of component version artifacts to be transported.\njq . ${CTF_ARCHIVE}/artifact-index.json\r{ \u0026#34;schemaVersion\u0026#34;: 1, \u0026#34;artifacts\u0026#34;: [ { \u0026#34;repository\u0026#34;: \u0026#34;component-descriptors/github.com/acme/helloworld\u0026#34;, \u0026#34;tag\u0026#34;: \u0026#34;1.0.0\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:d3cf4858f5387eaea194b7e40b7f6eb23460a658ad4005c5745361978897e043\u0026#34; } ] }\rThe 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/.\nThe component version is described as an OCI manifest:\njq . ${CTF_ARCHIVE}/blobs/sha256.d3cf4858f5387eaea194b7e40b7f6eb23460a658ad4005c5745361978897e043\r{ \u0026#34;schemaVersion\u0026#34;: 2, \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.manifest.v1+json\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.ocm.software.component.config.v1+json\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:0dd94de11c17f995648c8e817971581bce4b016f53d4d2bf2fff9fcda37d7b95\u0026#34;, \u0026#34;size\u0026#34;: 201 }, \u0026#34;layers\u0026#34;: [ { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.ocm.software.component-descriptor.v2+yaml+tar\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:4ab29c8acb0c8b002a5037e6d9edf2d657222da76fee2a10f38d65ecd981d0c6\u0026#34;, \u0026#34;size\u0026#34;: 3072 }, { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.manifest.v1+tar+gzip\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:b2dc5088f005d27ea39b427c2e67e91e2b6b80d3e85eca2476a019003c402904\u0026#34;, \u0026#34;size\u0026#34;: 16122 } ] }\rNotice 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:\ntar xvf ${CTF_ARCHIVE}/blobs/sha256.4ab29c8acb0c8b002a5037e6d9edf2d657222da76fee2a10f38d65ecd981d0c6 -O - component-descriptor.yaml\rmeta: schemaVersion: v2 component: name: github.com/acme/helloworld version: 1.0.0 provider: acme.org componentReferences: [] repositoryContexts: [] resources: - access: localReference: sha256:b2dc5088f005d27ea39b427c2e67e91e2b6b80d3e85eca2476a019003c402904 mediaType: application/vnd.oci.image.manifest.v1+tar+gzip referenceName: github.com/acme/helloworld/podinfo:6.7.0 type: localBlob digest: ... name: mychart relation: local type: helmChart version: 1.0.0 - access: imageReference: gcr.io/google_containers/echoserver:1.10 type: ociArtifact digest: ... name: image relation: external type: ociArtifact version: 1.0.0 sources: []\rThe 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.\n","date":"2023-03-13","id":12,"permalink":"/docs/getting-started/getting-started-with-ocm/create-a-component-version/","summary":"\u003ch2 id=\"creating-and-storing-component-versions\"\u003eCreating and Storing Component Versions\u003c/h2\u003e\n\u003cp\u003eComponent Versions are created using a \u003ccode\u003ecomponent-constructor.yaml\u003c/code\u003e 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.\u003c/p\u003e","tags":[],"title":"Create a Component Version"},{"content":"List Component Versions To show a component stored in an OCM repository or CTF archive (which itself is an OCM repository), the ocm get componentversion command can be used:\nocm get componentversion ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0\rCOMPONENT VERSION PROVIDER ocm.software/toi/demo/helmdemo 0.12.0 ocm.software\rTo see the component descriptor of the displayed component version, use the output format option -o yaml:\nocm get cv ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 -o yaml\rcomponent: componentReferences: - componentName: ocm.software/toi/installers/helminstaller name: installer version: 0.12.0 creationTime: \u0026#34;2024-07-19T14:32:13Z\u0026#34; name: ocm.software/toi/demo/helmdemo provider: ocm.software repositoryContexts: - baseUrl: ghcr.io componentNameMapping: urlPath subPath: open-component-model/ocm type: OCIRegistry resources: - access: localReference: sha256:8a2fe6af4ce56249094622c9d618e24b4cfb461a7dfa6a42cce31749189bc499 mediaType: application/vnd.toi.ocm.software.package.v1+yaml type: localBlob digest: ... labels: - name: commit value: e5ca3001323b75ee5793a786089f1f410e9e8db3 name: package relation: local type: toiPackage version: 0.12.0 - access: imageReference: ghcr.io/open-component-model/ocm/ocm.software/toi/demo/helmdemo/echoserver:0.1.0 type: ociArtifact digest: ... name: chart relation: local type: helmChart version: 0.12.0 ...\rTo refer to the content of a component repository, the component name can be appended to the repository specification separated by // (you can also use the --repo option to specifiy the repository).\nIn the example above, ghcr.io/open-component-model/ocm is the OCM repository, whereas ocm.software/toi/demo/helmdemo is the component stored in this component repository.\nOptionally, a specific version can be appended, separated by a colon (:). If no version is specified, all component versions will be displayed.\nWith the option --recursive, it is possible to show the complete component version, including the component versions it references.\nocm get cv ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 --recursive\rREFERENCEPATH COMPONENT VERSION PROVIDER IDENTITY ocm.software/toi/demo/helmdemo 0.12.0 ocm.software ocm.software/toi/demo/helmdemo:0.12.0 ocm.software/toi/installers/helminstaller 0.12.0 ocm.software \u0026#34;name\u0026#34;=\u0026#34;installer\u0026#34;\rTo get a tree view, add the option -o tree:\nocm get cv ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 --recursive -o tree\rNESTING COMPONENT VERSION PROVIDER IDENTITY └─ ⊗ ocm.software/toi/demo/helmdemo 0.12.0 ocm.software └─ ocm.software/toi/installers/helminstaller 0.12.0 ocm.software \u0026#34;name\u0026#34;=\u0026#34;installer\u0026#34;\rAs mentioned before a CTF archive itself is an OCM repository, so we can execute the same commands on a CTF archive. So, let\u0026rsquo;s get the information about the component github.com/acme.org/helloworld we created in the previous step and that we stored in the CTF archive /tmp/helloworld/ctf-hello-world:\nocm get cv /tmp/helloworld/ctf-hello-world//github.com/acme.org/helloworld:1.0.0\rCOMPONENT VERSION PROVIDER github.com/acme.org/helloworld 0.1.0 ocm.software\rList the Resources of a Component Version To list the resources found in a component version tree, the command ocm get resources can be used:\nocm get resources ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 --recursive -o tree\rCOMPONENT NAME VERSION IDENTITY TYPE RELATION └─ ocm.software/toi/demo/helmdemo 0.12.0 ├─ chart 0.12.0 helmChart local ├─ config-example 0.12.0 yaml local ├─ creds-example 0.12.0 yaml local ├─ image 1.0 ociImage external ├─ package 0.12.0 toiPackage local └─ ocm.software/toi/installers/helminstaller installer 0.12.0 ├─ toiexecutor 0.12.0 toiExecutor local └─ toiimage 0.12.0 ociImage local\rDownload the Resources of a Component Version Use the ocm download command to download resources such as component versions, individual resources or artifacts:\nocm download resource ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 chart -O helmchart.tgz\rhelmchart.tgz: 4707 byte(s) written\rBecause it is stored as OCI artifact in an OCI registry, the filesystem format used for OCI artifacts is the blob format.\nWhat happened? The file helmchart.tgz was downloaded.\ntar xvf helmchart.tgz\rx index.json x oci-layout x blobs x blobs/sha256.a9dd654eed17e786b5c5445e8bc48f3a47371c2efe392a53a3fbecd9e942b696 x blobs/sha256.c8017985866ceb44c2426a4ad9a429d6aec1f6818cb6dccbf964623139c1d1d5 x blobs/sha256.ea8e5b44cd1aff1f3d9377d169ad795be20fbfcd58475a62341ed8fb74d4788c\r$ jq . index.json\r{ \u0026#34;schemaVersion\u0026#34;: 2, \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.index.v1+json\u0026#34;, \u0026#34;manifests\u0026#34;: [ { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.manifest.v1+json\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:c8017985866ceb44c2426a4ad9a429d6aec1f6818cb6dccbf964623139c1d1d5\u0026#34;, \u0026#34;size\u0026#34;: 410, \u0026#34;annotations\u0026#34;: { \u0026#34;org.opencontainers.image.ref.name\u0026#34;: \u0026#34;0.1.0\u0026#34;, \u0026#34;software.ocm/tags\u0026#34;: \u0026#34;0.1.0\u0026#34; } } ], \u0026#34;annotations\u0026#34;: { \u0026#34;software.ocm/main\u0026#34;: \u0026#34;sha256:c8017985866ceb44c2426a4ad9a429d6aec1f6818cb6dccbf964623139c1d1d5\u0026#34; } }\rDownload with Download Handlers To use a format more suitable for the content technology, enable the usage of download handlers.\nIf a download handler is available for the artifact type and the blob media type used to store the blob in the OCM repository, it will convert the blob format into a more suitable format:\nocm download resource -d ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 chart -O helmchart.tgz\rhelmchart.tgz: 3763 byte(s) written\rWhat happened? The downloaded archive is now a regular Helm Chart archive:\ntar tvf helmchart.tgz\r-rw-r--r-- 0 0 0 136 Jul 19 16:32 echoserver/Chart.yaml -rw-r--r-- 0 0 0 1842 Jul 19 16:32 echoserver/values.yaml -rw-r--r-- 0 0 0 1755 Jul 19 16:32 echoserver/templates/NOTES.txt -rw-r--r-- 0 0 0 1802 Jul 19 16:32 echoserver/templates/_helpers.tpl -rw-r--r-- 0 0 0 1848 Jul 19 16:32 echoserver/templates/deployment.yaml -rw-r--r-- 0 0 0 922 Jul 19 16:32 echoserver/templates/hpa.yaml -rw-r--r-- 0 0 0 2083 Jul 19 16:32 echoserver/templates/ingress.yaml -rw-r--r-- 0 0 0 367 Jul 19 16:32 echoserver/templates/service.yaml -rw-r--r-- 0 0 0 324 Jul 19 16:32 echoserver/templates/serviceaccount.yaml -rw-r--r-- 0 0 0 385 Jul 19 16:32 echoserver/templates/tests/test-connection.yaml -rw-r--r-- 0 0 0 349 Jul 19 16:32 echoserver/.helmignore\rDownload an Image For example, for OCI images, the OCI format is more suitable:\nocm download resource ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 image -O image.tgz\rimage.tgz: 46181313 byte(s) written\rWhat happened? The file image.tgz was downloaded.\ntar xvf image.tgz\rx index.json x oci-layout x blobs x blobs/sha256.06679f57dba70a6875e4ae5843ba2483ecab6ec48182ca8720ddc5b1863bad52 x blobs/sha256.28c6282d04f63710146ace6c7be14a40c7ee6a71a2f91316928469e4aafe0d92 x blobs/sha256.2d3e25b9e93ad26878862abee5ed02683206f6f6d57e311cdd1dedf3662b61c8 x blobs/sha256.365ec60129c5426b4cf160257c06f6ad062c709e0576c8b3d9a5dcc488f5252d x blobs/sha256.4b12f3ef8e65aaf1fd77201670deb98728a8925236d8f1f0473afa5abe9de119 x blobs/sha256.76d46396145f805d716dcd1607832e6a1257aa17c0c2646a2a4916e47059dd54 x blobs/sha256.7fd34bf149707ca78b3bb90e4ba68fe9a013465e5d03179fb8d3a3b1cac8be27 x blobs/sha256.b0e3c31807a2330c86f07d45a6d80923d947a8a66745a2fd68eb3994be879db6 x blobs/sha256.bc391bffe5907b0eaa04e96fd638784f77d39f1feb7fbe438a1dae0af2675205 x blobs/sha256.cb5c1bddd1b5665e1867a7fa1b5fa843a47ee433bbb75d4293888b71def53229 x blobs/sha256.d5157969118932d522396fe278eb722551751c7aa7473e6d3f03e821a74ee8ec x blobs/sha256.e0962580d8254d0b1ef35006d7e2319eb4870e63dc1f9573d2406c7c47d442d2\rjq . index.json\r{ \u0026#34;schemaVersion\u0026#34;: 2, \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.index.v1+json\u0026#34;, \u0026#34;manifests\u0026#34;: [ { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.docker.distribution.manifest.v2+json\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:cb5c1bddd1b5665e1867a7fa1b5fa843a47ee433bbb75d4293888b71def53229\u0026#34;, \u0026#34;size\u0026#34;: 2400, \u0026#34;annotations\u0026#34;: { \u0026#34;org.opencontainers.image.ref.name\u0026#34;: \u0026#34;1.10\u0026#34;, \u0026#34;software.ocm/tags\u0026#34;: \u0026#34;1.10\u0026#34; } } ], \u0026#34;annotations\u0026#34;: { \u0026#34;software.ocm/main\u0026#34;: \u0026#34;sha256:cb5c1bddd1b5665e1867a7fa1b5fa843a47ee433bbb75d4293888b71def53229\u0026#34; } }\rDownload an Executable The Open Component Model allows to publish platform-specific executables. In this case, the platform specification is used by convention as extra identity for the artifacts that are contained in the component version.\nExample:\nocm get componentversion ghcr.io/open-component-model/ocm//ocm.software/ocmcli:0.1.0-dev -o yaml\r... resources: - name: ocmcli extraIdentity: architecture: amd64 os: linux relation: local type: executable version: 0.1.0-dev access: localReference: sha256:1a8827761f0aaa897d1d4330c845121c157e905d1ff300ba5488f8c423bc7cd9 mediaType: application/octet-stream type: localBlob - name: ocmcli extraIdentity: architecture: arm64 os: darwin relation: local type: executable version: 0.1.0-dev access: localReference: sha256:9976b18dc16ae2b2b3fc56686f18f4896d44859f1ea6221f70e83517f697e289 mediaType: application/octet-stream type: localBlob ...\rNote that the resources shown above have the same name and type executable but a different extra-identity. If a component version complies to this convention, executables can directly be downloaded for the specified platform with the use of the -x option. If only one executable is contained in the component version, the resource name can be omitted. Example:\nocm download resource -x --latest ghcr.io/open-component-model/ocm//ocm.software/ocmcli\rocm: 83369938 byte(s) written\rWhat happened? file ocm\rocm: Mach-O 64-bit executable arm64\rWith the option --latest, the latest matching component version is used for download. With the option --constraints, version constraints can be configured. For example: --constraints 0.1.x will select all patch versions of 0.1. Together with --latest, the latest patch version is selected.\nThe option -x enables the executable download handler, which provides the x-bit of the downloaded files. Additionally, it filters all matching resources for executables and the correct platform.\nDownload a Full Component Version Download entire component versions using the ocm download componentversion command:\nocm download componentversions ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 -O helloworld\rhelloworld: downloaded\rThe result is a CTF archive. This can then be modified using the ocm add ... commands shown earlier.\nWhat happened? The component version was downloaded.\ntree helloworld\rhelloworld/ ├── blobs │ ├── sha256.87cef1e2233bf5591030ac854e2556fbe6a00a28bb5640e25a9cb69ece519c5a │ ├── sha256.8a2fe6af4ce56249094622c9d618e24b4cfb461a7dfa6a42cce31749189bc499 │ └── sha256.e790920a11de2016de64225280efcf062e14b767955f7508de64fd5192e3fb3a └── component-descriptor.yaml\rDownload OCI Artifacts Download OCI artifacts from an OCI registry, such as OCI images, with the ocm download artifacts command:\nocm download artifact ghcr.io/open-component-model/ocm-controller:v0.24.0 -O ocm-controller\rocm-controller: downloaded\rWhat happened? The OCI image echoserver was downloaded.\ntree echoserver\rocm-controller/ ├── blobs │ ├── sha256.05d57e68048827c243cd477025f96064df9f4d83b8639ed04306f0647c9cfe78 │ ├── sha256.0f8b424aa0b96c1c388a5fd4d90735604459256336853082afb61733438872b5 │ ├── sha256.1069fc2daed1aceff7232f4b8ab21200dd3d8b04f61be9da86977a34a105dfdc │ ├── sha256.286c61c9a31ace5fa0b8832c8e8e30d66bf32138f2f787463235aa0071f714ea │ ├── sha256.2bdf44d7aa71bf3a0da2de0563ad0e3882948d699b4991edf8c0ab44e7f26ae3 │ ├── sha256.35fddc32f468fc8d276fa1b6a72cac27f35a0080233c2ddc6a03fab224024dbc │ ├── sha256.3f4e2c5863480125882d92060440a5250766bce764fee10acdbac18c872e4dc7 │ ├── sha256.452e9eed7ecfd0c2b44ac6fda20cee66ab98aec38ba30aa868e02445be7c8bb0 │ ├── sha256.80a8c047508ae5cd6a591060fc43422cb8e3aea1bd908d913e8f0146e2297fea │ ├── sha256.9375d0c4fac611287075434624a464af5b6bb026947698a06577ad348f607d56 │ ├── sha256.b40161cd83fc5d470d6abe50e87aa288481b6b89137012881d74187cfbf9f502 │ ├── sha256.c8022d07192eddbb2a548ba83be5e412f7ba863bbba158d133c9653bb8a47768 │ ├── sha256.d557676654e572af3e3173c90e7874644207fda32cd87e9d3d66b5d7b98a7b21 │ └── sha256.d858cbc252ade14879807ff8dbc3043a26bbdb92087da98cda831ee040b172b3 ├── index.json └── oci-layout\r","date":"2023-03-13","id":13,"permalink":"/docs/getting-started/getting-started-with-ocm/display-and-examine-component-versions/","summary":"\u003ch2 id=\"list-component-versions\"\u003eList Component Versions\u003c/h2\u003e\n\u003cp\u003eTo show a component stored in an OCM repository or CTF archive (which itself is an OCM repository), the \u003ca href=\"https://github.com/open-component-model/ocm/blob/main/docs/reference/ocm_get_componentversions.md\"\u003e\u003ccode\u003eocm get componentversion\u003c/code\u003e\u003c/a\u003e command can be used:\u003c/p\u003e","tags":[],"title":"Display and Examine Component Versions"},{"content":"The section Bundle Composed Components explained how to bundle multiple component version into a transport archive.\nDuring the transfer, it is possible to include component references as local blobs. It is also possible to include references in a recursive way.\nHere is an example of a recursive transfer from one OCI registry to another, which includes resources and references:\nocm transfer componentversion --recursive --copy-resources ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 another-registry/\rtransferring version \u0026#34;ocm.software/toi/demo/helmdemo:0.12.0\u0026#34;... transferring version \u0026#34;ocm.software/toi/installers/helminstaller:0.12.0\u0026#34;... ...resource 0 toiimage[ociImage](ocm.software/toi/installers/helminstaller/helminstaller:0.12.0)... ...resource 1 toiexecutor[toiExecutor]... ...adding component version... ...resource 0 package[toiPackage]... ...resource 1 chart[helmChart](ocm.software/toi/demo/helmdemo/echoserver:0.1.0)... ...resource 2 image[ociImage](google-containers/echoserver:1.10)... ...resource 3 config-example[yaml]... ...resource 4 creds-example[yaml]... ...adding component version... 2 versions transferred\rThe OCM CLI\u0026rsquo;s transfer command can be used to transfer component versions, component archives, transport archives, and artifacts. See ocm transfer -h for more information.\nMore examples on the transport archive and the common transfer format (CTF) can be found in the ocm-spec.\n","date":"2023-03-13","id":14,"permalink":"/docs/getting-started/getting-started-with-ocm/transport-ocm-component-versions/","summary":"\u003cp\u003eThe section \u003ca href=\"/docs/getting-started/getting-started-with-ocm/create-a-component-version#bundle-composed-components\"\u003eBundle Composed Components\u003c/a\u003e explained how to bundle multiple component version into a transport archive.\u003c/p\u003e\n\u003cp\u003eDuring the transfer, it is possible to include component references as local blobs. It is also possible to include references in a recursive way.\u003c/p\u003e","tags":[],"title":"Transport OCM Component Versions"},{"content":"Component versions can be signed to ensure integrity along a transport chain.\nSigning requires a key pair, a signature, and, optionally, an issuer, as well as an algorithm and a name for the signature.\nA component version can have multiple signatures with different names. A normalization of the component version is used for signing. See Signing Process and Normalization for more details. Currently, only signing according to the RSA PKCS #1 v1.5 signature algorithm is supported.\nTo follow the examples, one must follow the instructions from the section Create a Component Version.\nCreate a key pair using the OCM CLI:\nocm create rsakeypair acme.priv\rcreated rsa key pair acme.priv[acme.pub]\rThis creates two files. One named acme.priv for the private key and for convenience one named acme.pub for the public key.\nUse the sign componentversion command to sign a component version:\nocm sign componentversion --signature acme-sig --private-key=acme.priv ${OCM_REPO}//${COMPONENT}:${VERSION}\rapplying to version \u0026#34;github.com/acme/helloworld:1.0.0\u0026#34;[github.com/acme/helloworld:1.0.0]... resource 0: \u0026#34;name\u0026#34;=\u0026#34;mychart\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] resource 1: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] successfully signed github.com/acme/helloworld:1.0.0 (digest SHA-256:...)\rYou can also sign a common transport archive before uploading to a component repository:\nocm sign componentversion --signature acme-sig --private-key=acme.priv ${CTF_ARCHIVE}\rapplying to version \u0026#34;github.com/acme.org/helloworld:1.0.0\u0026#34;[github.com/acme.org/helloworld:1.0.0]... resource 0: \u0026#34;name\u0026#34;=\u0026#34;mychart\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] resource 1: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] successfully signed github.com/acme.org/helloworld:1.0.0 (digest SHA-256:...)\rWhat happened? Digests will be created for all described artifacts and referenced component versions. Then for the top-level component versions, the component-version digests are signed. The signature and digests are stored in the component descriptor(s):\njq . ${CTF_ARCHIVE}/artifact-index.json\r{ \u0026#34;schemaVersion\u0026#34;: 1, \u0026#34;artifacts\u0026#34;: [ { \u0026#34;repository\u0026#34;: \u0026#34;component-descriptors/github.com/acme.org/helloworld\u0026#34;, \u0026#34;tag\u0026#34;: \u0026#34;1.0.0\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:02b12782d66fc6504f0003bb11a8e2610ac8f3d616bc1a4545df17a6e9aca5c6\u0026#34; } ] }\rBeside the digests of the component descriptor layer, nothing has changed:\njq . ${CTF_ARCHIVE}/blobs/sha256.02b12782d66fc6504f0003bb11a8e2610ac8f3d616bc1a4545df17a6e9aca5c6\r{ \u0026#34;schemaVersion\u0026#34;: 2, \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.manifest.v1+json\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.ocm.software.component.config.v1+json\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:38ba9898cb8d2c5ad34274549632836b391f5acc96268f0276d6857e87b97141\u0026#34;, \u0026#34;size\u0026#34;: 201 }, \u0026#34;layers\u0026#34;: [ { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.ocm.software.component-descriptor.v2+yaml+tar\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:c9705f0045f91c2cba49ce922dd65da27e66796e3a1fdc7a6fc01058357f2cd4\u0026#34;, \u0026#34;size\u0026#34;: 3584 }, { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.manifest.v1+tar+gzip\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:125cf912d0f67b2b49e4170e684638a05a12f2fcfbdf3571e38a016273620b54\u0026#34;, \u0026#34;size\u0026#34;: 16119 } ] }\rtar xvf ${CTF_ARCHIVE}/blobs/sha256.c9705f0045f91c2cba49ce922dd65da27e66796e3a1fdc7a6fc01058357f2cd4 -O - component-descriptor.yaml\rmeta: schemaVersion: v2 component: name: github.com/acme.org/helloworld version: 1.0.0 provider: acme.org componentReferences: [] repositoryContexts: [] resources: - access: localReference: sha256:125cf912d0f67b2b49e4170e684638a05a12f2fcfbdf3571e38a016273620b54 mediaType: application/vnd.oci.image.manifest.v1+tar+gzip referenceName: github.com/acme.org/helloworld/podinfo:6.7.0 type: localBlob digest: ... name: mychart relation: local type: helmChart version: 1.0.0 - access: imageReference: gcr.io/google_containers/echoserver:1.10 type: ociArtifact digest: ... name: image relation: external type: ociArtifact version: 1.0.0 sources: [] signatures: - digest: ... name: acme-sig signature: algorithm: RSASSA-PKCS1-V1_5 mediaType: application/vnd.ocm.signature.rsa value: ...\rSigning with Certificates The public key from the last example cannot be validated. This can be changed by using a certificate instead of a pure public key. The certificate is signed by a CA. This ensures the authenticity of the described public key. Additionally, the common name of the certificate is validated against the issuer attribute of the signature stored in the component descriptor.\nThe following example creates a CA and signing certificates that are used to sign a component version.\nCreate the root CA:\nocm create rsakeypair --ca CN=certificate-authority root.priv\rcreated rsa key pair root.priv[root.cert]\rCreate the CA that is used to create signing certificates:\nocm create rsakeypair --ca CN=acme.org --ca-key root.priv --ca-cert root.cert ca.priv\rcreated rsa key pair ca.priv[ca.cert]\rCreate signing certificates from the CA:\nocm create rsakeypair CN=acme.org C=DE --ca-key ca.priv --ca-cert ca.cert --root-certs root.cert key.priv\rcreated rsa key pair key.priv[key.cert]\rYou can use additional attributes of the certificate like O, OU or C. See usage for details. The certificate can be requested by any official certificate authority instead. It requires the usage types x509.KeyUsageDigitalSignature and x509.ExtKeyUsageCodeSigning.\nFor signing the component version you need to provide the issuer, then run:\nocm sign componentversion ${CTF_ARCHIVE} --private-key key.priv --public-key key.cert --ca-cert root.cert --signature acme.org --issuer CN=acme.org\rapplying to version \u0026#34;github.com/acme.org/helloworld:1.0.0\u0026#34;[github.com/acme.org/helloworld:1.0.0]... resource 0: \u0026#34;name\u0026#34;=\u0026#34;mychart\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] resource 1: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] successfully signed github.com/acme.org/helloworld:1.0.0 (digest SHA-256:...)\rNow the issuer will be stored along the signature and will be checked when verifying with the certificate instead of the public key.\nSignature Verification You can verify a signed component version. Therefore, a public key or a certificate provided by the signer is required. If a certificate is provided, it is validated according to its certificate chain. If an official CA is used instead, you need the certificate of the used root CA.\nIf you followed the previous examples, you can verify the signature of a component version as follows:\nocm verify componentversions --signature acme-sig --public-key=acme.pub ${OCM_REPO}//${COMPONENT}:${VERSION}\rapplying to version \u0026#34;github.com/acme/helloworld:1.0.0\u0026#34;[github.com/acme/helloworld:1.0.0]... resource 0: \u0026#34;name\u0026#34;=\u0026#34;mychart\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] resource 1: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] successfully verified github.com/acme/helloworld:1.0.0 (digest SHA-256:...)\rocm verify component ${CTF_ARCHIVE} --ca-cert root.cert --issuer CN=acme.org\rapplying to version \u0026#34;github.com/acme.org/helloworld:1.0.0\u0026#34;[github.com/acme.org/helloworld:1.0.0]... resource 0: \u0026#34;name\u0026#34;=\u0026#34;mychart\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] resource 1: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] no public key found for signature \u0026#34;acme.org\u0026#34; -\u0026gt; extract key from signature successfully verified github.com/acme.org/helloworld:1.0.0 (digest SHA-256:...)\r","date":"2023-03-13","id":15,"permalink":"/docs/getting-started/getting-started-with-ocm/sign-component-versions/","summary":"\u003cp\u003eComponent versions can be signed to ensure integrity along a transport chain.\u003c/p\u003e\n\u003cp\u003eSigning requires a key pair, a signature, and, optionally, an issuer, as well as an algorithm and a\nname for the signature.\u003c/p\u003e","tags":[],"title":"Sign Component Versions"},{"content":"","date":"2020-10-06","id":16,"permalink":"/docs/controller/","summary":"","tags":[],"title":"OCM Controllers"},{"content":"This document explains the architecture of the OCM Kubernetes Controller Set (KCS). The purpose of the KCS is to enable the automated deployment of components using Kubernetes and Flux.\nThe following functions are provided as part of the KCS:\nReplication: replication of components from one OCM repository to another Signature Verification: verification of component signatures before resources are reconciled Resource Reconciliation: individual resources can be extracted from a component and reconciled to machines internal or external to the cluster Resource transformation: resource localization \u0026amp; configuration can be performed out of the box, with any other kind of modification supported via an extensible architecture Component unpacking: multiple resources can be extracted from a component and transformed with a common set of user definable operations Git synchronization: resources extracted from a component can be pushed to a git repository One of the central design decisions underpinning KCS is that resources should be composable. To this end we have introduced the concept of Snapshots; snapshots are immutable, Flux-compatible, single layer OCI images containing a single OCM resource. Snapshots are stored in an in-cluster registry and in addition to making component resources accessible for transformation, they also can be used as a caching mechanism to reduce unnecessary calls to the source OCM registry.\nControllers The KCS consists of the following controllers:\nOCM controller Replication controller Git sync controller OCM controller The ocm-controller is responsible for the core work necessary to utilise resources from an OCM component in a Kubernetes cluster. This includes resolving ComponentDescriptor metadata for a particular component version, performing authentication to OCM repositories, retrieving artifacts from OCM repositories, making individual resources from the OCM component available within the cluster, performing localization and configuration.\nSnapshots are used to pass resources between controllers and are stored in an in-cluster registry.\nThe ocm-controller consists of 5 sub-controllers:\nComponent Version Controller Resource Controller Snapshot Controller Localization Controller Configuration Controller FluxDeployer Controller Component Version Controller The Component Version controller reconciles component versions from an OCI repository by fetching the component descriptor and any referenced component descriptors. The component version controller will also verify signatures for all the public keys provided. The Component Version controller does not fetch any resources other than component descriptors. It is used by downstream controllers to access component descriptors and to attest the validity of component signatures. Downstream controllers can look up a component descriptor via the status field of the component version resource.\nsequenceDiagram User-\u003e\u003eKubernetes API: submit ComponentVersion CR Kubernetes API--\u003e\u003eComponent Version Controller: Component Version Created Event Component Version Controller-\u003e\u003eOCM Repository: Find latest component matching semver Component Version Controller-\u003e\u003eOCM Repository: Validate signatures Component Version Controller-\u003e\u003eOCM Repository: Download Component Descriptor Component Version Controller-\u003e\u003eKubernetes API: Submit Component Descriptor CR Component Version Controller-\u003e\u003eKubernetes API: Update Component Version status\rThe custom resource for the component version controller looks as follows:\napiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion metadata: name: component-x namespace: default spec: interval: 10m0s component: github.com/open-component-model/component-x version: semver: \u0026#34;\u0026gt;=v1.0.0\u0026#34; repository: url: ghcr.io/jane-doe secretRef: name: ghcr-creds verify: - name: dev-signature publicKey: secretRef: name: signing-key\rResource Controller The resource controller extracts resources from a component so that they may be used within the cluster. The resource is written to a snapshot which enables it to be cached and used by downstream processes. Resources can be selected using the name and extraIdentity fields. The resource controller requests resources using the in-cluster registry client. This means that if a resource has previously been requested then the cached version will be returned. If the resource is not found in the cache then it will be fetched from the OCM registry and written to the cache. Once the resource has been resolved and is stored in the internal registry a Snapshot CR is created\nsequenceDiagram User-\u003e\u003eKubernetes API: submit Resource CR Kubernetes API--\u003e\u003eResource Controller: Resource Created Event Resource Controller-\u003e\u003eInternal Registry: Fetch resource from cache or upstream Resource Controller-\u003e\u003eKubernetes API: Create Snapshot CR Resource Controller-\u003e\u003eKubernetes API: Update Resource status\rThe custom resource for the Resource controller is as follows:\napiVersion: delivery.ocm.software/v1alpha1 kind: Resource metadata: name: manifests spec: interval: 10m0s sourceRef: name: component-x namespace: default resourceRef: name: manifests referencePath: - name: nested-component\rSnapshot Controller The Snapshot controller reconciles Snapshot Custom Resources. Currently, the functionality here is limited to updating the status thereby validating that the snapshotted resource exists. In the future we plan to expand the scope of this controller to include verification of snapshots.\nLocalization Controller The localization controller applies localization rules to a snapshot. Because localization is deemed a common operation it is included along with the configuration controller in the ocm-controller itself. Localizations can consume an OCM resource directly or a snapshot resource from the in-cluster registry. The configuration details for the localization operation are supplied via another OCM resource which should be a yaml file in the following format:\napiVersion: config.ocm.software/v1alpha1 kind: ConfigData metadata: name: ocm-config labels: env: test localization: - resource: name: image file: deploy.yaml image: spec.template.spec.containers[0].image\rLocalization parameters are specified under the localization stanza. The Localization controller will apply the localization rules that apply to the resource specified in the source field.\nsequenceDiagram User-\u003e\u003eKubernetes API: submit Localization CR Kubernetes API--\u003e\u003eLocalization Controller: Localization Created Event Localization Controller-\u003e\u003eInternal Registry: Fetch resource from cache or upstream Localization Controller-\u003e\u003eInternal Registry: Fetch configuration resource from cache or upstream Localization Controller-\u003e\u003eLocalization Controller: Apply matching localization rules Localization Controller-\u003e\u003eInternal Registry: Push localized resource to internal registry Localization Controller-\u003e\u003eKubernetes API: Create Snapshot CR Localization Controller-\u003e\u003eKubernetes API: Update Localization status\rThe custom resource for the Localization controllers is as follows:\napiVersion: delivery.ocm.software/v1alpha1 kind: Localization metadata: name: manifests spec: interval: 1m sourceRef: kind: Resource name: manifests resourceRef: name: manifests version: latest configRef: kind: ComponentVersion name: component-x resourceRef: name: config version: latest\rConfiguration Controller The configuration controller is used to configure resources for a particular environment and similar to localization the configured resource is written to a snapshot. Because configuration is deemed a common operation it is included along with the configuration controller in the ocm-controller itself. The behaviour is as described for the localization controller but instead of retrieving configuration from the localization stanza of the ConfigData file, the controller retrieves configuration information from the configuration stanza:\napiVersion: config.ocm.software/v1alpha1 kind: ConfigData metadata: name: ocm-config labels: env: test configuration: defaults: color: red message: Hello, world! schema: type: object additionalProperties: false properties: color: type: string message: type: string rules: - value: (( message )) file: configmap.yaml path: data.PODINFO_UI_MESSAGE - value: (( color )) file: configmap.yaml path: data.PODINFO_UI_COLOR\rAnd a configuration object might something like this:\napiVersion: delivery.ocm.software/v1alpha1 kind: Configuration metadata: name: configuration spec: interval: 1m0s sourceRef: # we configure the localized data kind: Localization name: manifests configRef: kind: ComponentVersion name: component-x resourceRef: name: config version: latest valuesFrom: fluxSource: sourceRef: kind: GitRepository # get the values from a git repository provided by flux name: flux-system namespace: flux-system path: ./values.yaml subPath: component-x-configs\rFluxDeployer controller The final piece in this puzzle is the deployment object. Note this might change in the future to provide more deployment options.\nCurrent, Flux is implemented using the FluxDeployer API. This provides a connection with Flux\u0026rsquo;s ability to apply manifest files taken from an OCI repository. Here, the OCI repository is the in-cluster registry and the path to it will be provided by the snapshot created by the last link in the chain.\nConsider the following example using the localized and configured resource from above:\napiVersion: delivery.ocm.software/v1alpha1 kind: FluxDeployer metadata: name: fluxdeployer-podinfo-pipeline-frontend spec: interval: 1m0s sourceRef: kind: Configuration name: configuration kustomizationTemplate: interval: 5s path: ./ prune: true targetNamespace: ocm-system\rThis will deploy any manifest files at path ./ in the result of the above configuration.\nReplication controller The Replication Controller handles the replication of components between OCI repositories. It consists of a single reconciler which manages subscriptions to a source OCI repository. A semver constraint is used to specify a target component version. Component versions satisfying the semver constraint will be copied to the destination OCI repository. The replication controller will verify signatures before performing replication.\napiVersion: delivery.ocm.software/v1alpha1 kind: ComponentSubscription metadata: name: componentsubscription-sample namespace: ocm-system spec: source: secretRef: name: source-access-secret url: oci://source destination: secretRef: name: destination-access-secret url: oci://destination component: \u0026#34;https://github.com/open-component-model/component-x\u0026#34; interval: 10m0s semver: \u0026#34;~v0.1.0\u0026#34; verify: - signature: name: signature-name key: name: verify-key-name status: latestVersion: \u0026#34;v0.1.1\u0026#34; replicatedVersion: \u0026#34;v0.1.0\u0026#34;\rsequenceDiagram User-\u003e\u003eKubernetes API: submit Component Subscription CR Kubernetes API--\u003e\u003eReplication Controller: Component Subscription Created Event Replication Controller-\u003e\u003eReplication Controller: Determine new component is available in source repository based on semver Replication Controller-\u003e\u003eSource OCM Repository: Verify signatures Source OCM Repository-\u003e\u003eDestination OCM Repository: Transfer component by value Replication Controller-\u003e\u003eKubernetes API: Update Component Subscription status\rIn-cluster Docker Registry The ocm-controller manages a deployment of the docker registry. This provides a caching mechanism for resources and storage for snapshots whilst also enabling integration with Flux. Usage of the in-cluster registry is transparent to the clients and is handled via the ocm client library provided by the controller sdk.\n","date":"2023-10-20","id":17,"permalink":"/docs/controller/architecture/","summary":"\u003cp\u003eThis document explains the architecture of the OCM Kubernetes Controller Set (KCS). The purpose of the KCS is to enable the automated deployment of components using Kubernetes and Flux.\u003c/p\u003e","tags":[],"title":"Architecture"},{"content":"ocm-controller The ocm-controller can be installed using the OCM CLI:\nocm controller install\rThis command will install the ocm-controller in the kubernetes cluster specified by the current KUBECONFIG context.\nThe following flags are available:\nFlags: -u, --base-url string the base url to the ocm-controller\u0026#39;s release page (default \u0026#34;https://github.com/open-component-model/ocm-controller/releases\u0026#34;) -c, --controller-name string name of the controller that\u0026#39;s used for status check (default \u0026#34;ocm-controller\u0026#34;) -d, --dry-run if enabled, prints the downloaded manifest file -h, --help help for install -n, --namespace string the namespace into which the controller is installed (default \u0026#34;ocm-system\u0026#34;) -a, --release-api-url string the base url to the ocm-controller\u0026#39;s API release page (default \u0026#34;https://api.github.com/repos/open-component-model/ocm-controller/releases\u0026#34;) -t, --timeout duration maximum time to wait for deployment to be ready (default 1m0s) -v, --version string the version of the controller to install (default \u0026#34;latest\u0026#34;) Description: Install either a specific or latest version of the ocm-controller.\rreplication-controller The replication-controller can be installed using kubectl:\nVERSION=$(curl -sL https://api.github.com/repos/open-component-model/replication-controller/releases/latest | jq -r \u0026#39;.name\u0026#39;) kubectl apply -f https://github.com/open-component-model/replication-controller/releases/download/$VERSION/install.yaml\r","date":"2023-06-27","id":18,"permalink":"/docs/controller/installation/","summary":"\u003ch2 id=\"ocm-controller\"\u003eocm-controller\u003c/h2\u003e\n\u003cp\u003eThe \u003ccode\u003eocm-controller\u003c/code\u003e can be installed using the \u003ca href=\"/docs/getting-started/installing-the-ocm-cli\"\u003eOCM CLI\u003c/a\u003e:\u003c/p\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame is-terminal not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" class=\"chroma\"\u003e\u003ccode class=\"language-bash\" data-lang=\"bash\"\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003eocm controller install\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003cp\u003eThis command will install the \u003ccode\u003eocm-controller\u003c/code\u003e in the kubernetes cluster specified by the current \u003ccode\u003eKUBECONFIG\u003c/code\u003e context.\u003c/p\u003e","tags":[],"title":"Installation"},{"content":"","date":"2023-01-17","id":19,"permalink":"/docs/component-descriptors/","summary":"","tags":[],"title":"Component Descriptors"},{"content":"","date":"2022-01-25","id":20,"permalink":"/docs/controller/controller-reference/","summary":"","tags":[],"title":"Kubernetes Controllers"},{"content":"","date":"2022-01-25","id":21,"permalink":"/docs/controller/controller-reference/api-reference/","summary":"","tags":[],"title":"API Reference"},{"content":"Packages:\ndelivery.ocm.software/v1alpha1 delivery.ocm.software/v1alpha1 Package v1alpha1 contains API Schema definitions for the delivery v1alpha1 API group\nResource Types: ComponentVersion ComponentVersion is the Schema for the ComponentVersions API.\nField Description metadata\nKubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec\nComponentVersionSpec component\nstring Component specifies the name of the ComponentVersion.\nversion\nVersion Version specifies the version information for the ComponentVersion.\nrepository\nRepository Repository provides details about the OCI repository from which the component descriptor can be retrieved.\ninterval\nKubernetes meta/v1.Duration Interval specifies the interval at which the Repository will be checked for updates.\nverify\n[]Signature (Optional) Verify specifies a list signatures that should be validated before the ComponentVersion is marked Verified.\nreferences\nReferencesConfig (Optional) References specifies configuration for the handling of nested component references.\nsuspend\nbool (Optional) Suspend can be used to temporarily pause the reconciliation of the ComponentVersion resource.\nserviceAccountName\nstring (Optional) ServiceAccountName can be used to configure access to both destination and source repositories. If service account is defined, it\u0026rsquo;s usually redundant to define access to either source or destination, but it is still allowed to do so. https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account\nstatus\nComponentVersionStatus ComponentVersionSpec (Appears on: ComponentVersion) ComponentVersionSpec specifies the configuration required to retrieve a component descriptor for a component version.\nField Description component\nstring Component specifies the name of the ComponentVersion.\nversion\nVersion Version specifies the version information for the ComponentVersion.\nrepository\nRepository Repository provides details about the OCI repository from which the component descriptor can be retrieved.\ninterval\nKubernetes meta/v1.Duration Interval specifies the interval at which the Repository will be checked for updates.\nverify\n[]Signature (Optional) Verify specifies a list signatures that should be validated before the ComponentVersion is marked Verified.\nreferences\nReferencesConfig (Optional) References specifies configuration for the handling of nested component references.\nsuspend\nbool (Optional) Suspend can be used to temporarily pause the reconciliation of the ComponentVersion resource.\nserviceAccountName\nstring (Optional) ServiceAccountName can be used to configure access to both destination and source repositories. If service account is defined, it\u0026rsquo;s usually redundant to define access to either source or destination, but it is still allowed to do so. https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account\nComponentVersionStatus (Appears on: ComponentVersion) ComponentVersionStatus defines the observed state of ComponentVersion.\nField Description observedGeneration\nint64 (Optional) ObservedGeneration is the last reconciled generation.\nconditions\n[]Kubernetes meta/v1.Condition (Optional) Conditions holds the conditions for the ComponentVersion.\ncomponentDescriptor\nReference (Optional) ComponentDescriptor holds the ComponentDescriptor information for the ComponentVersion.\nreconciledVersion\nstring (Optional) ReconciledVersion is a string containing the version of the latest reconciled ComponentVersion.\nverified\nbool (Optional) Verified is a boolean indicating whether all the specified signatures have been verified and are valid.\nConfigMapSource (Appears on: ValuesSource) Field Description sourceRef\ngithub.com/fluxcd/pkg/apis/meta.LocalObjectReference key\nstring subPath\nstring (Optional) Configuration Configuration is the Schema for the configurations API.\nField Description metadata\nKubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec\nMutationSpec interval\nKubernetes meta/v1.Duration sourceRef\nObjectReference configRef\nObjectReference (Optional) values\nk8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1.JSON (Optional) valuesFrom\nValuesSource (Optional) patchStrategicMerge\nPatchStrategicMerge (Optional) suspend\nbool (Optional) Suspend stops all operations on this object.\nstatus\nMutationStatus DeliverySpec DeliverySpec holds a set of targets onto which the pipeline output will be deployed.\nField Description targets\n[]WasmStep ElementMeta (Appears on: ResourceReference) Field Description name\nstring version\nstring extraIdentity\ngithub.com/open-component-model/ocm/pkg/contexts/ocm/compdesc/meta/v1.Identity labels\ngithub.com/open-component-model/ocm/pkg/contexts/ocm/compdesc/meta/v1.Labels FluxDeployer FluxDeployer is the Schema for the FluxDeployers API.\nField Description metadata\nKubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec\nFluxDeployerSpec sourceRef\nObjectReference interval\nKubernetes meta/v1.Duration The interval at which to reconcile the Kustomization and Helm Releases.\nkustomizationTemplate\ngithub.com/fluxcd/kustomize-controller/api/v1beta2.KustomizationSpec (Optional) helmReleaseTemplate\ngithub.com/fluxcd/helm-controller/api/v2beta1.HelmReleaseSpec (Optional) status\nFluxDeployerStatus FluxDeployerSpec (Appears on: FluxDeployer) FluxDeployerSpec defines the desired state of FluxDeployer.\nField Description sourceRef\nObjectReference interval\nKubernetes meta/v1.Duration The interval at which to reconcile the Kustomization and Helm Releases.\nkustomizationTemplate\ngithub.com/fluxcd/kustomize-controller/api/v1beta2.KustomizationSpec (Optional) helmReleaseTemplate\ngithub.com/fluxcd/helm-controller/api/v2beta1.HelmReleaseSpec (Optional) FluxDeployerStatus (Appears on: FluxDeployer) FluxDeployerStatus defines the observed state of FluxDeployer.\nField Description observedGeneration\nint64 (Optional) ObservedGeneration is the last reconciled generation.\nconditions\n[]Kubernetes meta/v1.Condition (Optional) kustomization\nstring (Optional) ociRepository\nstring (Optional) FluxValuesSource (Appears on: ValuesSource) Field Description sourceRef\ngithub.com/fluxcd/pkg/apis/meta.NamespacedObjectKindReference path\nstring subPath\nstring (Optional) Localization Localization is the Schema for the localizations API.\nField Description metadata\nKubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec\nMutationSpec interval\nKubernetes meta/v1.Duration sourceRef\nObjectReference configRef\nObjectReference (Optional) values\nk8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1.JSON (Optional) valuesFrom\nValuesSource (Optional) patchStrategicMerge\nPatchStrategicMerge (Optional) suspend\nbool (Optional) Suspend stops all operations on this object.\nstatus\nMutationStatus MutationObject MutationObject defines any object which produces a snapshot\nMutationSpec (Appears on: Configuration, Localization) MutationSpec defines a common spec for Localization and Configuration of OCM resources.\nField Description interval\nKubernetes meta/v1.Duration sourceRef\nObjectReference configRef\nObjectReference (Optional) values\nk8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1.JSON (Optional) valuesFrom\nValuesSource (Optional) patchStrategicMerge\nPatchStrategicMerge (Optional) suspend\nbool (Optional) Suspend stops all operations on this object.\nMutationStatus (Appears on: Configuration, Localization) MutationStatus defines a common status for Localizations and Configurations.\nField Description observedGeneration\nint64 (Optional) ObservedGeneration is the last reconciled generation.\nconditions\n[]Kubernetes meta/v1.Condition (Optional) latestSnapshotDigest\nstring (Optional) latestSourceVersion\nstring (Optional) latestConfigVersion\nstring (Optional) latestPatchSourceVersio\nstring (Optional) snapshotName\nstring (Optional) ObjectReference (Appears on: FluxDeployerSpec, MutationSpec, ResourcePipelineSpec, ResourceSpec) ObjectReference defines a resource which may be accessed via a snapshot or component version\nField Description NamespacedObjectKindReference\ngithub.com/fluxcd/pkg/apis/meta.NamespacedObjectKindReference (Members of NamespacedObjectKindReference are embedded into this type.) resourceRef\nResourceReference (Optional) PatchStrategicMerge (Appears on: MutationSpec) PatchStrategicMerge contains the source and target details required to perform a strategic merge.\nField Description source\nPatchStrategicMergeSource target\nPatchStrategicMergeTarget PatchStrategicMergeSource (Appears on: PatchStrategicMerge) PatchStrategicMergeSource contains the details required to retrieve the source from a Flux source.\nField Description sourceRef\ngithub.com/fluxcd/pkg/apis/meta.NamespacedObjectKindReference path\nstring PatchStrategicMergeTarget (Appears on: PatchStrategicMerge) PatchStrategicMergeTarget provides details about the merge target.\nField Description path\nstring PipelineSpec (Appears on: ResourcePipelineSpec) PipelineSpec holds the steps that constitute the pipeline.\nField Description steps\n[]WasmStep PublicKey (Appears on: Signature) PublicKey specifies access to a public key for verification.\nField Description secretRef\nKubernetes core/v1.LocalObjectReference (Optional) SecretRef is a reference to a Secret that contains a public key.\nvalue\nstring (Optional) Value defines a PEM/base64 encoded public key value.\nReference (Appears on: ComponentVersionStatus, Reference) Reference contains all referred components and their versions.\nField Description name\nstring Name specifies the name of the referenced component.\nversion\nstring Version specifies the version of the referenced component.\nreferences\n[]Reference References is a list of component references.\nextraIdentity\nmap[string]string (Optional) ExtraIdentity specifies additional identity attributes of the referenced component.\ncomponentDescriptorRef\ngithub.com/fluxcd/pkg/apis/meta.NamespacedObjectReference (Optional) ComponentDescriptorRef specifies the reference for the Kubernetes object representing the ComponentDescriptor.\nReferencesConfig (Appears on: ComponentVersionSpec) ReferencesConfig specifies how component references should be handled when reconciling the root component.\nField Description expand\nbool (Optional) Expand specifies if a Kubernetes API resource of kind ComponentDescriptor should be generated for each component reference that is present in the root ComponentVersion.\nRepository (Appears on: ComponentVersionSpec) Repository specifies access details for the repository that contains OCM ComponentVersions.\nField Description url\nstring URL specifies the URL of the OCI registry in which the ComponentVersion is stored. MUST NOT CONTAIN THE SCHEME.\nsecretRef\nKubernetes core/v1.LocalObjectReference (Optional) SecretRef specifies the credentials used to access the OCI registry.\nResource Resource is the Schema for the resources API.\nField Description metadata\nKubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec\nResourceSpec interval\nKubernetes meta/v1.Duration Interval specifies the interval at which the Repository will be checked for updates.\nsourceRef\nObjectReference SourceRef specifies the source object from which the resource should be retrieved.\nsuspend\nbool (Optional) Suspend can be used to temporarily pause the reconciliation of the Resource.\nstatus\nResourceStatus ResourcePipeline ResourcePipeline is the Schema for the resourcepipelines API.\nField Description metadata\nKubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec\nResourcePipelineSpec interval\nKubernetes meta/v1.Duration suspend\nbool (Optional) serviceAccountName\nstring (Optional) sourceRef\nObjectReference parameters\nk8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1.JSON (Optional) pipelineSpec\nPipelineSpec (Optional) status\nResourcePipelineStatus ResourcePipelineSource ResourcePipelineSource defines the component version and resource which will be processed by the pipeline.\nField Description name\nstring namespace\nstring (Optional) resource\nstring ResourcePipelineSpec (Appears on: ResourcePipeline) ResourcePipelineSpec defines the desired state of ResourcePipeline.\nField Description interval\nKubernetes meta/v1.Duration suspend\nbool (Optional) serviceAccountName\nstring (Optional) sourceRef\nObjectReference parameters\nk8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1.JSON (Optional) pipelineSpec\nPipelineSpec (Optional) ResourcePipelineStatus (Appears on: ResourcePipeline) ResourcePipelineStatus defines the observed state of ResourcePipeline.\nField Description observedGeneration\nint64 (Optional) ObservedGeneration is the last reconciled generation.\nconditions\n[]Kubernetes meta/v1.Condition (Optional) latestSnapshotDigest\nstring (Optional) snapshotName\nstring (Optional) ResourceReference (Appears on: ObjectReference) Field Description ElementMeta\nElementMeta (Members of ElementMeta are embedded into this type.) referencePath\n[]github.com/open-component-model/ocm/pkg/contexts/ocm/compdesc/meta/v1.Identity (Optional) ResourceSpec (Appears on: Resource) ResourceSpec defines the desired state of Resource.\nField Description interval\nKubernetes meta/v1.Duration Interval specifies the interval at which the Repository will be checked for updates.\nsourceRef\nObjectReference SourceRef specifies the source object from which the resource should be retrieved.\nsuspend\nbool (Optional) Suspend can be used to temporarily pause the reconciliation of the Resource.\nResourceStatus (Appears on: Resource) ResourceStatus defines the observed state of Resource.\nField Description observedGeneration\nint64 (Optional) ObservedGeneration is the last reconciled generation.\nconditions\n[]Kubernetes meta/v1.Condition (Optional) Conditions holds the conditions for the ComponentVersion.\nlastAppliedResourceVersion\nstring (Optional) LastAppliedResourceVersion holds the version of the resource that was last applied (if applicable).\nlastAppliedComponentVersion\nstring (Optional) LastAppliedComponentVersion holds the version of the last applied ComponentVersion for the ComponentVersion which contains this Resource.\nsnapshotName\nstring (Optional) SnapshotName specifies the name of the Snapshot that has been created to store the resource within the cluster and make it available for consumption by Flux controllers.\nlatestSnapshotDigest\nstring (Optional) LatestSnapshotDigest is a string representation of the digest for the most recent Resource snapshot.\nSignature (Appears on: ComponentVersionSpec) Signature defines the details of a signature to use for verification.\nField Description name\nstring Name specifies the name of the signature. An OCM component may have multiple signatures.\npublicKey\nPublicKey PublicKey provides a reference to a Kubernetes Secret of contain a blob of a public key that which will be used to validate the named signature.\nValuesSource (Appears on: MutationSpec) ValuesSource provides access to values from an external Source such as a ConfigMap or GitRepository. An optional subpath defines the path within the source from which the values should be resolved.\nField Description fluxSource\nFluxValuesSource (Optional) configMapSource\nConfigMapSource (Optional) Version (Appears on: ComponentVersionSpec) Version specifies version information that can be used to resolve a Component Version.\nField Description semver\nstring (Optional) Semver specifies a semantic version constraint for the Component Version.\nWasmStep (Appears on: DeliverySpec, PipelineSpec) WasmStep defines the name version and location of a wasm module that is stored// in an ocm component. The format of the module name must be :@. Optionally a registry address can be specified.\nField Description name\nstring module\nstring registry\nstring (Optional) values\nk8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1.JSON (Optional) timeout\nKubernetes meta/v1.Duration (Optional) This page was automatically generated with gen-crd-api-reference-docs\n","date":"2023-06-27","id":22,"permalink":"/docs/controller/controller-reference/api-reference/ocm-controller-api-v1/","summary":"\u003cp\u003ePackages:\u003c/p\u003e\n\u003cul class=\"simple\"\u003e\n\u003cli\u003e\n\u003ca href=\"#delivery.ocm.software%2fv1alpha1\"\u003edelivery.ocm.software/v1alpha1\u003c/a\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"delivery.ocm.software/v1alpha1\"\u003edelivery.ocm.software/v1alpha1\u003c/h2\u003e\n\u003cp\u003ePackage v1alpha1 contains API Schema definitions for the delivery v1alpha1 API group\u003c/p\u003e\nResource Types:\n\u003cul class=\"simple\"\u003e\u003c/ul\u003e\n\u003ch3 id=\"delivery.ocm.software/v1alpha1.ComponentVersion\"\u003eComponentVersion\n\u003c/h3\u003e\n\u003cp\u003eComponentVersion is the Schema for the ComponentVersions API.\u003c/p\u003e","tags":[],"title":"OCM Controller API v1"},{"content":"Packages:\ndelivery.ocm.software/v1alpha1 delivery.ocm.software/v1alpha1 Package v1alpha1 contains API Schema definitions for the delivery v1alpha1 API group\nResource Types: ComponentSubscription ComponentSubscription is the Schema for the componentsubscriptions API\nField Description metadata\nKubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec\nComponentSubscriptionSpec component\nstring Component specifies the name of the Component that should be replicated.\nsemver\nstring (Optional) Semver specifies an optional semver constraint that is used to evaluate the component versions that should be replicated.\nsource\nOCMRepository Source holds the OCM Repository details for the replication source.\ndestination\nOCMRepository (Optional) Destination holds the destination or target OCM Repository details. The ComponentVersion will be transfered into this repository.\ninterval\nKubernetes meta/v1.Duration Interval is the reconciliation interval, i.e. at what interval shall a reconciliation happen. This is used to requeue objects for reconciliation in case of success as well as already reconciling objects.\nserviceAccountName\nstring (Optional) ServiceAccountName can be used to configure access to both destination and source repositories. If service account is defined, it\u0026rsquo;s usually redundant to define access to either source or destination, but it is still allowed to do so. https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account\nverify\n[]Signature (Optional) Verify specifies a list signatures that must be verified before a ComponentVersion is replicated.\nstatus\nComponentSubscriptionStatus ComponentSubscriptionSpec (Appears on: ComponentSubscription) ComponentSubscriptionSpec defines the desired state of ComponentSubscription. It specifies the parameters that the replication controller will use to replicate a desired Component from a source OCM repository to a destination OCM repository.\nField Description component\nstring Component specifies the name of the Component that should be replicated.\nsemver\nstring (Optional) Semver specifies an optional semver constraint that is used to evaluate the component versions that should be replicated.\nsource\nOCMRepository Source holds the OCM Repository details for the replication source.\ndestination\nOCMRepository (Optional) Destination holds the destination or target OCM Repository details. The ComponentVersion will be transfered into this repository.\ninterval\nKubernetes meta/v1.Duration Interval is the reconciliation interval, i.e. at what interval shall a reconciliation happen. This is used to requeue objects for reconciliation in case of success as well as already reconciling objects.\nserviceAccountName\nstring (Optional) ServiceAccountName can be used to configure access to both destination and source repositories. If service account is defined, it\u0026rsquo;s usually redundant to define access to either source or destination, but it is still allowed to do so. https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account\nverify\n[]Signature (Optional) Verify specifies a list signatures that should be validated before the ComponentVersion is marked Verified.\nComponentSubscriptionStatus (Appears on: ComponentSubscription) ComponentSubscriptionStatus defines the observed state of ComponentSubscription\nField Description lastAttemptedVersion\nstring (Optional) LastAttemptedVersion defines the latest version encountered while checking component versions. This might be different from last applied version which should be the latest applied/replicated version. The difference might be caused because of semver constraint or failures during replication.\nobservedGeneration\nint64 (Optional) ObservedGeneration is the last reconciled generation.\nlastAppliedVersion\nstring (Optional) LastAppliedVersion defines the final version that has been applied to the destination component version.\nreplicatedRepositoryURL\nstring (Optional) ReplicatedRepositoryURL defines the final location of the reconciled Component.\nconditions\n[]Kubernetes meta/v1.Condition (Optional) OCMRepository (Appears on: ComponentSubscriptionSpec) OCMRepository specifies access details for an OCI based OCM Repository.\nField Description url\nstring URL specifies the URL of the OCI registry.\nsecretRef\nKubernetes core/v1.LocalObjectReference (Optional) SecretRef specifies the credentials used to access the OCI registry.\nSecretRef (Appears on: Signature) SecretRef clearly denotes that the requested option is a Secret.\nField Description secretRef\ngithub.com/fluxcd/pkg/apis/meta.LocalObjectReference Signature (Appears on: ComponentSubscriptionSpec) Signature defines the details of a signature to use for verification.\nField Description name\nstring Name specifies the name of the signature. An OCM component may have multiple signatures.\npublicKey\nSecretRef PublicKey provides a reference to a Kubernetes Secret that contains a public key which will be used to validate the named signature.\nThis page was automatically generated with gen-crd-api-reference-docs\n","date":"2023-07-10","id":23,"permalink":"/docs/controller/controller-reference/api-reference/replication-controller-api-v1/","summary":"\u003cp\u003ePackages:\u003c/p\u003e\n\u003cul class=\"simple\"\u003e\n\u003cli\u003e\n\u003ca href=\"#delivery.ocm.software%2fv1alpha1\"\u003edelivery.ocm.software/v1alpha1\u003c/a\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"delivery.ocm.software/v1alpha1\"\u003edelivery.ocm.software/v1alpha1\u003c/h2\u003e\n\u003cp\u003ePackage v1alpha1 contains API Schema definitions for the delivery v1alpha1 API group\u003c/p\u003e\nResource Types:\n\u003cul class=\"simple\"\u003e\u003c/ul\u003e\n\u003ch3 id=\"delivery.ocm.software/v1alpha1.ComponentSubscription\"\u003eComponentSubscription\n\u003c/h3\u003e\n\u003cp\u003eComponentSubscription is the Schema for the componentsubscriptions API\u003c/p\u003e","tags":[],"title":"Replication Controller API v1"},{"content":"","date":"2022-01-25","id":24,"permalink":"/docs/controller/controller-reference/ocm-controller/","summary":"","tags":[],"title":"OCM Controller"},{"content":"The ComponentVersion API produces component descriptors for a specific component version.\nExample The following is an example of a ComponentVersion:\napiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion metadata: name: podinfo namespace: default spec: interval: 10m0s component: phoban.io/podinfo repository: url: ghcr.io/phoban01 version: semver: \u0026#34;\u0026gt;=6.3.x\u0026#34;\rIn the above example:\nA ComponentVersion named podinfo is created, indicated by the .metadata.name field. The ocm-controller checks the OCM repository every 10m0s, indicated by the .spec.interval field. It retrieves the version matching the semver constraint specified by .spec.version.semver field. The resolved component descriptor and version are written to the .status.componentDescriptor and .status.reconciledVersion fields. Whenever a new version is available that satisfies .spec.version.semver and is greater than .status.reconciledVersion then the ocm-controller will fetch the new component version. You can run this example by saving the manifest into componentversion.yaml.\nApply the resource to the cluster: kubectl apply -f componentversion.yaml\rRun kubectl get componentversion to see the ComponentVersion NAME READY VERSION AGE STATUS podinfo True 6.3.6 8s Applied version: 6.3.6\rRun kubectl describe componentversion podinfo to see the ComponentVersion Status: Name: podinfo Namespace: default Labels: \u0026lt;none\u0026gt; Annotations: \u0026lt;none\u0026gt; API Version: delivery.ocm.software/v1alpha1 Kind: ComponentVersion Metadata: Creation Timestamp: 2023-06-28T15:41:57Z Generation: 1 Resource Version: 235307145 UID: 318963a5-3b4f-4098-b324-348a57e532ff Spec: Component: phoban.io/podinfo Interval: 10m0s Repository: URL: ghcr.io/phoban01 Version: Semver: \u0026gt;=6.3.x Status: Component Descriptor: Component Descriptor Ref: Name: phoban.io-podinfo-6.3.6-10372358058082697739 Namespace: default Name: phoban.io/podinfo Version: 6.3.6 Conditions: Last Transition Time: 2023-06-28T15:42:01Z Message: Applied version: 6.3.6 Observed Generation: 1 Reason: Succeeded Status: True Type: Ready Observed Generation: 1 Reconciled Version: 6.3.6 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Progressing 46s ocm-controller Version check succeeded, found latest version: 6.3.6 Normal Succeeded 43s ocm-controller Reconciliation finished, next run in 10m0s\rView the ComponentDescriptor for this ComponentVersion by running kubectl get componentdescriptor -oyaml \\ $(kubectl get cv podinfo -ojsonpath=\u0026#34;{.status.componentDescriptor.componentDescriptorRef.name}\u0026#34;)\rapiVersion: delivery.ocm.software/v1alpha1 kind: ComponentDescriptor metadata: creationTimestamp: \u0026#34;2023-06-28T15:42:01Z\u0026#34; generation: 1 name: phoban.io-podinfo-6.3.6-10372358058082697739 namespace: default ownerReferences: - apiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion name: podinfo uid: 318963a5-3b4f-4098-b324-348a57e532ff resourceVersion: \u0026#34;235307140\u0026#34; uid: 4efd4eb2-cb2d-4e0d-ae3c-f74cc59e3fa0 spec: resources: - access: globalAccess: digest: sha256:265a95fcccabded6d2040e1438b8b1c5bef1441adb60039adf54640c00b84003 mediaType: application/x-tar ref: ghcr.io/phoban01/component-descriptors/phoban.io/podinfo size: 3072 type: ociBlob localReference: sha256:265a95fcccabded6d2040e1438b8b1c5bef1441adb60039adf54640c00b84003 mediaType: application/x-tar type: localBlob name: deployment relation: local type: Directory version: 6.3.6 - access: globalAccess: digest: sha256:b3fe60d3213e6c11006b6f62d9f1bcc6a6e12da1b3aa5ee9f27943710262d351 mediaType: application/octet-stream ref: ghcr.io/phoban01/component-descriptors/phoban.io/podinfo size: 515 type: ociBlob localReference: sha256:b3fe60d3213e6c11006b6f62d9f1bcc6a6e12da1b3aa5ee9f27943710262d351 mediaType: application/octet-stream type: localBlob name: config relation: local type: PlainText version: 6.3.6 - access: imageReference: ghcr.io/stefanprodan/podinfo:6.3.5 type: ociArtifact name: image relation: external type: ociImage version: 6.3.5 version: 6.3.6\rWriting a ComponentVersion spec As with all other Kubernetes config, an ComponentVersion needs apiVersion, kind, and metadata fields. The name of an ComponentVersion object must be a valid DNS subdomain name.\nAn ComponentVersion also needs a .spec section.\nComponent .spec.component is a required field that specifies the name of the component.\nVersion .spec.version.semver specifies a semantic version constraint that is used to determine the specific component version or range of versions that will be reconciled.\nRepository .spec.repository provides the necessary configuration for the ocm-controller to access the OCI repository where the component version is stored.\nURL .spec.repository.url is a required field that denoting the registry in which the OCM component is stored.\nSecret Reference .spec.repository.secretRef.name is an optional field to specify a name reference to a Secret in the same namespace as the ComponentVersion, containing authentication credentials for the OCI repository.\nThis secret is expected to contain the keys username and password. You can create such a secret using kubectl:\nkubectl create secret generic registry-credentials --from-literal=username=$GITHUB_USER --from-literal=password=$GITHUB_TOKEN\rService Account Name .spec.serviceAccountName is an optional field to specify a name reference to a Service Account in the same namespace as the ComponentVersion. The controller will fetch the image pull secrets attached to the service account and use them for authentication.\nPublic OCI Repository access\nthat for a publicly accessible OCI repository, you don’t need to provide a secretRef nor serviceAccountName.\nInterval .spec.interval is a required field that specifies the interval at which the ComponentVersion must be reconciled.\nAfter successfully reconciling the object, the ocm-controller requeues it for inspection after the specified interval. The value must be in a Go recognized duration string format, e.g. 10m0s to reconcile the object every 10 minutes.\nIf the .metadata.generation of a resource changes (due to e.g. a change to the spec), this is handled instantly outside the interval window.\nVerify .spec.verify is an optional list of signatures that should be validated before the component version is marked as verified. A ComponentVersion that is not verified will not be consumed by downstream ocm-controller resources. Each signature item consists of a name and a publicKey.\nName .spec.verify.[].name is a required field that specifies the name of the signature that should be verified.\nPublic Key .spec.verify.[].publicKey is a required field that specifies a reference to a secret containing the public key that can be used to verify the signature. The key of the public key in the secret must match the name of the signature.\nFor example, the following ComponentVersion verifies two signatures:\napiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion metadata: name: podinfo namespace: default spec: interval: 10m0s component: phoban.io/podinfo repository: url: ghcr.io/phoban01 version: semver: \u0026#34;\u0026gt;=6.3.x\u0026#34; verify: - name: operations publicKey: secretRef: name: signing-keys - name: security publicKey: secretRef: name: signing-keys\rThe accompanying secret should be in the following format:\napiVersion: v1 kind: Secret metadata: name: signing-keys type: Opaque data: operations: \u0026lt;BASE64\u0026gt; security: \u0026lt;BASE64\u0026gt;\rSuspend .spec.suspend is an optional field to suspend the reconciliation of a ComponentVersion. When set to true, the controller will stop reconciling the ComponentVersion. When the field is set to false or removed, it will resume.\nDebugging ComponentVersions There are several ways to gather information about a ComponentVersion for debugging purposes.\nDescribe the ComponentVersion Describing an ComponentVersion using kubectl describe componentversion \u0026lt;repository-name\u0026gt; displays the latest recorded information for the resource in the Status and Events sections:\n... Status: ... Conditions: Last Transition Time: 2023-06-29T11:54:23Z Message: reconcilation in progress for component: phoban.io/podinfo Observed Generation: 1 Reason: ProgressingWithRetry Status: True Type: Reconciling Last Transition Time: 2023-06-29T11:54:23Z Message: failed to verify phoban.io/podinfo with constraint \u0026gt;=6.3.x Observed Generation: 1 Reason: ComponentVerificationFailed Status: False Type: Ready Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Progressing 18s ocm-controller Version check succeeded, found latest version: 6.3.6 Warning ComponentVerificationFailed 16s ocm-controller failed to get public key for verification: public key not found, retrying in 10m0s Warning ComponentVerificationFailed 16s ocm-controller Reconciliation did not succeed, retrying in 10m0s\rTrace emitted Events To view events for specific ComponentVersion(s), kubectl events can be used in combination with --for to list the Events for specific objects. For example, running:\nkubectl events --for ComponentVersion/\u0026lt;name\u0026gt;\routputs:\nLAST SEEN TYPE REASON OBJECT MESSAGE 38s Warning ComponentVerificationFailed ComponentVersion/podinfo failed to get public key for verification: public key not found, retrying in 10m0s 38s Warning ComponentVerificationFailed ComponentVersion/podinfo Reconciliation did not succeed, retrying in 10m0s\rBesides being reported in Events, the reconciliation errors are also logged by the controller. You can use a tool such as stern in tandem with grep to filter and refine the output of controller logs:\nstern ocm-controller -n ocm-system | grep ComponentVersion\rwill output the following log stream:\nocm-controller-bcf4cbbb8-crd4d manager 2023-06-29T11:54:21Z INFO Version check succeeded, found latest version: 6.3.6 {\u0026#34;name\u0026#34;: \u0026#34;podinfo\u0026#34;, \u0026#34;namespace\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;reconciler kind\u0026#34;: \u0026#34;ComponentVersion\u0026#34;, \u0026#34;reason\u0026#34;: \u0026#34;Progressing\u0026#34;, \u0026#34;annotations\u0026#34;: {}} ocm-controller-bcf4cbbb8-crd4d manager 2023-06-29T11:54:23Z ERROR failed to get public key for verification: public key not found, retrying in 10m0s {\u0026#34;name\u0026#34;: \u0026#34;podinfo\u0026#34;, \u0026#34;namespace\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;reconciler kind\u0026#34;: \u0026#34;ComponentVersion\u0026#34;, \u0026#34;annotations\u0026#34;: {}, \u0026#34;error\u0026#34;: \u0026#34;ComponentVerificationFailed\u0026#34;} ocm-controller-bcf4cbbb8-crd4d manager github.com/open-component-model/ocm-controller/controllers.(*ComponentVersionReconciler).Reconcile ocm-controller-bcf4cbbb8-crd4d manager 2023-06-29T11:54:23Z ERROR Reconciliation did not succeed, retrying in 10m0s {\u0026#34;name\u0026#34;: \u0026#34;podinfo\u0026#34;, \u0026#34;namespace\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;reconciler kind\u0026#34;: \u0026#34;ComponentVersion\u0026#34;, \u0026#34;annotations\u0026#34;: {}, \u0026#34;error\u0026#34;: \u0026#34;ComponentVerificationFailed\u0026#34;} ocm-controller-bcf4cbbb8-crd4d manager github.com/open-component-model/ocm-controller/controllers.(*ComponentVersionReconciler).Reconcile.func1 ocm-controller-bcf4cbbb8-crd4d manager github.com/open-component-model/ocm-controller/controllers.(*ComponentVersionReconciler).Reconcile\rComponentVersion Status Observed Generation The ocm-controller reports an observed generation in the ComponentVersion’s .status.observedGeneration. The observed generation is the latest .metadata.generation which resulted in either a ready state, or stalled due to error it can not recover from without human intervention.\nConditions ComponentVersion has various states during its lifecycle, reflected as Kubernetes Conditions. It can be reconciling while fetching the remote ComponentVersion or verifying signatures, it can be ready, or it can fail during reconciliation.\nComponent Descriptor The status contains a reference to the component descriptor for the reconciled component version.\nThe following fields make up the reference:\nname: name of the reconciled component. version: version of the reconciled component. extraIdentity: additional identity attributes of the reconciled component. references: a list of component references. componentDescriptorRef: a reference to the ComponentDescriptor Kubernetes representation. Reconciled Version The reconciled version status field holds the specific version that was reconciled by the ocm-controller.\nVerified ","date":"2023-06-28","id":25,"permalink":"/docs/controller/controller-reference/ocm-controller/component-version/","summary":"\u003cp\u003eThe \u003ccode\u003eComponentVersion\u003c/code\u003e API produces component descriptors for a specific component version.\u003c/p\u003e\n\u003ch2 id=\"example\"\u003eExample\u003c/h2\u003e\n\u003cp\u003eThe following is an example of a ComponentVersion:\u003c/p\u003e","tags":[],"title":"Component Version"},{"content":"OCM Controller API reference v1alpha1 Packages:\ndelivery.ocm.software/v1alpha1 delivery.ocm.software/v1alpha1 Package v1alpha1 contains API Schema definitions for the delivery v1alpha1 API group\nResource Types: Component Component gathers together reconciled information about a component.\nField Description name\nstring version\nstring registry\nRegistry ComponentSubscription ComponentSubscription is the Schema for the componentsubscriptions API\nField Description metadata\nKubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec\nComponentSubscriptionSpec interval\nKubernetes meta/v1.Duration Interval is the reconciliation interval, i.e. at what interval shall a reconciliation happen. This is used to requeue objects for reconciliation in case of success as well as already reconciling objects.\nsource\nOCMRepository destination\nOCMRepository component\nstring serviceAccountName\nstring (Optional) ServiceAccountName can be used to configure access to both destination and source repositories. If service account is defined, it\u0026rsquo;s usually redundant to define access to either source or destination, but it is still allowed to do so. https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account\nsemver\nstring (Optional) verify\n[]Signature status\nComponentSubscriptionStatus ComponentSubscriptionSpec (Appears on: ComponentSubscription) ComponentSubscriptionSpec defines the desired state of ComponentSubscription\nField Description interval\nKubernetes meta/v1.Duration Interval is the reconciliation interval, i.e. at what interval shall a reconciliation happen. This is used to requeue objects for reconciliation in case of success as well as already reconciling objects.\nsource\nOCMRepository destination\nOCMRepository component\nstring serviceAccountName\nstring (Optional) ServiceAccountName can be used to configure access to both destination and source repositories. If service account is defined, it\u0026rsquo;s usually redundant to define access to either source or destination, but it is still allowed to do so. https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account\nsemver\nstring (Optional) verify\n[]Signature ComponentSubscriptionStatus (Appears on: ComponentSubscription) ComponentSubscriptionStatus defines the observed state of ComponentSubscription\nField Description lastAttemptedVersion\nstring (Optional) LastAttemptedVersion defines the latest version encountered while checking component versions. This might be different from last applied version which should be the latest applied/replicated version. The difference might be caused because of semver constraint or failures during replication.\nobservedGeneration\nint64 (Optional) ObservedGeneration is the last reconciled generation.\nlastAppliedVersion\nstring (Optional) LastAppliedVersion defines the final version that has been applied to the destination component version.\nreplicatedRepositoryURL\nstring (Optional) ReplicatedRepositoryURL defines the final location of the reconciled Component.\nconditions\n[]Kubernetes meta/v1.Condition (Optional) OCMRepository (Appears on: ComponentSubscriptionSpec) OCMRepository defines details for a repository, such as access keys and the url.\nField Description url\nstring secretRef\ngithub.com/fluxcd/pkg/apis/meta.LocalObjectReference (Optional) Registry (Appears on: Component) Registry defines information about the location of a component.\nField Description url\nstring SecretRef (Appears on: Signature) SecretRef clearly denotes that the requested option is a Secret.\nField Description secretRef\ngithub.com/fluxcd/pkg/apis/meta.LocalObjectReference Signature (Appears on: ComponentSubscriptionSpec) Signature defines the details of a signature to use for verification.\nField Description name\nstring Name of the signature.\npublicKey\nSecretRef Key which is used for verification.\nThis page was automatically generated with gen-crd-api-reference-docs\n","date":"2022-01-25","id":26,"permalink":"/docs/controller/controller-reference/replication-controller/","summary":"\u003ch1\u003eOCM Controller API reference v1alpha1\u003c/h1\u003e\n\u003cp\u003ePackages:\u003c/p\u003e\n\u003cul class=\"simple\"\u003e\n\u003cli\u003e\n\u003ca href=\"#delivery.ocm.software%2fv1alpha1\"\u003edelivery.ocm.software/v1alpha1\u003c/a\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"delivery.ocm.software/v1alpha1\"\u003edelivery.ocm.software/v1alpha1\u003c/h2\u003e\n\u003cp\u003ePackage v1alpha1 contains API Schema definitions for the delivery v1alpha1 API group\u003c/p\u003e\nResource Types:\n\u003cul class=\"simple\"\u003e\u003c/ul\u003e\n\u003ch3 id=\"delivery.ocm.software/v1alpha1.Component\"\u003eComponent\n\u003c/h3\u003e\n\u003cp\u003eComponent gathers together reconciled information about a component.\u003c/p\u003e","tags":[],"title":"Replication Controller"},{"content":"The ComponentSubscription API produces component descriptors for a specific component version.\nExample The following is an example of a ComponentSubscription:\napiVersion: delivery.ocm.software/v1alpha1 kind: ComponentSubscription metadata: name: podinfo namespace: default spec: interval: 10m0s component: phoban.io/podinfo semver: \u0026#34;\u0026gt;=6.3.x\u0026#34; source: url: ghcr.io/phoban01 destination: url: ghcr.io/phoban01/foo secretRef: name: ghcr-credentials\rIn the above example:\nA ComponentSubscription named podinfo is created, indicated by the .metadata.name field. The replication-controller checks the Source repository every 10m0s, indicated by the .spec.interval field. It retrieves the version matching the semver constraint specified by .spec.version.semver field. Whenever a new version is available in the Source repository that satisfies .spec.semver and is greater than .status.lastAppliedVersion then the replication-controller will copy the component and all of it\u0026rsquo;s resources to the OCI repository specified in spec.destination. You can run this example by saving the manifest into subscription.yaml.\nCreate the registry access secret for GitHub Container Registry: GITHUB_USER={USERNAME} # replace with your GitHub Username. GITHUB_TOKEN={TOKEN} # replace with a GitHub Personal Access Token. kubectl create secret generic ghcr-credentials \\ --from-literal=username=$GITHUB_USER \\ --from-literal=password=$GITHUB_TOKEN\rApply the resource to the cluster, (making sure to update the destination repository details for your own ghcr.io account): kubectl apply -f subscription.yaml\rRun kubectl get componentsubscriptions to see the ComponentSubscription NAME AGE podinfo 8s\rRun kubectl describe componentsubscription podinfo to see the ComponentSubscription Status: ... Status: Conditions: Last Transition Time: 2023-07-12T08:46:09Z Message: Reconciliation success Observed Generation: 1 Reason: Succeeded Status: True Type: Ready Last Applied Version: 6.3.6 Observed Generation: 1 Replicated Repository URL: ghcr.io/phoban01/foo\rWriting a ComponentSubscription spec As with all other Kubernetes config, an ComponentSubscription needs apiVersion, kind, and metadata fields. The name of an ComponentSubscription object must be a valid DNS subdomain name.\nAn ComponentSubscription also needs a .spec section.\nComponent .spec.component is a required field that specifies the component\u0026rsquo;s name.\nVersion .spec.semver specifies a semantic version constraint used to determine the range of versions to be replicated.\nSource Repository .spec.source is a required field that provides the necessary configuration for the replication-controller to access the OCI repository where the source component versions are stored.\nSource Repository URL .spec.source.url is a required field denoting the registry in which the source OCM components are stored.\nSource Repository Secret Reference .spec.source.secretRef.name is an optional field to specify a name reference to a Secret in the same namespace as the ComponentSubscription, containing authentication credentials for the OCI repository.\nThis secret is expected to contain the keys username and password. You can create such a secret using kubectl:\nNote: that for a publicly accessible source repository, you don’t need to provide credentials.\nkubectl create secret generic registry-credentials --from-literal=username=$GITHUB_USER --from-literal=password=$GITHUB_TOKEN\rDestination Repository .spec.destination is an optional field that provides the necessary configuration for the replication-controller to access the destination repository into which components will be replicated.\nService Account Name .spec.serviceAccountName is an optional field to specify a name reference to a Service Account in the same namespace as the ComponentSubscription. The controller will fetch the image pull secrets attached to the service account and use them for authentication.\nInterval .spec.interval is a required field that specifies the interval at which the ComponentSubscription must be reconciled.\nAfter successfully reconciling the object, the replication-controller requeues it for inspection after the specified interval. The value must be in a Go recognized duration string format, e.g. 10m0s to reconcile the object every 10 minutes.\nIf the .metadata.generation of a resource changes (due to e.g. a change to the spec), this is handled instantly outside the interval window.\nVerify .spec.verify is an optional list of signatures that should be validated before the component version is replicated. Each signature item consists of a name and a publicKey.\nName .spec.verify.[].name is a required field that specifies the name of the signature that should be verified.\nPublic Key .spec.verify.[].publicKey is a required field that specifies a reference to a secret containing the public key that can be used to verify the signature. The key of the public key in the secret must match the name of the signature.\nFor example, the following ComponentSubscription verifies two signatures:\napiVersion: delivery.ocm.software/v1alpha1 kind: ComponentSubscription metadata: name: podinfo namespace: default spec: interval: 10m0s component: phoban.io/podinfo semver: \u0026#34;\u0026gt;=6.3.x\u0026#34; source: url: ghcr.io/phoban01 destination: url: ghcr.io/phoban01/foo secretRef: name: ghcr-credentials verify: - name: operations publicKey: secretRef: name: signing-keys - name: security publicKey: secretRef: name: signing-keys\rThe accompanying secret should be in the following format:\napiVersion: v1 kind: Secret metadata: name: signing-keys type: Opaque data: operations: \u0026lt;BASE64\u0026gt; security: \u0026lt;BASE64\u0026gt;\rDebugging ComponentSubscriptions There are several ways to gather information about a ComponentSubscription for debugging purposes.\nDescribe the ComponentSubscription Describing an ComponentSubscription using kubectl describe componentsubscription \u0026lt;subscription-name\u0026gt; displays the latest recorded information for the resource in the Status sections:\n... Status: Conditions: Last Transition Time: 2023-07-12T10:12:14Z Message: no matching versions found for constraint \u0026#39;\u0026gt;=7.3.x\u0026#39; Observed Generation: 2 Reason: PullingLatestVersionFailed Status: False Type: Ready Last Applied Version: 6.3.6 Observed Generation: 1 Replicated Repository URL: ghcr.io/phoban01/foo\rReconciliation errors are also logged by the controller. You can use a tool such as stern in tandem with grep to filter and refine the output of controller logs:\nstern replication-controller -n ocm-system | grep ComponentSubscription\rwill output the following log stream:\nreplication-controller-76848b97c5-4flrl manager 2023-07-12T10:13:05Z LEVEL(-4) credentials configured {\u0026#34;controller\u0026#34;: \u0026#34;componentsubscription\u0026#34;, \u0026#34;controllerGroup\u0026#34;: \u0026#34;delivery.ocm.software\u0026#34;, \u0026#34;controllerKind\u0026#34;: \u0026#34;ComponentSubscription\u0026#34;, \u0026#34;ComponentSubscription\u0026#34;: {\u0026#34;name\u0026#34;:\u0026#34;podinfo\u0026#34;,\u0026#34;namespace\u0026#34;:\u0026#34;default\u0026#34;}, \u0026#34;namespace\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;podinfo\u0026#34;, \u0026#34;reconcileID\u0026#34;: \u0026#34;a9eeba17-a533-4dc7-81fd-af97096d60aa\u0026#34;} replication-controller-76848b97c5-4flrl manager 2023-07-12T10:13:06Z ERROR Reconciler error {\u0026#34;controller\u0026#34;: \u0026#34;componentsubscription\u0026#34;, \u0026#34;controllerGroup\u0026#34;: \u0026#34;delivery.ocm.software\u0026#34;, \u0026#34;controllerKind\u0026#34;: \u0026#34;ComponentSubscription\u0026#34;, \u0026#34;ComponentSubscription\u0026#34;: {\u0026#34;name\u0026#34;:\u0026#34;podinfo\u0026#34;,\u0026#34;namespace\u0026#34;:\u0026#34;default\u0026#34;}, \u0026#34;namespace\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;podinfo\u0026#34;, \u0026#34;reconcileID\u0026#34;: \u0026#34;a9eeba17-a533-4dc7-81fd-af97096d60aa\u0026#34;, \u0026#34;error\u0026#34;: \u0026#34;failed to get latest component version: no matching versions found for constraint \u0026#39;\u0026gt;=7.3.x\u0026#39;\u0026#34;}\rComponentSubscription Status Observed Generation The replication-controller reports an observed generation in the ComponentSubscription\u0026rsquo;s .status.observedGeneration. The observed generation is the latest .metadata.generation, which resulted in either a ready state or stalled due to an error it can not recover from without human intervention.\nConditions ComponentSubscription has various states during its lifecycle, reflected as Kubernetes Conditions. These are as follows:\nreconciling signature verification ready failed reconciling Last Applied Version The LastAppliedVersion field holds information regarding the most up-to-date version that has been successfully replicated to the destination repository.\nReplicated Repository URL ReplicatedRepositoryURL holds information regarding the repository\u0026rsquo;s URL into which the last applied version has been replicated.\n","date":"2023-07-11","id":27,"permalink":"/docs/controller/controller-reference/replication-controller/component-subscription/","summary":"\u003cp\u003eThe \u003ccode\u003eComponentSubscription\u003c/code\u003e API produces component descriptors for a specific component version.\u003c/p\u003e\n\u003ch2 id=\"example\"\u003eExample\u003c/h2\u003e\n\u003cp\u003eThe following is an example of a ComponentSubscription:\u003c/p\u003e","tags":[],"title":"Component Subscription"},{"content":"","date":"2020-10-06","id":28,"permalink":"/docs/tutorials/","summary":"","tags":[],"title":"Tutorials"},{"content":"Introduction In this guide, we will show you how the tools provided by OCM make it possible to automate your air-gapped deployments.\nAir-gapped can mean different things depending on the context. For this guide, we\u0026rsquo;ll assume it means your deployment artifacts are stored in a private registry protected by the security controls at your organization. Your applications only have access to this private registry and little to no public internet access.\nWe\u0026rsquo;ll take the same podinfo component that we deployed in the Deploy Applications with OCM \u0026amp; GitOps guide but this time we will use the OCM CLI to transfer the component to our own registry. The application will then be deployed from this \u0026ldquo;private\u0026rdquo; registry. This, of course, mimics a real-world air-gap scenario. In practice, there could be many layers of security between the two registries; however, the mechanics are ultimately the same.\nTable of Contents Introduction Table of Contents Requirements Component Content Component Transfer GitOps \u0026amp; Localization Verification To Be Continued Conclusion Requirements OCM command line tool kubectl git gh kind flux Component Content The podinfo component contains three resources:\na container image for podinfo a kubernetes deployment manifest for podinfo a configuration file read by the ocm-controller We can list these resources using the ocm CLI:\nocm get resources ghcr.io/phoban01//phoban.io/podinfo -c v6.3.5 NAME VERSION IDENTITY TYPE RELATION config 6.3.5 PlainText local deployment 6.3.5 Directory local image 6.3.5 ociImage external\rIf we examine the config file, we will see a section named localization:\nocm download resource ghcr.io/phoban01//phoban.io/podinfo -c v6.3.5 config -O - apiVersion: config.ocm.software/v1alpha1 kind: ConfigData metadata: name: ocm-config ... localization: - name: image # rule name file: deployment.yaml # target file for substitution image: spec.template.spec.containers[0].image # path in file to insert image name resource: # ocm resource from which to resolve the image location name: image\rThe localization section contains a list of rules that describe the substitutions the ocm-controller needs to perform to ensure that the Local copy of our image is deployed. OCM provides an identifier for each resource which can always be resolved to a specific storage location at which the resource can be accessed. This secret sauce makes it possible to automate air-gapped deployments using OCM.\nWe can examine the image resource to see precisely where the image can be accessed:\nocm get resources ghcr.io/phoban01//phoban.io/podinfo -c 6.3.5 image -owide NAME VERSION IDENTITY TYPE RELATION ACCESSTYPE ACCESSSPEC image 6.3.5 ociImage external ociArtifact {\u0026#34;imageReference\u0026#34;:\u0026#34;ghcr.io/stefanprodan/podinfo:6.3.5\u0026#34;}\rComponent Transfer We can use the ocm CLI to transfer this public component into our \u0026ldquo;private\u0026rdquo; registry. Because we are simulating an air-gapped install, we instruct the ocm CLI to copy the resources along with the component metadata:\nAIR_GAPPED_REGISTRY=ghcr.io/phoban01/air-gapped ocm transfer component --copy-resources ghcr.io/phoban01//phoban.io/podinfo $AIR_GAPPED_REGISTRY\rIt will take few moments to complete the transfer. Once it is complete we can view the component in the air-gapped registry:\nocm get component ghcr.io/phoban01/air-gapped//phoban.io/podinfo COMPONENT VERSION PROVIDER phoban.io/podinfo 6.2.3 phoban.io phoban.io/podinfo 6.3.5 phoban.io\rLet\u0026rsquo;s examine the image resource on the component in our private registry:\nocm get resources $AIR_GAPPED_REGISTRY//phoban.io/podinfo -c 6.3.5 image -owide NAME VERSION IDENTITY TYPE RELATION ACCESSTYPE ACCESSSPEC image 6.3.5 ociImage external ociArtifact {\u0026#34;imageReference\u0026#34;:\u0026#34;ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5\u0026#34;}\rWe can see that the image reference now points to an image stored in our air-gapped registry.\nGitOps \u0026amp; Localization Now that our component has been successfully transferred, let\u0026rsquo;s deploy it using GitOps.\nWe assume you have completed the Deploy Applications with OCM \u0026amp; GitOps guide and will use that repository as the starting point for our air-gapped deployment.\nBecause our air-gapped OCM repository is private, we need to provide credentials. This will enable the ocm-controller to retrieve components from the repository.\nWe can do this using a ServiceAccount. First, create an Kubernetes Secret to hold the credentials:\nkubectl create secret docker-registry -n ocm-system ghcr-cred \\ --docker-server=ghcr.io \\ --docker-username=$GITHUB_USER \\ --docker-password=$GITHUB_TOKEN\rThen, create the ServiceAccount:\ncat \u0026gt; ./components/service_account.yaml \u0026lt;\u0026lt;EOF apiVersion: v1 kind: ServiceAccount metadata: name: air-gapped-ops namespace: ocm-system imagePullSecrets: - name: ghcr-cred EOF\rNext, let\u0026rsquo;s modify the ComponentVersion manifest so that it points to our air-gapped OCM repository and references the ServiceAccount:\napiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion metadata: name: podinfo namespace: ocm-system spec: interval: 1m0s component: phoban.io/podinfo version: semver: \u0026#34;\u0026gt;=v6.3.5\u0026#34; repository: url: ghcr.io/phoban01/air-gapped serviceAccountName: air-gapped-ops\rNow we need to tell the ocm-controller to use the Localization rules we discussed earlier. To do this, we create a Localization Custom Resource:\ncat \u0026gt; ./components/localization.yaml \u0026gt;\u0026gt;EOF apiVersion: delivery.ocm.software/v1alpha1 kind: Localization metadata: name: podinfo-deployment namespace: ocm-system spec: interval: 5m sourceRef: kind: Resource name: podinfo-deployment # this is the podinfo deployment manifest resource we created previously configRef: kind: ComponentVersion name: podinfo resourceRef: name: config # here we reference the resource containing localization rules EOF\rYou can see that we have used the existing Resource as the source for the Localization and have provided the localization rules using the spec.configRef field. The ocm-controller enables us to freely chain resources together in order to perform a sequence of transformations upon an OCM resource.\nBecause the output we want to deploy is now generated by the Localization CR rather than the Resource CR, we need to update our FluxDeployer:\napiVersion: delivery.ocm.software/v1alpha1 kind: FluxDeployer metadata: name: podinfo namespace: ocm-system spec: sourceRef: kind: Localization name: podinfo-deployment kustomizationTemplate: interval: 1m0s path: ./ prune: true targetNamespace: default\rLet\u0026rsquo;s commit, push, and reconcile these changes:\ngit add ./components git commit -m \u0026#34;move to air-gapped repository\u0026#34; git push flux reconcile source git flux-system\rVerification Flux should now be reconciling the Localized manifest with image references pointing to our private OCM repository.\nWe can easily verify this using kubectl:\nkubectl get deployment -n default podinfo -oyaml | grep image | xargs image: ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5\rTo Be Continued If we look closer, however, we will see that our application has not successfully rolled out:\nkubectl get po -n default NAME READY STATUS RESTARTS AGE podinfo-7b7d874bf8-xv75x 0/1 ImagePullBackOff 0 1m4s\rIf we filter the events we can see that Kubernetes cannot pull the image owing to missing credentials:\nkubectl get events --field-selector involvedObject.kind=Pod LAST SEEN TYPE REASON OBJECT MESSAGE 7m31s Normal Scheduled pod/podinfo-7b7d874bf8-xv75x Successfully assigned default/podinfo-7b7d874bf8-xv75x to kind-control-plane 6m7s Normal Pulling pod/podinfo-7b7d874bf8-xv75x Pulling image \u0026#34;ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5\u0026#34; 6m6s Warning Failed pod/podinfo-7b7d874bf8-xv75x Failed to pull image \u0026#34;ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5\u0026#34;: rpc error: code = Unknown desc = failed to pull and unpack image \u0026#34;ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5\u0026#34;: failed to resolve reference \u0026#34;ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5\u0026#34;: failed to authorize: failed to fetch anonymous token: unexpected status: 401 Unauthorized 6m6s Warning Failed pod/podinfo-7b7d874bf8-xv75x Error: ErrImagePull 2m31s Normal BackOff pod/podinfo-7b7d874bf8-xv75x Back-off pulling image \u0026#34;ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5\u0026#34; 5m44s Warning Failed pod/podinfo-7b7d874bf8-xv75x Error: ImagePullBackOff\rCheck out our GitOps Driven Configuration of OCM Applications guide to see how we can use the ocm-controller to configure our application at runtime and solve exactly this kind of problem!\nConclusion In this tutorial we have shown how we can automate the process of delivering software to air-gapped environments using the Open Component Model and Flux.\nWe have shown how the process of Localization is enabled via OCM and combined with GitOps delivers a seamless application deployment model suitable for any environment.\n","date":"0001-01-01","id":29,"permalink":"/docs/tutorials/ocm-and-gitops/air-gapped-gitops-with-ocm-flux/","summary":"\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eIn this guide, we will show you how the tools provided by OCM make it possible to automate your air-gapped deployments.\u003c/p\u003e","tags":[],"title":"Air-gapped GitOps with OCM \u0026 Flux"},{"content":"This chapter contains guidelines for common scenarios how to work with the Open Component Model, focusing on using CI/CD, build and publishing processes.\nUse Public Schema for Validation and Auto-Completion of Component Descriptors Separate Build and Publish Processes Separation Between Build and Publish Building Multi-Architecture Images Using Makefiles Prerequisites Templating the Resources Pipeline Integration Static and Dynamic Variable Substitution Debugging: Explain the Blobs Directory Self-Contained Transport Archives CICD Integration Use Public Schema for Validation and Auto-Completion of Component Descriptors The Open Component Model (OCM) provides a public schema to validate and offer auto-completion of component constructor files used to create component descriptors. This schema is available at https://ocm.software/schemas/configuration-schema.yaml.\nTo use this schema in your IDE, you can add the following line to your component constructor file:\n# yaml-language-server: $schema=https://ocm.software/schemas/configuration-schema.yaml\rThis line tells the YAML language server to use the OCM schema for validation and auto-completion.\nSeparate Build and Publish Processes Traditional automated builds often have unrestricted internet access, which can lead to several challenges in enterprise environments:\nLimited control over downloaded artifacts Potential unavailability of required resources Security risks associated with write permissions to external repositories Best practice: Implement a two-step process: a) Build: Create artifacts in a controlled environment, using local mirrors when possible. b) Publish: Use a separate, secured process to distribute build results.\nOCM supports this approach through filesystem-based OCM repositories, allowing you to generate Common Transport Format (CTF) archives for component versions. These archives can then be securely processed and distributed.\nSeparation Between Build and Publish Typical automated builds have access to the complete internet ecosystem. This involves downloading of content required for a build (e.g., go mod tidy), but also the upload of build results to repositories (e.g., OCI image registries).\nFor builds in enterprise environments this can lead to several challenges:\nLimited control over downloaded artifacts Potential unavailability of required resources Security risks associated with write permissions to external repositories The first problem might be acceptable, because the build results may be analyzed by scanners later to figure out what has been packaged. Triaging the results could be done in an asynchronous step later.\nThe second problem could be solved by mirroring the required artifacts and instrument the build to use the artifacts from the local mirror. Such a mirror would also offer a solution for the first problem and act as target for various scanning tools.\nThe third problem might pose severe security risks, because the build procedure as well as the downloaded artifacts may be used to catch registry credentials or at least corrupt the content of those repositories.\nThis could be avoided by establishing a contract between the build procedure of a component/project and the build system, providing the build result as a local file or file-structure. This is then taken by the build system to push content wherever it should be pushed to. This way the execution of the build procedure does not need write permissions to any repository, because it never pushes build results.\nThe Open Component Model supports such processes by supporting filesystem based OCM repositories, which are able to host any type of content, regardless of its technology. The task of the build then is to provide such a CTF archive for the OCM component versions generated by the build. This archive can then be used by the build-system to do whatever is required to make the content accessible by others.\nThe composition of such archives is described in the Getting Started section.\nTo secure further processes, a certified build-system could even sign the content with its build system certificate to enable followup-processes to verify that involved component versions are provided by accepted and well-known processes.\nBuilding Multi-Architecture Images Note: This section provides information only on on building multi-arch images. Referencing a multi-arch image does not differ from images for just one platform, see the ocm add resources command for the OCM CLI\nAt the time of writing this guide Docker is not able to build multi-architecture (multi-arch / multi-platform) images natively. Instead, the buildx plugin is used. However, this implies building and pushing images in one step to a remote container registry as the local Docker image store does not support multi-arch images (for additional information, see the Multi-arch build and images, the simple way blog post)\nThe OCM CLI has some built-in support for dealing with multi-arch images during the component version composition (ocm add resources). This allows building all artifacts locally and push them in a separate step to a container registry. This is done by building single-arch images in a first step (still using buildx for cross-platform building). In a second step all images are bundled into a multi-arch image, which is stored as local artifact in a component (CA) or common transport (CTF) archive. This archive can be processed as usual (e.g., for signing or transfer to other locations). When pushed to an image registry, multi-arch images are generated with a multi-arch-image manifest.\nThe following steps illustrate this procedure. For a simple project with a Go binary and a helm-chart assume the following file structure:\ntree . . ├── Dockerfile ├── go.mod ├── helmchart │ ├── Chart.yaml │ ├── templates │ │ ├── ... │ └── values.yaml └── main.go\rThe Dockerfile has the following content:\nFROM golang:1.19 AS builder WORKDIR /app COPY go.mod ./ COPY main.go ./ # RUN go mod download RUN go build -o /helloserver main.go # Create a new release build stage FROM gcr.io/distroless/base-debian10 # Set the working directory to the root directory path WORKDIR / # Copy over the binary built from the previous stage COPY --from=builder /helloserver /helloserver ENTRYPOINT [\u0026#34;/helloserver\u0026#34;]\rNow we want to build images for two platforms using Docker and buildx. Note the --load option for buildx to store the image in the local Docker store. Note the architecture suffix in the tag to be able to distinguish the images for the different platforms. Also note that the tag has a different syntax than the --platform argument for buildx as slashes are not allowed in tags.\n$ TAG_PREFIX=eu.gcr.io/my-project/acme # path to you OCI registry $ PLATFORM=linux/amd64 $ VERSION=0.1.0 $ docker buildx build --load -t ${TAG_PREFIX}/simpleserver:0.1.0-linux-amd64 --platform linux/amd64 . [+] Building 54.4s (14/14) FINISHED =\u0026gt; [internal] load build definition from dockerfile 0.0s =\u0026gt; =\u0026gt; transferring dockerfile: 660B 0.0s =\u0026gt; [internal] load .dockerignore 0.0s =\u0026gt; =\u0026gt; transferring context: 2B 0.0s =\u0026gt; [internal] load metadata for gcr.io/distroless/base-debian10:latest 1.6s =\u0026gt; [internal] load metadata for docker.io/library/golang:1.19 1.2s =\u0026gt; [builder 1/5] FROM docker.io/library/golang:1.19@sha256:dc76ef03e54c34a00dcdca81e55c242d24b34d231637776c4bb5c1a8e851425 49.2s =\u0026gt; =\u0026gt; resolve docker.io/library/golang:1.19@sha256:dc76ef03e54c34a00dcdca81e55c242d24b34d231637776c4bb5c1a8e8514253 0.0s =\u0026gt; =\u0026gt; sha256:14a70245b07c7f5056bdd90a3d93e37417ec26542def5a37ac8f19e437562533 156B / 156B 0.2s =\u0026gt; =\u0026gt; sha256:a2b47720d601b6c6c6e7763b4851e25475118d80a76be466ef3aa388abf2defd 148.91MB / 148.91MB 46.3s =\u0026gt; =\u0026gt; sha256:52908dc1c386fab0271a2b84b6ef4d96205a98a8c8801169554767172e45d8c7 85.97MB / 85.97MB 42.9s =\u0026gt; =\u0026gt; sha256:195ea6a58ca87a18477965a6e6a8623112bde82c5b568a29c56ce4581b6e6695 54.59MB / 54.59MB 33.8s =\u0026gt; =\u0026gt; sha256:c85a0be79bfba309d1f05dc40b447aa82b604593531fed1e7e12e4bef63483a5 10.88MB / 10.88MB 3.4s =\u0026gt; =\u0026gt; sha256:e4e46864aba2e62ba7c75965e4aa33ec856ee1b1074dda6b478101c577b63abd 5.16MB / 5.16MB 1.5s =\u0026gt; =\u0026gt; sha256:a8ca11554fce00d9177da2d76307bdc06df7faeb84529755c648ac4886192ed1 55.04MB / 55.04MB 19.3s =\u0026gt; =\u0026gt; extracting sha256:a8ca11554fce00d9177da2d76307bdc06df7faeb84529755c648ac4886192ed1 1.1s =\u0026gt; =\u0026gt; extracting sha256:e4e46864aba2e62ba7c75965e4aa33ec856ee1b1074dda6b478101c577b63abd 0.1s =\u0026gt; =\u0026gt; extracting sha256:c85a0be79bfba309d1f05dc40b447aa82b604593531fed1e7e12e4bef63483a5 0.1s =\u0026gt; =\u0026gt; extracting sha256:195ea6a58ca87a18477965a6e6a8623112bde82c5b568a29c56ce4581b6e6695 1.1s =\u0026gt; =\u0026gt; extracting sha256:52908dc1c386fab0271a2b84b6ef4d96205a98a8c8801169554767172e45d8c7 1.5s =\u0026gt; =\u0026gt; extracting sha256:a2b47720d601b6c6c6e7763b4851e25475118d80a76be466ef3aa388abf2defd 2.8s =\u0026gt; =\u0026gt; extracting sha256:14a70245b07c7f5056bdd90a3d93e37417ec26542def5a37ac8f19e437562533 0.0s =\u0026gt; [stage-1 1/3] FROM gcr.io/distroless/base-debian10@sha256:101798a3b76599762d3528635113f0466dc9655ecba82e8e33d410e2bf5cd 30.7s =\u0026gt; =\u0026gt; resolve gcr.io/distroless/base-debian10@sha256:101798a3b76599762d3528635113f0466dc9655ecba82e8e33d410e2bf5cd319 0.0s =\u0026gt; =\u0026gt; sha256:f291067d32d8d06c3b996ba726b9aa93a71f6f573098880e05d16660cfc44491 8.12MB / 8.12MB 30.6s =\u0026gt; =\u0026gt; sha256:2445dbf7678f5ec17f5654ac2b7ad14d7b1ea3af638423fc68f5b38721f25fa4 657.02kB / 657.02kB 1.3s =\u0026gt; =\u0026gt; extracting sha256:2445dbf7678f5ec17f5654ac2b7ad14d7b1ea3af638423fc68f5b38721f25fa4 0.1s =\u0026gt; =\u0026gt; extracting sha256:f291067d32d8d06c3b996ba726b9aa93a71f6f573098880e05d16660cfc44491 0.1s =\u0026gt; [internal] load build context 0.1s =\u0026gt; =\u0026gt; transferring context: 575B 0.0s =\u0026gt; [builder 2/5] WORKDIR /app 0.1s =\u0026gt; [builder 3/5] COPY go.mod ./ 0.0s =\u0026gt; [builder 4/5] COPY main.go ./ 0.0s =\u0026gt; [builder 5/5] RUN go build -o /helloserver main.go 2.4s =\u0026gt; [stage-1 2/3] COPY --from=builder /helloserver /helloserver 0.0s =\u0026gt; exporting to oci image format 0.8s =\u0026gt; =\u0026gt; exporting layers 0.2s =\u0026gt; =\u0026gt; exporting manifest sha256:04d69fc3245757d327d96b1a83b7a64543d970953c61d1014ae6980ed8b3ba2a 0.0s =\u0026gt; =\u0026gt; exporting config sha256:08641d64f612661a711587b07cfeeb6d2804b97998cfad85864a392c1aabcd06 0.0s =\u0026gt; =\u0026gt; sending tarball 0.6s =\u0026gt; importing to docker\rRepeat this command for the second platform:\n$ docker buildx build --load -t ${TAG_PREFIX}/simpleserver:0.1.0-linux-arm64 --platform linux/arm64 . docker buildx build --load -t ${TAG_PREFIX}/simpleserver:0.1.0-linux-arm64 --platform linux/arm64 . [+] Building 40.1s (14/14) FINISHED =\u0026gt; [internal] load .dockerignore 0.0s =\u0026gt; =\u0026gt; transferring context: 2B 0.0s =\u0026gt; [internal] load build definition from dockerfile 0.0s =\u0026gt; =\u0026gt; transferring dockerfile: 660B 0.0s =\u0026gt; [internal] load metadata for gcr.io/distroless/base-debian10:latest 1.0s =\u0026gt; [internal] load metadata for docker.io/library/golang:1.19 1.1s =\u0026gt; [builder 1/5] FROM docker.io/library/golang:1.19@sha256:dc76ef03e54c34a00dcdca81e55c242d24b34d231637776c4bb5c1a8e851425 37.7s =\u0026gt; =\u0026gt; resolve docker.io/library/golang:1.19@sha256:dc76ef03e54c34a00dcdca81e55c242d24b34d231637776c4bb5c1a8e8514253 0.0s =\u0026gt; =\u0026gt; sha256:cd807e8b483974845eabbdbbaa4bb3a66f74facd8c061e01e923e9f1da608271 157B / 157B 0.2s =\u0026gt; =\u0026gt; sha256:fecd6ba4b3f93b6c90f4058b512f1b0a44223ccb3244f0049b16fe2c1b41cf45 115.13MB / 115.13MB 35.6s =\u0026gt; =\u0026gt; sha256:4fb255e3f99867ec7a2286dfbbef990491cde0a5d226d92be30bad4f9e917fa4 81.37MB / 81.37MB 31.8s =\u0026gt; =\u0026gt; sha256:426e8acfed2a5373bd99b22b5a968d55a148e14bc0e0f51c5cf0d779afefe291 54.68MB / 54.68MB 26.7s =\u0026gt; =\u0026gt; sha256:3d7b1480fa4dae5cbbb7d091c46ae0ae52f501418d4cfeb849b87023364e2564 10.87MB / 10.87MB 3.0s =\u0026gt; =\u0026gt; sha256:a3e29af4daf3531efcc63588162e8bdcf3434aa5d72df4eabeb5e20c6695e303 5.15MB / 5.15MB 1.3s =\u0026gt; =\u0026gt; sha256:077c13527d405646e2f6bb426e04716ae4f8dd2fdd8966dcb0194564a2b57896 53.70MB / 53.70MB 13.3s =\u0026gt; =\u0026gt; extracting sha256:077c13527d405646e2f6bb426e04716ae4f8dd2fdd8966dcb0194564a2b57896 0.9s =\u0026gt; =\u0026gt; extracting sha256:a3e29af4daf3531efcc63588162e8bdcf3434aa5d72df4eabeb5e20c6695e303 0.3s =\u0026gt; =\u0026gt; extracting sha256:3d7b1480fa4dae5cbbb7d091c46ae0ae52f501418d4cfeb849b87023364e2564 0.1s =\u0026gt; =\u0026gt; extracting sha256:426e8acfed2a5373bd99b22b5a968d55a148e14bc0e0f51c5cf0d779afefe291 1.2s =\u0026gt; =\u0026gt; extracting sha256:4fb255e3f99867ec7a2286dfbbef990491cde0a5d226d92be30bad4f9e917fa4 1.4s =\u0026gt; =\u0026gt; extracting sha256:fecd6ba4b3f93b6c90f4058b512f1b0a44223ccb3244f0049b16fe2c1b41cf45 2.0s =\u0026gt; =\u0026gt; extracting sha256:cd807e8b483974845eabbdbbaa4bb3a66f74facd8c061e01e923e9f1da608271 0.0s =\u0026gt; [stage-1 1/3] FROM gcr.io/distroless/base-debian10@sha256:101798a3b76599762d3528635113f0466dc9655ecba82e8e33d410e2bf5cd 25.7s =\u0026gt; =\u0026gt; resolve gcr.io/distroless/base-debian10@sha256:101798a3b76599762d3528635113f0466dc9655ecba82e8e33d410e2bf5cd319 0.0s =\u0026gt; =\u0026gt; sha256:21d6a6c3921f47fb0a96eb028b4c3441944a6e5a44b30cd058425ccc66279760 7.13MB / 7.13MB 25.5s =\u0026gt; =\u0026gt; sha256:7d441aeb75fe3c941ee4477191c6b19edf2ad8310bac7356a799c20df198265c 657.02kB / 657.02kB 1.3s =\u0026gt; =\u0026gt; extracting sha256:7d441aeb75fe3c941ee4477191c6b19edf2ad8310bac7356a799c20df198265c 0.1s =\u0026gt; =\u0026gt; extracting sha256:21d6a6c3921f47fb0a96eb028b4c3441944a6e5a44b30cd058425ccc66279760 0.1s =\u0026gt; [internal] load build context 0.0s =\u0026gt; =\u0026gt; transferring context: 54B 0.0s =\u0026gt; [builder 2/5] WORKDIR /app 0.2s =\u0026gt; [builder 3/5] COPY go.mod ./ 0.0s =\u0026gt; [builder 4/5] COPY main.go ./ 0.0s =\u0026gt; [builder 5/5] RUN go build -o /helloserver main.go 0.3s =\u0026gt; [stage-1 2/3] COPY --from=builder /helloserver /helloserver 0.0s =\u0026gt; exporting to oci image format 0.5s =\u0026gt; =\u0026gt; exporting layers 0.2s =\u0026gt; =\u0026gt; exporting manifest sha256:267ed1266b2b0ed74966e72d4ae8a2dfcf77777425d32a9a46f0938c962d9600 0.0s =\u0026gt; =\u0026gt; exporting config sha256:67102364e254bf5a8e58fa21ea56eb40645851d844f5c4d9651b4af7a40be780 0.0s =\u0026gt; =\u0026gt; sending tarball 0.3s =\u0026gt; importing to docker\rCheck that the images were created correctly:\n$ docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE eu.gcr.io/acme/simpleserver 0.1.0-linux-arm64 67102364e254 6 seconds ago 22.4MB eu.gcr.io/acme/simpleserver 0.1.0-linux-amd64 08641d64f612 About a minute ago 25.7MB\rIn the next step we create a component archive and a transport archive\nPROVIDER=acme COMPONENT=github.com/$(PROVIDER)/simpleserver VERSION=0.1.0 mkdir gen ocm create ca ${COMPONENT} ${VERSION} --provider ${PROVIDER} --file gen/ca\rCreate the file resources.yaml. Note the variants in the image input and the type dockermulti:\n--- name: chart type: helmChart input: type: helm path: helmchart --- name: image type: ociImage version: 0.1.0 input: type: dockermulti repository: eu.gcr.io/acme/simpleserver variants: - \u0026#34;eu.gcr.io/acme/simpleserver:0.1.0-linux-amd64\u0026#34; - \u0026#34;eu.gcr.io/acme/simpleserver:0.1.0-linux-arm64\u0026#34;\rThe input type dockermulti adds a multi-arch image composed by the given dedicated images from the local Docker image store as local artifact to the component archive.\nAdd the described resources to your component archive:\n$ ocm add resources ./gen/ca resources.yaml processing resources.yaml... processing document 1... processing index 1 processing document 2... processing index 1 found 2 resources adding resource helmChart: \u0026#34;name\u0026#34;=\u0026#34;chart\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;\u0026lt;componentversion\u0026gt;\u0026#34;... adding resource ociImage: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;0.1.0\u0026#34;... image 0: eu.gcr.io/acme/simpleserver:0.1.0-linux-amd64 image 1: eu.gcr.io/acme/simpleserver:0.1.0-linux-arm64 image 2: INDEX locator: github.com/acme/simpleserver, repo: eu.gcr.io/acme/simpleserver, version 0.1.0\rWhat happened? The input type dockermulti is used to compose a multi-arch image on-the fly. Like the input type docker it reads images from the local Docker daemon. In contrast to this command you can list multiple images, created for different platforms, for which an OCI index manifest is created to describe a multi-arch image. The complete set of blobs is then packaged as artifact set archive and put as single resource into the component version.\nThe resulting component-descriptor.yaml in gen/ca is:\ncomponent: componentReferences: [] name: github.com/acme/simpleserver provider: acme repositoryContexts: [] resources: - access: localReference: sha256.9dd0f2cbae3b8e6eb07fa947c05666d544c0419a6e44bd607e9071723186333b mediaType: application/vnd.oci.image.manifest.v1+tar+gzip referenceName: github.com/acme/simpleserver/helloserver:0.1.0 type: localBlob name: chart relation: local type: helmChart version: 0.1.0 - access: localReference: sha256.4e26c7dd46e13c9b1672e4b28a138bdcb086e9b9857b96c21e12839827b48c0c mediaType: application/vnd.oci.image.index.v1+tar+gzip referenceName: github.com/acme/simpleserver/eu.gcr.io/acme/simpleserver:0.1.0 type: localBlob name: image relation: local type: ociImage version: 0.1.0 sources: [] version: 0.1.0 meta: schemaVersion: v2\rNote that there is only one resource of type image with media-type application/vnd.oci.image.index.v1+tar+gzip which is the standard media type for multi-arch images.\n$ ls -l gen/ca/blobs total 24M -rw-r--r-- 1 d058463 staff 24M Dec 1 09:50 sha256.4e26c7dd46e13c9b1672e4b28a138bdcb086e9b9857b96c21e12839827b48c0c -rw-r--r-- 1 d058463 staff 4.7K Dec 1 09:50 sha256.9dd0f2cbae3b8e6eb07fa947c05666d544c0419a6e44bd607e9071723186333b\rThe file sha256.4e26\u0026hellip; contains the multi-arch image packaged as OCI artifact set:\n$ tar tvf gen/ca/blobs/sha256.4e26c7dd46e13c9b1672e4b28a138bdcb086e9b9857b96c21e12839827b48c0c -rw-r--r-- 0 0 0 741 Jan 1 2022 index.json -rw-r--r-- 0 0 0 38 Jan 1 2022 oci-layout drwxr-xr-x 0 0 0 0 Jan 1 2022 blobs -rw-r--r-- 0 0 0 3051520 Jan 1 2022 blobs/sha256.05ef21d763159987b9ec5cfb3377a61c677809552dcac3301c0bde4e9fd41bbb -rw-r--r-- 0 0 0 723 Jan 1 2022 blobs/sha256.117f12f0012875471168250f265af9872d7de23e19f0d4ef05fbe99a1c9a6eb3 -rw-r--r-- 0 0 0 6264832 Jan 1 2022 blobs/sha256.1496e46acd50a8a67ce65bac7e7287440071ad8d69caa80bcf144892331a95d3 -rw-r--r-- 0 0 0 6507520 Jan 1 2022 blobs/sha256.66817c8096ad97c6039297dc984ebc17c5ac9325200bfa9ddb555821912adbe4 -rw-r--r-- 0 0 0 491 Jan 1 2022 blobs/sha256.75a096351fe96e8be1847a8321bd66535769c16b2cf47ac03191338323349355 -rw-r--r-- 0 0 0 3051520 Jan 1 2022 blobs/sha256.77192cf194ddc77d69087b86b763c47c7f2b0f215d0e4bf4752565cae5ce728d -rw-r--r-- 0 0 0 1138 Jan 1 2022 blobs/sha256.91018e67a671bbbd7ab875c71ca6917484ce76cde6a656351187c0e0e19fe139 -rw-r--r-- 0 0 0 17807360 Jan 1 2022 blobs/sha256.91f7bcfdfda81b6c6e51b8e1da58b48759351fa4fae9e6841dd6031528f63b4a -rw-r--r-- 0 0 0 1138 Jan 1 2022 blobs/sha256.992b3b72df9922293c05f156f0e460a220bf601fa46158269ce6b7d61714a084 -rw-r--r-- 0 0 0 14755840 Jan 1 2022 blobs/sha256.a83c9b56bbe0f6c26c4b1d86e6de3a4862755d208c9dfae764f64b210eafa58c -rw-r--r-- 0 0 0 723 Jan 1 2022 blobs/sha256.e624040295fb78a81f4b4b08b43b4de419f31f21074007df8feafc10dfb654e6 $ tar xvf gen/ca/blobs/sha256.4e26c7dd46e13c9b1672e4b28a138bdcb086e9b9857b96c21e12839827b48c0c -O - index.json | jq . x index.json { \u0026#34;schemaVersion\u0026#34;: 2, \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.index.v1+json\u0026#34;, \u0026#34;manifests\u0026#34;: [ { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.manifest.v1+json\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:e624040295fb78a81f4b4b08b43b4de419f31f21074007df8feafc10dfb654e6\u0026#34;, \u0026#34;size\u0026#34;: 723 }, { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.manifest.v1+json\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:117f12f0012875471168250f265af9872d7de23e19f0d4ef05fbe99a1c9a6eb3\u0026#34;, \u0026#34;size\u0026#34;: 723 }, { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.index.v1+json\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:75a096351fe96e8be1847a8321bd66535769c16b2cf47ac03191338323349355\u0026#34;, \u0026#34;size\u0026#34;: 491, \u0026#34;annotations\u0026#34;: { \u0026#34;org.opencontainers.image.ref.name\u0026#34;: \u0026#34;0.1.0\u0026#34;, \u0026#34;software.ocm/tags\u0026#34;: \u0026#34;0.1.0\u0026#34; } } ], \u0026#34;annotations\u0026#34;: { \u0026#34;software.ocm/main\u0026#34;: \u0026#34;sha256:75a096351fe96e8be1847a8321bd66535769c16b2cf47ac03191338323349355\u0026#34; } }\rYou can create a common transport archive from the component archive.\ncm transfer ca gen/ca gen/ctf transferring version \u0026#34;github.com/acme/simpleserver:0.1.0\u0026#34;... ...resource 0(github.com/acme/simpleserver/helloserver:0.1.0)... ...resource 1(github.com/acme/simpleserver/eu.gcr.io/acme/simpleserver:0.1.0)... ...adding component version...\rOr you can push it directly to the OCM repository:\n$ OCMREPO=ghcr.io/${PROVIDER} $ ocm transfer ca gen/ca $OCMREPO transferring version \u0026#34;github.com/acme/simpleserver:0.1.0\u0026#34;... ...resource 0(github.com/acme/simpleserver/helloserver:0.1.0)... ...resource 1(github.com/acme/simpleserver/eu.gcr.io/acme/simpleserver:0.1.0)... ...adding component version...\rThe repository now should contain three additional artifacts. Depending on the OCI registry and the corresponding UI you may see that the uploaded OCI image is a multi-arch-image. For example on GitHub packages under the attribute OS/Arch you can see two platforms, linux/amd64 and linux/arm64\nFor automation and reuse purposes you may consider templating resource files and Makefiles (see below).\nUsing Makefiles Developing with the Open Component Model usually is an iterative process of building artifacts, generating component descriptors, analyzing and finally publishing them. To simplify and speed up this process it should be automated using a build tool. One option is to use a Makefile. The following example can be used as a starting point and can be modified according to your needs.\nIn this example we will automate the same example as in the sections before:\nCreating a multi-arch image from Go sources from a Git repository using the Docker CLI Packaging the image and a Helm chart into a common transport archive Signing and publishing the build result Prerequisites The OCM CLI must be installed and be available in your PATH The Makefile is located in the top-level folder of a Git project Operating system is Unix/Linux A sub-directory local can be used for local settings e.g. environment varibles, RSA keys, \u0026hellip; A sub-directory gen will be used for generated artifacts from the make buildcommand It is recommended to add local/ and gen/ to the .gitignore file We use the following file system layout for the example:\n$ tree . . ├── Dockerfile ├── LICENSE ├── Makefile ├── README.md ├── go.mod ├── helmchart │ ├── Chart.yaml │ ├── templates │ │ ├── NOTES.txt │ │ ├── _helpers.tpl │ │ ├── deployment.yaml │ │ ├── hpa.yaml │ │ ├── ingress.yaml │ │ ├── service.yaml │ │ ├── serviceaccount.yaml │ │ └── tests │ │ └── test-connection.yaml │ └── values.yaml ├── local │ └── env.sh ├── main.go ├── resources.yaml └── VERSION\rThis Makefile can be used NAME ?= simpleserver PROVIDER ?= acme.org GITHUBORG ?= acme IMAGE = ghcr.io/$(GITHUBORG)/demo/$(NAME) COMPONENT = $(PROVIDER)/demo/$(NAME) OCMREPO ?= ghcr.io/$(GITHUBORG)/ocm MULTI ?= true PLATFORMS ?= linux/amd64 linux/arm64 REPO_ROOT = . VERSION = $(shell git describe --tags --exact-match 2\u0026gt;/dev/null|| echo \u0026#34;$$(cat $(REPO_ROOT)/VERSION)\u0026#34;) COMMIT = $(shell git rev-parse HEAD) EFFECTIVE_VERSION = $(VERSION)-$(COMMIT) GIT_TREE_STATE := $(shell [ -z \u0026#34;$(git status --porcelain 2\u0026gt;/dev/null)\u0026#34; ] \u0026amp;\u0026amp; echo clean || echo dirty) GEN = ./gen OCM = ocm CHART_SRCS=$(shell find helmchart -type f) GO_SRCS=$(shell find . -name \\*.go -type f) ifeq ($(MULTI),true) FLAGSUF = .multi endif .PHONY: build build: $(GEN)/build .PHONY: version version: @echo $(VERSION) .PHONY: ca ca: $(GEN)/ca $(GEN)/ca: $(GEN)/.exists $(GEN)/image.$(NAME)$(FLAGSUF) resources.yaml $(CHART_SRCS) $(OCM) create ca -f $(COMPONENT) \u0026#34;$(VERSION)\u0026#34; --provider $(PROVIDER) --file $(GEN)/ca $(OCM) add resources --templater spiff $(GEN)/ca COMMIT=\u0026#34;$(COMMIT)\u0026#34; VERSION=\u0026#34;$(VERSION)\u0026#34; \\ IMAGE=\u0026#34;$(IMAGE):$(VERSION)\u0026#34; PLATFORMS=\u0026#34;$(PLATFORMS)\u0026#34; MULTI=$(MULTI) resources.yaml @touch $(GEN)/ca $(GEN)/build: $(GO_SRCS) go build . @touch $(GEN)/build .PHONY: image image: $(GEN)/image.$(NAME) $(GEN)/image.$(NAME): $(GEN)/.exists Dockerfile $(OCMSRCS) docker build -t $(IMAGE):$(VERSION) --file Dockerfile $(COMPONENT_ROOT) .; @touch $(GEN)/image.$(NAME) .PHONY: multi multi: $(GEN)/image.$(NAME).multi $(GEN)/image.$(NAME).multi: $(GEN)/.exists Dockerfile $(GO_SRCS) echo \u0026#34;Building Multi $(PLATFORMS)\u0026#34; for i in $(PLATFORMS); do \\ tag=$$(echo $$i | sed -e s:/:-:g); \\ echo \u0026#34;Building platform $$i with tag: $$tag\u0026#34;; \\ docker buildx build --load -t $(IMAGE):$(VERSION)-$$tag --platform $$i .; \\ done @touch $(GEN)/image.$(NAME).multi .PHONY: ctf ctf: $(GEN)/ctf $(GEN)/ctf: $(GEN)/ca @rm -rf $(GEN)/ctf $(OCM) transfer ca $(GEN)/ca $(GEN)/ctf touch $(GEN)/ctf .PHONY: push push: $(GEN)/ctf $(GEN)/push.$(NAME) $(GEN)/push.$(NAME): $(GEN)/ctf $(OCM) transfer ctf -f $(GEN)/ctf $(OCMREPO) @touch $(GEN)/push.$(NAME) .PHONY: transport transport: ifneq ($(TARGETREPO),) $(OCM) transfer component -Vc $(OCMREPO)//$(COMPONENT):$(VERSION) $(TARGETREPO) else @echo \u0026#34;Cannot transport no TARGETREPO defined as destination\u0026#34; \u0026amp;\u0026amp; exit 1 endif $(GEN)/.exists: @mkdir -p $(GEN) @touch $@ .PHONY: info info: @echo \u0026#34;VERSION: $(VERSION)\u0026#34; @echo \u0026#34;COMMIT: $(COMMIT)\u0026#34; @echo \u0026#34;TREESTATE: $(GIT_TREE_STATE)\u0026#34; .PHONY: describe describe: $(GEN)/ctf ocm get resources --lookup $(OCMREPO) -r -o treewide $(GEN)/ctf .PHONY: descriptor descriptor: $(GEN)/ctf ocm get component -S v3alpha1 -o yaml $(GEN)/ctf .PHONY: clean clean: rm -rf $(GEN) The Makefile supports the following targets:\nbuild (default) simple Go build version show current VERSION of Github repository image build a local Docker image multi build multi-arch images with Docker ca execute build and create a component archive ctf create a common transport format archive push push the common transport archive to an OCI registry info show variables used in Makefile (version, commit, etc.) describe display the component version in a tree-form descriptor show the component descriptor of the component version transport transport the component from the upload repository into another OCM repository clean delete all generated files (but does not delete Docker images) The variables assigned with ?= at the beginning can be set from outside and override the default declared in the Makefile. Use either an environment variable or an argument when calling make.\nExample:\nPROVIDER=foo make ca\rTemplating the Resources The Makefile uses a dynamic list of generated platforms for the images. You can just set the PLATFORMS variable:\nMULTI ?= true PLATFORMS ?= linux/amd64 linux/arm64 If MULTI is set to true, the variable PLATFORMS will be evaluated to decide which image variants will be built. This has to be reflected in the resources.yaml. It has to use the input type dockermulti and list all the variants which should be packaged into a multi-arch image. This list depends on the content of the Make variable.\nThe OCM CLI supports this by enabling templating mechanisms for the content by selecting a templater using the option --templater .... The example uses the Spiff templater.\n$(GEN)/ca: $(GEN)/.exists $(GEN)/image.$(NAME)$(FLAGSUF) resources.yaml $(CHART_SRCS) $(OCM) create ca -f $(COMPONENT) \u0026#34;$(VERSION)\u0026#34; --provider $(PROVIDER) --file $(GEN)/ca $(OCM) add resources --templater spiff $(GEN)/ca COMMIT=\u0026#34;$(COMMIT)\u0026#34; VERSION=\u0026#34;$(VERSION)\u0026#34; \\ IMAGE=\u0026#34;$(IMAGE):$(VERSION)\u0026#34; PLATFORMS=\u0026#34;$(PLATFORMS)\u0026#34; MULTI=$(MULTI) resources.yaml @touch $(GEN)/ca The variables given to the add resources command are passed to the templater. The template looks like:\nname: image type: ociImage version: (( values.VERSION )) input: type: (( bool(values.MULTI) ? \u0026#34;dockermulti\u0026#34; :\u0026#34;docker\u0026#34; )) repository: (( index(values.IMAGE, \u0026#34;:\u0026#34;) \u0026gt;= 0 ? substr(values.IMAGE,0,index(values.IMAGE,\u0026#34;:\u0026#34;)) :values.IMAGE )) variants: (( bool(values.MULTI) ? map[split(\u0026#34; \u0026#34;, values.PLATFORMS)|v|-\u0026gt; values.IMAGE \u0026#34;-\u0026#34; replace(v,\u0026#34;/\u0026#34;,\u0026#34;-\u0026#34;)] :~~ )) path: (( bool(values.MULTI) ? ~~ :values.IMAGE ))\rBy using a variable values.MULTI, the command distinguishes between a single Docker image and a multi-arch image. With map[], the platform list from the Makefile is mapped to a list of tags created by the docker buildx command used in the Makefile. The value ~~ is used to undefine the yaml fields not required for the selected case (the template can be used for multi- and single-arch builds).\n$(GEN)/image.$(NAME).multi: $(GEN)/.exists Dockerfile $(GO_SRCS) echo \u0026#34;Building Multi $(PLATFORMS)\u0026#34; for i in $(PLATFORMS); do \\ tag=$$(echo $$i | sed -e s:/:-:g); \\ echo \u0026#34;Building platform $$i with tag: $$tag\u0026#34;; \\ docker buildx build --load -t $(IMAGE):$(VERSION)-$$tag --platform $$i .; \\ done @touch $(GEN)/image.$(NAME).multi Pipeline Integration Pipeline infrastructures are heterogenous, so there is no universal answer how to integrate a build pipeline with OCM. Usually, the simplest way is using the OCM command line interface. Following you will find an example using GitHub actions.\nThere are two repositories dealing with GitHub actions: The first one provides various actions that can be called from a workflow. The second one provides the required installations of the OCM parts into the container.\nAn typical workflow for a build step will create a component version and a transport archive:\njobs: create-ocm: runs-on: ubuntu-latest steps: ... - name: setup OCM uses: open-component-model/ocm-setup-action@main ... - name: create OCM component version uses: open-component-model/ocm-action@main with: action: create_component component: acme.org/demo/simpleserver provider: ${{ env.PROVIDER }} version: github.com/jensh007 ...\rThis creates a component version for the current build. Additionally, a transport archive may be created or the component version along with the built container images may be uploaded to an OCI registry, etc.\nMore documentation is available here. A full example can be found in the sample Github repository.\nStatic and Dynamic Variable Substitution Looking at the settings file shows that some variables like the version or the commit change with every build or release. In many cases, these variables will be auto-generated during the build.\nOther variables like the version of 3rd-party components will just change from time to time and are often set manually by an engineer or release manager. It is useful to separate between static and dynamic variables. Static files can be checked-in into the source control system and are maintained manually. Dynamic variables can be generated during build.\nExample: manually maintained:\nNAME: microblog COMPONENT_NAME_PREFIX: github.com/acme.org/microblog PROVIDER: ocm.software ELASTIC_VERSION: 8.5.1 MARIADB_VERSION: 10.6.11 MARIADB_CHART_VERSION: 11.4.2 NGINX_VERSION: 1.5.1 NGINX_CHART_VERSION: 4.4.2\rauto-generated from a build script:\nVERSION: 0.23.1 COMMIT: 5f03021059c7dbe760ac820a014a8a84166ef8b4\rocm add componentversions --create --file ../gen/ctf --settings ../gen/dynamic_settings.yaml --settings static_settings.yaml component-constructor.yaml\rDebugging: Explain the Blobs Directory For analyzing and debugging the content of a transport archive, there are some supportive commands to analyze what is contained in the archive and what is stored in which blob:\ntree ../gen/ctf ../gen/ctf ├── artifact-index.json └── blobs ├── ... ├── sha256.59ff88331c53a2a94cdd98df58bc6952f056e4b2efc8120095fbc0a870eb0b67 ├── ...\rocm get resources -r -o wide ../gen/ctf ... --- REFERENCEPATH: github.com/acme.org/microblog/nginx-controller:1.5.1 NAME : nginx-controller-chart VERSION : 1.5.1 IDENTITY : TYPE : helmChart RELATION : local ACCESSTYPE : localBlob ACCESSSPEC : {\u0026#34;localReference\u0026#34;:\u0026#34;sha256:59ff88331c53a2a94cdd98df58bc6952f056e4b2efc8120095fbc0a870eb0b67\u0026#34;,\u0026#34;mediaType\u0026#34;:\u0026#34;application/vnd.oci.image.manifest.v1+tar+gzip\u0026#34;,\u0026#34;referenceName\u0026#34;:\u0026#34;github.com/acme.org/microblog/nginx-controller/ingress-nginx:4.4.2\u0026#34;} ...\rSelf-Contained Transport Archives The transport archive created from a component-constructor file, using the command ocm add componentversions --create ..., does not automatically resolve image references to external OCI registries and stores them in the archive. If you want to create a self-contained transport archive with all images stored as local artifacts, you need to use the --copy-resources option of the ocm transfer ctf command. This will copy all external images to the blobs directory of the archive.\nocm transfer ctf --copy-resources \u0026lt;ctf-dir\u0026gt; \u0026lt;new-ctf-dir-or-oci-repo-url\u0026gt;\rNote that this archive can become huge if there an many external images involved!\nCICD Integration Configure rarely changing variables in a static file and generate dynamic variables during the build from the environment. See the Static and Dynamic Variable Substitution section above.\n","date":"2023-03-13","id":30,"permalink":"/docs/tutorials/best-practices/","summary":"\u003cp\u003eThis chapter contains guidelines for common scenarios how to work with the Open Component Model, focusing on using CI/CD, build and publishing processes.\u003c/p\u003e","tags":[],"title":"Best Practices"},{"content":"Introduction Let\u0026rsquo;s illustrate a very simple \u0026ldquo;Hello World\u0026rdquo; example application and show how to leverage OCM to build an application component containing a Helm Chart and an OCI Image and deploy it to a local kind k8s cluster. The topics ocm localization and configuration are NOT part of this very simple example, but is covered in other tutorials.\nAs base we use the podinfo application from Stefan Prodan\u0026rsquo;s Github repo. All files can be found here.\nAt the end of the tutorial you will have created one OCM component for your business application podinfo. This component will be composed using the OCM guidelines and consist of multiple resources, alongside an OCI image and a Helm chart.\nFor building multiple components in one shot the \u0026ldquo;all-in-one\u0026rdquo; mechanism becomes handy.\nRequirements OCM command line tool kubectl git kind flux Building the Application Component Using OCM First we build an OCM component which contains Helm Charts in different kind of formats. This 101 guide explains all possible formats a HelmChart resource can have in OCM, but in reality you\u0026rsquo;ll just pick the one most appropriate to you.\nPrepare Helm Charts We are leveraging Kubernetes deployments which often use Helm charts. The OCM specification supports Helm charts as artifact type. For this simple example, we will re-use existing open source community Helm charts.\nThe OCM CLI supports referencing Helm charts stored in an OCI registry or Helm chart repositories, as well as local archives or folders. The preferred option is to store Helm charts in an OCI registry or Helm repository, as this allows for easy sharing and versioning of the Helm charts.\nHelm charts can be embedded in the component archive in four different ways:\nreferenced in OCI registry referenced in Helm repository as local *.tgz file as local folder containing a Helm Chart file To demonstrate No. 3. and 4. we need a Helm chart on our local machine. For the sake of the this simplified guide, we download and unpack an already existing open source Helm chart for podinfo. In a real world application, this would be your own Helm chart. You will most likely store your own Helm charts within a git repository and leverage a CI/CD pipeline to build *.tgz Helm chart files in order to push them to your OCI registry or Helm repository.\nDownloading Helm charts can easily be achieved using the Helm CLI:\nhelm repo add \u0026lt;repo-name\u0026gt; \u0026lt;helm-chart-repo-url\u0026gt; helm pull --destination \u0026lt;target-dir\u0026gt; \u0026lt;repo-name/chart-name\u0026gt;\rFor the podinfo example:\nhelm repo add podinfo https://stefanprodan.github.io/podinfo helm pull --destination . podinfo/podinfo\rThe Helm chart is then stored in the current working directory as podinfo-6.7.0.tgz and can be referenced as path from there in the component-constructor.yaml file (see below).\nUnpack podinfo-6.7.0.tgz to simulate the process as if this helm chart is our own and not downloaded from a public repository:\ntar -xzf podinfo-6.7.0.tgz\rInput Specification The corresponding input file for building our component version (component-constructor.yaml) looks like:\n# specify a schema to validate the configuration and get auto-completion in your editor # yaml-language-server: $schema=https://ocm.software/schemas/configuration-schema.yaml components: # podinfo component - name: ${COMPONENT_NAME_PREFIX}/podinfo labels: - name: \u0026#34;org.opencontainers.image.source\u0026#34; value: \u0026#34;https://github.com/stb1337/ocm-hello-world-v1\u0026#34; version: ${PODINFO_VERSION} provider: name: ${PROVIDER} resources: # Helm chart in OCI registry - name: helm-chart-external-oci type: helmChart version: ${PODINFO_VERSION} access: type: ociArtifact imageReference: ghcr.io/stefanprodan/charts/podinfo:${PODINFO_VERSION} # Helm Chart in Helm repository - name: helm-chart-external-helm-repo type: helmChart version: ${PODINFO_VERSION} access: type: helm helmChart: podinfo:${PODINFO_CHART_VERSION} helmRepository: https://stefanprodan.github.io/podinfo # Helm chart as local tgz file - name: helm-chart-local-tgz type: helmChart input: type: helm path: podinfo-${PODINFO_CHART_VERSION}.tgz # Helm chart as local folder - name: helm-chart-local-folder type: helmChart version: ${PODINFO_VERSION} input: type: dir path: ./podinfo/ # Image referenced in the Helm chart - name: image type: ociImage version: ${PODINFO_VERSION} access: type: ociArtifact repository: ocm/ocm.software/podinfo/image imageReference: ghcr.io/stefanprodan/podinfo:${PODINFO_VERSION}\rSome frequently changing parameters have been extracted as variables. The OCM CLI uses templating to fill them with values. The templating mechanism is described here. For this example we use the default template engine type subst.\nNote the differences between the various components:\nBuilding the Common Transport Archive (CTF) From the input file component-constructor.yaml the common transport archive can be created with the OCM CLI. We need to provide values for all variables, which can be passed in the command line or stored in a file. For many variables, having a values file is more convenient. The corresponding file settings.yaml may look like this:\nVERSION: 0.0.1 NAME: ocm-hello-world-v1 COMPONENT_NAME_PREFIX: ocm.software PROVIDER: stb1337 PODINFO_VERSION: 6.7.0 PODINFO_CHART_VERSION: 6.7.0\rCreate the transport archive with the following commands:\nocm add componentversions --create --file \u0026lt;ctf-target-dir\u0026gt; --settings settings.yaml component-constructor.yaml\rocm add componentversions --create --file ocm-hello-world --settings settings.yaml component-constructor.yaml processing component-constructor.yaml... processing document 1... processing index 1 found 1 component adding component ocm.software/podinfo:6.7.0... adding resource helmChart: \u0026#34;name\u0026#34;=\u0026#34;helm-chart-external-oci\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;6.7.0\u0026#34;... adding resource helmChart: \u0026#34;name\u0026#34;=\u0026#34;helm-chart-external-helm-repo\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;6.7.0\u0026#34;... adding resource helmChart: \u0026#34;name\u0026#34;=\u0026#34;helm-chart-local-tgz\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;\u0026lt;componentversion\u0026gt;\u0026#34;... adding resource helmChart: \u0026#34;name\u0026#34;=\u0026#34;helm-chart-local-folder\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;6.7.0\u0026#34;... adding resource ociImage: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;6.7.0\u0026#34;...\rYou can view all component versions in a transport archive using the command:\nocm get componentversion -o yaml \u0026lt;ctf-target-dir\u0026gt;\rocm get componentversion ./ocm-hello-world COMPONENT VERSION PROVIDER ocm.software/podinfo 6.7.0 stb1337\rYou can store the transport archive in an OCI registry (this step needs a proper configuration of credentials for the OCM CLI):\nocm transfer ctf -f \u0026lt;ctf-target-dir\u0026gt; \u0026lt;oci-repo-url\u0026gt;\rUsing the --copy-resources flag the OCM CLI will copy also copy all referenced resources to the OCI registry, making the resources part of the OCM component version, creating a self-contained component version.\nocm transfer ctf --copy-resources --enforce --overwrite ./ocm-hello-world OCIRegistry::ghcr.io/stb1337/ocm-hello-world-v1 transferring component \u0026#34;ocm.software/podinfo\u0026#34;... transferring version \u0026#34;ocm.software/podinfo:6.7.0\u0026#34;... ...resource 0 helm-chart-external-oci[helmChart](stefanprodan/charts/podinfo:6.7.0)... ...resource 1 helm-chart-external-helm-repo[helmChart]... ...resource 2 helm-chart-local-tgz[helmChart](ocm.software/podinfo/podinfo:6.7.0)... ...resource 3 helm-chart-local-folder[helmChart]... ...resource 4 image[ociImage](stefanprodan/podinfo:6.7.0)... ...adding component version...\rNote: Be careful with the -f or --overwrite flag. This will replace existing component versions in the OCI registry. During development it is useful being able to overwrite existing component versions until something is ready for release. For released versions you should never use this flag! Released component versions should be immutable and should never be overwritten. They serve as source of truth for what the release is made of and should never be changed.\nPackage Navigate to the overview of your OCI repository, which should list the following items:\nDeploying the OCM Software Artifact By this step we have created a transport archive containing all required parts (images and Helm charts) for installing the application. This archive is self-contained and can be transferred to an OCI registry with a single command from the OCM tooling. After pushing this archive to an OCI registry we have a shared location that can be used as a source of deployment without any external references. As an alternative, you can transport the archive using offline mechanisms (file transfer, USB-stick) and push it on a target location in an OCI registry.\nTo actually deploy the application we need to get access to the Helm charts contained in the archive. We can use the OCM CLI to retrieve their location. See the example below.\nSetup Local Kind Cluster Create local kind cluster on your local machine:\nkind create cluster -n ocm-hello-world Creating cluster \u0026#34;ocm-hello-world\u0026#34; ... ✓ Ensuring node image (kindest/node:v1.29.2) 🖼 ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹️ ✓ Installing CNI 🔌 ✓ Installing StorageClass 💾 Set kubectl context to \u0026#34;kind-ocm-hello-world\u0026#34; You can now use your cluster with: kubectl cluster-info --context kind-ocm-hello-world Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community 🙂\rMake sure that your current kubectl context is set to \u0026ldquo;kind-ocm-hello-world\u0026rdquo;:\nkind export kubeconfig -n ocm-hello-world Set kubectl context to \u0026#34;kind-ocm-hello-world\u0026#34; kubectl cluster-info Kubernetes control plane is running at https://127.0.0.1:52112 CoreDNS is running at https://127.0.0.1:52112/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use \u0026#39;kubectl cluster-info dump\u0026#39;.\rInstall Flux:\nflux install ✚ generating manifests ✔ manifests build completed ► installing components in flux-system namespace CustomResourceDefinition/alerts.notification.toolkit.fluxcd.io created CustomResourceDefinition/buckets.source.toolkit.fluxcd.io created CustomResourceDefinition/gitrepositories.source.toolkit.fluxcd.io created CustomResourceDefinition/helmcharts.source.toolkit.fluxcd.io created CustomResourceDefinition/helmreleases.helm.toolkit.fluxcd.io created CustomResourceDefinition/helmrepositories.source.toolkit.fluxcd.io created CustomResourceDefinition/kustomizations.kustomize.toolkit.fluxcd.io created CustomResourceDefinition/ocirepositories.source.toolkit.fluxcd.io created CustomResourceDefinition/providers.notification.toolkit.fluxcd.io created CustomResourceDefinition/receivers.notification.toolkit.fluxcd.io created Namespace/flux-system created ResourceQuota/flux-system/critical-pods-flux-system created ServiceAccount/flux-system/helm-controller created ServiceAccount/flux-system/kustomize-controller created ServiceAccount/flux-system/notification-controller created ServiceAccount/flux-system/source-controller created ClusterRole/crd-controller-flux-system created ClusterRole/flux-edit-flux-system created ClusterRole/flux-view-flux-system created ClusterRoleBinding/cluster-reconciler-flux-system created ClusterRoleBinding/crd-controller-flux-system created Service/flux-system/notification-controller created Service/flux-system/source-controller created Service/flux-system/webhook-receiver created Deployment/flux-system/helm-controller created Deployment/flux-system/kustomize-controller created Deployment/flux-system/notification-controller created Deployment/flux-system/source-controller created NetworkPolicy/flux-system/allow-egress created NetworkPolicy/flux-system/allow-scraping created NetworkPolicy/flux-system/allow-webhooks created ◎ verifying installation ✔ helm-controller: deployment ready ✔ kustomize-controller: deployment ready ✔ notification-controller: deployment ready ✔ source-controller: deployment ready ✔ install finished\rInstall OCM controller:\nocm controller install ► running pre-install check ► installing prerequisites ► installing cert-manager with version v1.13.2 ✔ successfully fetched install file ► applying to cluster... ► waiting for ocm deployment to be ready ✔ cert-manager successfully installed ► creating certificate for internal registry ✔ successfully installed prerequisites ► installing ocm-controller with version latest ► got latest version \u0026#34;v0.18.1\u0026#34; ✔ successfully fetched install file ► applying to cluster... ► waiting for ocm deployment to be ready ✔ ocm-controller successfully installed\rInspect Component Descriptor Let\u0026rsquo;s assume that we have pushed the transport archive to an OCI registry. We need the identity of the component version and the location of the component-descriptors in the OCI registry:\nComponentVersion: name: ocm.software/podinfo version: 6.7.0\nURL of OCI registry: ghcr.io/stb1337/ocm-hello-world-v1\nIt is convenient to put this into an environment variable:\nexport OCM_REPO=ghcr.io/stb1337/ocm-hello-world-v1\rGetting the component version 6.7.0 of the application with the OCM CLI:\nocm get componentversion --repo OCIRegistry::${OCM_REPO} ocm.software/podinfo:6.7.0 -o yaml\r--- component: componentReferences: [] creationTime: \u0026#34;2024-03-21T15:55:18Z\u0026#34; labels: - name: org.opencontainers.image.source value: https://github.com/stb1337/ocm-hello-world-v1 name: ocm.software/podinfo provider: stb1337 repositoryContexts: - baseUrl: ghcr.io componentNameMapping: urlPath subPath: stb1337/ocm-hello-world-v1 type: OCIRegistry resources: - access: localReference: sha256:cf9318c4944f733f8ce925ca0b818cdae638dce4107a13c3395984bb86306c4b mediaType: application/vnd.cncf.helm.chart.content.v1.tar+gzip type: localBlob digest: hashAlgorithm: SHA-256 normalisationAlgorithm: genericBlobDigest/v1 value: cf9318c4944f733f8ce925ca0b818cdae638dce4107a13c3395984bb86306c4b name: helm-chart-external relation: external type: helmChart version: 6.7.0 - access: imageReference: ghcr.io/stb1337/ocm-hello-world-v1/ocm.software/podinfo/podinfo:6.7.0 type: ociArtifact digest: hashAlgorithm: SHA-256 normalisationAlgorithm: ociArtifactDigest/v1 value: fa473086ce82810801785ec4ab70763fa81fcd971082035906a1695b9014c019 name: helm-chart-local-tgz relation: local type: helmChart version: 6.7.0 - access: localReference: sha256:8ff0604bfaebe6791ac4285c38a9f02771452497530367eeae49f1cf8594ca4c mediaType: application/x-tar type: localBlob digest: hashAlgorithm: SHA-256 normalisationAlgorithm: genericBlobDigest/v1 value: 8ff0604bfaebe6791ac4285c38a9f02771452497530367eeae49f1cf8594ca4c name: helm-chart-local-folder relation: local type: helmChart version: 6.7.0 - access: localReference: sha256:4a05cbc915a171301efdaad863d7d1bb0bc9193730767eca9385c49361956863 mediaType: application/x-tgz type: localBlob digest: hashAlgorithm: SHA-256 normalisationAlgorithm: genericBlobDigest/v1 value: 4a05cbc915a171301efdaad863d7d1bb0bc9193730767eca9385c49361956863 name: manifests relation: local type: dir version: 6.7.0 - access: imageReference: ghcr.io/stb1337/ocm-hello-world-v1/stefanprodan/podinfo:6.7.0 type: ociArtifact digest: hashAlgorithm: SHA-256 normalisationAlgorithm: ociArtifactDigest/v1 value: c04843c796025fbaa2574344994cb2461041b5e1d6b7a0de76b2b9fa46318e08 name: image relation: external type: ociImage version: 6.7.0 sources: [] version: 6.7.0 meta: schemaVersion: v2\rWith this we can drill down to the installable Helm charts and the container images:\nocm get resource --repo OCIRegistry::${OCM_REPO} ocm.software/podinfo:6.7.0 -o wide NAME VERSION IDENTITY TYPE RELATION ACCESSTYPE ACCESSSPEC helm-chart-external 6.7.0 helmChart external localBlob {\u0026#34;localReference\u0026#34;:\u0026#34;sha256:cf9318c4944f733f8ce925ca0b818cdae638dce4107a13c3395984bb86306c4b\u0026#34;,\u0026#34;mediaType\u0026#34;:\u0026#34;application/vnd.cncf.helm.chart.content.v1.tar+gzip\u0026#34;} helm-chart-local-folder 6.7.0 helmChart local localBlob {\u0026#34;localReference\u0026#34;:\u0026#34;sha256:8ff0604bfaebe6791ac4285c38a9f02771452497530367eeae49f1cf8594ca4c\u0026#34;,\u0026#34;mediaType\u0026#34;:\u0026#34;application/x-tar\u0026#34;} helm-chart-local-tgz 6.7.0 helmChart local ociArtifact {\u0026#34;imageReference\u0026#34;:\u0026#34;ghcr.io/stb1337/ocm-hello-world-v1/ocm.software/podinfo/podinfo:6.7.0\u0026#34;} image 6.7.0 ociImage external ociArtifact {\u0026#34;imageReference\u0026#34;:\u0026#34;ghcr.io/stb1337/ocm-hello-world-v1/stefanprodan/podinfo:6.7.0\u0026#34;}\rApply Kubernetes Manifest Create file k8s-component-version/01-pod-info-kind.yaml with the following content:\n#k8s-component-version/01-pod-info-kind.yaml apiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion metadata: name: ocm-hello-world-podinfo namespace: ocm-system spec: component: ocm.software/podinfo interval: 10s repository: url: ghcr.io/stb1337/ocm-hello-world-v1 secretRef: name: ghcr-pull-secret version: semver: \u0026#34;6.7.0\u0026#34; --- apiVersion: delivery.ocm.software/v1alpha1 kind: Resource metadata: name: ocm-hello-world-podinfo-helm-chart-external namespace: ocm-system spec: interval: 10s sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion name: ocm-hello-world-podinfo namespace: ocm-system resourceRef: name: helm-chart-external-helm-repo version: \u0026#34;6.7.0\u0026#34; --- apiVersion: delivery.ocm.software/v1alpha1 kind: FluxDeployer metadata: name: ocm-hello-world-podinfo-helm-chart-external namespace: ocm-system spec: interval: 10s sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: Resource name: ocm-hello-world-podinfo-helm-chart-external helmReleaseTemplate: values: replicaCount: 3 image: repository: ghcr.io/stb1337/ocm-hello-world-v1/stefanprodan/podinfo ui: color: \u0026#34;#8F00FF\u0026#34; message: \u0026#34;Hello from remote referenced Helm Chart\u0026#34; serviceAccount: enabled: true name: \u0026#34;sa-podinfo-ghcr-io-1\u0026#34; imagePullSecrets: - name: pull-secret interval: 10s releaseName: \u0026#34;podinfo-helm-chart-external\u0026#34; targetNamespace: default --- apiVersion: delivery.ocm.software/v1alpha1 kind: Resource metadata: name: ocm-hello-world-podinfo-helm-chart-local-tgz namespace: ocm-system spec: interval: 10s sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion name: ocm-hello-world-podinfo namespace: ocm-system resourceRef: name: helm-chart-local-tgz version: \u0026#34;6.7.0\u0026#34; --- apiVersion: delivery.ocm.software/v1alpha1 kind: FluxDeployer metadata: name: ocm-hello-world-podinfo-helm-chart-local-tgz namespace: ocm-system spec: interval: 10s sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: Resource name: ocm-hello-world-podinfo-helm-chart-local-tgz helmReleaseTemplate: values: replicaCount: 2 image: repository: ghcr.io/stb1337/ocm-hello-world-v1/stefanprodan/podinfo ui: color: \u0026#34;#FFC0CB\u0026#34; message: \u0026#34;Hello from local .tar file Helm Chart\u0026#34; serviceAccount: enabled: true name: \u0026#34;sa-podinfo-ghcr-io-2\u0026#34; imagePullSecrets: - name: pull-secret interval: 10s releaseName: \u0026#34;podinfo-helm-chart-local-tgz\u0026#34; targetNamespace: default --- apiVersion: delivery.ocm.software/v1alpha1 kind: Resource metadata: name: ocm-hello-world-podinfo-image namespace: ocm-system spec: interval: 10s sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion name: ocm-hello-world-podinfo namespace: ocm-system resourceRef: name: image version: \u0026#34;6.7.0\u0026#34;\rCreate two Kubernetes secrets in order for OCM and Kubernetes to pull from your private OCI registry:\nexport GITHUB_USER=.. \u0026amp;\u0026amp; export GITHUB_TOKEN=ghp_.... \u0026amp;\u0026amp; export GITHUB_USER_EMAIL=steffen.... kubectl create secret docker-registry pull-secret -n default \\ --docker-server=ghcr.io \\ --docker-username=$GITHUB_USER \\ --docker-password=$GITHUB_TOKEN \\ --docker-email=$GITHUB_USER_EMAIL kubectl create secret generic ghcr-pull-secret -n ocm-system \\ --from-literal=username=$GITHUB_USER \\ --from-literal=password=$GITHUB_TOKEN\rApply the manifest to your local kind cluster:\nk apply -f k8s-component-version/01-pod-info-kind.yaml componentversion.delivery.ocm.software/ocm-hello-world-podinfo created resource.delivery.ocm.software/ocm-hello-world-podinfo-helm-chart-external created fluxdeployer.delivery.ocm.software/ocm-hello-world-podinfo-helm-chart-external created resource.delivery.ocm.software/ocm-hello-world-podinfo-helm-chart-local-tgz created fluxdeployer.delivery.ocm.software/ocm-hello-world-podinfo-helm-chart-local-tgz created resource.delivery.ocm.software/ocm-hello-world-podinfo-image created\rkubectl port-forward service/podinfo-helm-chart-external -n default 9898:9898 Forwarding from 127.0.0.1:9898 -\u0026gt; 9898 Forwarding from [::1]:9898 -\u0026gt; 9898 Handling connection for 9898\rkubectl port-forward service/podinfo-helm-chart-local-tgz -n default 9898:9898 Forwarding from 127.0.0.1:9898 -\u0026gt; 9898 Forwarding from [::1]:9898 -\u0026gt; 9898 Handling connection for 9898\r","date":"2024-03-19","id":31,"permalink":"/docs/tutorials/build-deploy-infrastructure-via-helm-charts-with-ocm/","summary":"\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eLet\u0026rsquo;s illustrate a very simple \u0026ldquo;Hello World\u0026rdquo; example application and show how to leverage OCM to build an application component containing a Helm Chart and an OCI Image and deploy it to a local \u003ccode\u003ekind\u003c/code\u003e k8s cluster.\nThe topics \u003ccode\u003eocm\u003c/code\u003e \u003ca href=\"/docs/tutorials/structuring-and-deploying-software-products-with-ocm/#localization\"\u003e\u003ccode\u003elocalization\u003c/code\u003e\u003c/a\u003e and \u003ca href=\"/docs/tutorials/structuring-and-deploying-software-products-with-ocm/#configuration\"\u003e\u003ccode\u003econfiguration\u003c/code\u003e\u003c/a\u003e are NOT part of this very simple example, but is covered in other tutorials.\u003c/p\u003e","tags":[],"title":"Build \u0026 Deploy Infrastructure via Helm Charts with OCM"},{"content":"Introduction In this specification software products are comprised of logical units called components. A component version consists of a set of technical artifacts (e.g., Docker images, Helm charts, binaries, configuration data, etc.). Such artifacts are called resources in this specification. Resources are usually built from something, e.g., code in a git repo. Those are named sources in this specification.\nOCM introduces a Component Descriptor for every component version that describes the resources, sources, and other component versions belonging to a particular component version and how to access them.\nUsually, however, real-life applications are composed of multiple components. For example, an application might consist of a frontend, a backend, a database, and a web server. During the software development process new component versions are created and third-party components might be consumed from a public registry and updated from time to time.\nNot all component version combinations of frontend, backend, database, etc. are compatible and form a valid product version. In order to define reasonable version combinations for the software product, we could use another feature of the Component Descriptor, called a Component Reference (or reference in short), which allows the aggregation of component versions.\nFor each component and each version in use, there is a Component Descriptor. For the entire application, we introduce a new component that describes the overall software product referencing all components. This describes the entire application.\nA particular version of this application is again described by a Component Descriptor, which contains references to the Component Descriptors of its components in their version in use. You are not restricted to this approach. It is, e.g., possible to create multi-level hierarchies or you could just maintain a list of component version combinations which build a valid product release.\nIn a nutshell, OCM provides a simple approach to specify what belongs to a product version. Starting with the Component Descriptor for a product version and following the component references, you could collect all artifacts belonging to this product version.\nPrerequisites We assume that you have already read the guides in the Getting Started section, as this guide discusses a more complex scenario using plain Localizations and Configurations without the use of Unpacker.\nConstructing the Component We are going to use podinfo in microservices mode. This enables us to deploy several components and configure them individually.\npodinfo has three services which we are going to model using individual component descriptors:\nbackend frontend cache (redis) We will use the following example application to demonstrate a multi-component structure using podinfo: Podinfo Component.\nThis repository contains the following items:\nComponent File The following component file describes four components: three components that represent the podinfo microservices and one aggregate component that brings together the podinfo components using references. We refer to the aggregate component as the product component.\n# specify a schema to validate the configuration and get auto-completion in your editor # yaml-language-server: $schema=https://ocm.software/schemas/configuration-schema.yaml components: # -- product component - name: ocm.software/podinfo version: 1.0.2 labels: - name: ocm.software/labels/podinfo/purpose value: - kind: test type: manual provider: name: open-component-model componentReferences: - name: backend componentName: ocm.software/podinfo/backend version: 1.0.0 - name: frontend componentName: ocm.software/podinfo/frontend version: 1.0.0 - name: redis componentName: ocm.software/redis version: 1.0.0 sources: - access: commit: ac0afafcf4aa333546634cba631f0090a0a4cbe3 ref: refs/heads/main repoUrl: https://github.com/open-component-model/podinfo type: github name: github_com_open_component_model_podinfo type: git version: 1.0.0 # -- backend component - name: ocm.software/podinfo/backend version: 1.0.0 provider: name: open-component-model labels: - name: ocm.software/labels/podinfo/service value: backend resources: - name: config type: configdata.ocm.software input: type: file mediaType: application/yaml path: backend/config.yaml compress: true - name: image relation: external type: ociImage version: 6.2.0 access: type: ociArtifact imageReference: ghcr.io/stefanprodan/podinfo:6.2.0 - name: manifests type: kustomize.ocm.fluxcd.io input: type: dir path: backend/manifests compress: true sources: - access: commit: 9d294e85d8d3fe7803d1eccbf009619078d30cb9 ref: refs/heads/main repoUrl: https://github.com/open-component-model/podinfo type: github name: github_com_open_component_model_podinfo type: git version: 1.0.0 # -- frontend component - name: ocm.software/podinfo/frontend version: 1.0.0 provider: name: open-component-model labels: - name: ocm.software/labels/podinfo/service value: frontend resources: - name: config type: configdata.ocm.software input: type: file mediaType: application/yaml path: frontend/config.yaml compress: true - name: image relation: external type: ociImage version: 6.2.0 access: type: ociArtifact imageReference: ghcr.io/stefanprodan/podinfo:6.2.0 - name: manifests type: kustomize.ocm.fluxcd.io input: type: dir path: frontend/manifests compress: true sources: - access: commit: 9d294e85d8d3fe7803d1eccbf009619078d30cb9 ref: refs/heads/main repoUrl: https://github.com/open-component-model/podinfo type: github name: github_com_open_component_model_podinfo type: git version: 1.0.0 # -- redis component - name: ocm.software/redis version: 1.0.0 provider: name: open-component-model labels: - name: ocm.software/labels/podinfo/service value: redis resources: - name: config type: configdata.ocm.software input: type: file mediaType: application/yaml path: redis/config.yaml compress: true - name: image relation: external type: ociImage version: 6.0.1 access: type: ociArtifact imageReference: redis:6.0.1 - name: manifests type: kustomize.ocm.fluxcd.io input: type: dir path: redis/manifests compress: true sources: - access: commit: 9d294e85d8d3fe7803d1eccbf009619078d30cb9 ref: refs/heads/main repoUrl: https://github.com/open-component-model/podinfo type: github name: github_com_open_component_model_podinfo type: git version: 1.0.0\rWith the components modeled we can start to build a component archive using the ocm cli:\nocm add componentversions --create --file component-archive component-constructor.yaml processing component-constructor.yaml... processing document 1... processing index 1 processing index 2 processing index 3 processing index 4 found 4 components adding component ocm.software/podinfo:1.0.2... adding reference ocm.software/podinfo/backend: \u0026#34;name\u0026#34;=\u0026#34;backend\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;1.0.0\u0026#34;... adding reference ocm.software/podinfo/frontend: \u0026#34;name\u0026#34;=\u0026#34;frontend\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;1.0.0\u0026#34;... adding reference ocm.software/redis: \u0026#34;name\u0026#34;=\u0026#34;redis\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;1.0.0\u0026#34;... adding component ocm.software/podinfo/backend:1.0.0... adding resource configdata.ocm.software: \u0026#34;name\u0026#34;=\u0026#34;config\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;\u0026lt;componentversion\u0026gt;\u0026#34;... adding resource ociImage: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;6.2.0\u0026#34;... adding resource kustomize.ocm.fluxcd.io: \u0026#34;name\u0026#34;=\u0026#34;manifests\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;\u0026lt;componentversion\u0026gt;\u0026#34;... adding component ocm.software/podinfo/frontend:1.0.0... adding resource configdata.ocm.software: \u0026#34;name\u0026#34;=\u0026#34;config\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;\u0026lt;componentversion\u0026gt;\u0026#34;... adding resource ociImage: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;6.2.0\u0026#34;... adding resource kustomize.ocm.fluxcd.io: \u0026#34;name\u0026#34;=\u0026#34;manifests\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;\u0026lt;componentversion\u0026gt;\u0026#34;... adding component ocm.software/redis:1.0.0... adding resource configdata.ocm.software: \u0026#34;name\u0026#34;=\u0026#34;config\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;\u0026lt;componentversion\u0026gt;\u0026#34;... adding resource ociImage: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;6.0.1\u0026#34;... adding resource kustomize.ocm.fluxcd.io: \u0026#34;name\u0026#34;=\u0026#34;manifests\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;\u0026lt;componentversion\u0026gt;\u0026#34;...\rThis will create a folder called component-archive. The structure of that should look something like this:\ntree . . ├── artifact-index.json └── blobs ├── sha256.03ac3a7611e118d08fcf70e9b7be263c4a7082066f9763f71d8901d7fa2afc9d ├── sha256.118b6e8282ee1d335b1638a76a20022b6acc319177dbbce3089700da835afb6a ├── sha256.12073781e4fba95f19f046c51c90f0c4e1338d47afe4795bf6fcca163ae46eb8 ├── sha256.1f239399104ec0cc7680956eb60960d212b3368609feb83dac2c95040d24b480 ├── sha256.3c9c902ce013ca070a29634e4603c90063c96df632ef2c8e6b4447aaeb70b67e ├── sha256.3dc6209959eb782fa6f5f44892f66e9657276735bfb40407bd00ddca30d0a9d1 ├── sha256.654debd65dbadbcee73e55b675980865ddf22acffcec166c59a5e48a213e4dd5 ├── sha256.699ea8628e39256048cd1687c496fe64999a41f16f200ef5ce938ee9f19c37f0 ├── sha256.70a47378c043721e3099801dec02c44b1dd9cdef0ebf79c55784eb4666bdbc29 ├── sha256.773b28fb63f1195ff73e328744639ddc1c574d58c1e723d6e386fcd66b45bd9c ├── sha256.893be914eebd8230ef848ea82b3433c6201152f5d9925e7b5b8d68e0cec7133e ├── sha256.92991cf391167c928f3afe6891001f3dd325b64ce800cf34fad4c038141fc57f ├── sha256.98ca4d46130f5c09a704b3d8ee9af94de3c0ac73d7e990df53e64606c418fea8 ├── sha256.a779270c2fea310835d3125de90e089e423c9730a98f1acdda328470d21fced0 ├── sha256.a7dd532f80e8417ed33cf0c97328582847017895fc5146e499bdf4c94a9d17b5 ├── sha256.cae4365f264251c616210707aa4765bd95f23fd22f98abc68bae9f58d6e4506d ├── sha256.ee79c92bbcce9e7a98f07c6577fd56dd45cf6f7c2d3115216ee249f42119030e └── sha256.f6a82a23220752c232e5f66ce46f0be28b27a5af19474072c77dac6d1feb0c16 2 directories, 19 files\rThese blobs contain the resources we described when modelling our podinfo application. If we cat a random blob we get something like this:\ncat sha256.3c9c902ce013ca070a29634e4603c90063c96df632ef2c8e6b4447aaeb70b67e {\u0026#34;componentDescriptorLayer\u0026#34;:{\u0026#34;mediaType\u0026#34;:\u0026#34;application/vnd.ocm.software.component-descriptor.v2+yaml+tar\u0026#34;,\u0026#34;digest\u0026#34;:\u0026#34;sha256:699ea8628e39256048cd1687c496fe64999a41f16f200ef5ce938ee9f19c37f0\u0026#34;,\u0026#34;size\u0026#34;:2560}}%\rNext, we transfer this component to a location of your choice. Here \u0026lt;your-location\u0026gt; for me was ghcr.io/skarlso/demo-component.\nocm transfer component ./component-archive \u0026lt;your-location\u0026gt; transferring version \u0026#34;ocm.software/podinfo:1.0.2\u0026#34;... ...adding component version... transferring version \u0026#34;ocm.software/podinfo/backend:1.0.0\u0026#34;... ...resource 0... ...resource 2... ...adding component version... transferring version \u0026#34;ocm.software/podinfo/frontend:1.0.0\u0026#34;... ...resource 0... ...resource 2... ...adding component version... transferring version \u0026#34;ocm.software/redis:1.0.0\u0026#34;... ...resource 0... ...resource 2... ...adding component version... 4 versions transferred\rWith the transfer completed, we now have a component version that we can use and deploy throughout this example.\nPodinfo Components Backend The backend files contain the following relevant data:\nmanifests configmap.yaml\ncontains configuration options such as PODINFO_UI_COLOR deploy.yaml\nthe deployment configuration. Note that this deployment yaml contains an attribute image that will be configured using the config.yaml explained below.\nspec: containers: - name: backend image: not-an-image\rkustomization.yaml makes sure only the relevant files are applied\nservice.yaml to expose the service endpoint and make discoverable\nconfig.yaml contains the configuration and localization rules which will be applied to the deployment file. Localization will use an image resource to replace the above value for the atribute image with the correct one Configuration will use the config information to configure some default values for those values such as color and message. Frontend Frontend contains the same file structure as backend. The only differences are the deployed services.\nCache The cache contains the same resources as backend. The only differences are the values of those deployments.\nConstructing the Kubernetes Objects ComponentVersion We start by creating an image pull secret since the component that we just transferred was placed in a private OCI registry. The pull secret will be used by the OCM client or OCM controller to access this package in ghcr. To create the secret, run:\nkubectl create secret docker-registry pull-secret -n ocm-system \\ --docker-server=ghcr.io \\ --docker-username=$GITHUB_USER \\ --docker-password=$GITHUB_TOKEN \\ --docker-email=$GITHUB_EMAIL\rNow we create a ComponentVersion custom resource that will trigger a reconcile of the podinfo component.\napiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion metadata: name: podinfocomponent-version namespace: ocm-system spec: component: ocm.software/podinfo interval: 10m0s repository: url: \u0026lt;your-location\u0026gt; # this is where you transferred the component to secretRef: name: pull-secret version: semver: 1.0.2\rThis will reconcile the ComponentDescriptor for the specific version, making the component metadata available for other Kubernetes resources to consume. If everything was successful, we can inspect the created component version:\nkubectl describe componentversion -n ocm-system podinfocomponent-version\rapiVersion: delivery.ocm.software/v3alpha1 kind: ComponentVersion metadata: name: podinfocomponent-version namespace: ocm-system spec: component: ocm.software/podinfo interval: 10m0s repository: url: \u0026lt;your-location\u0026gt; serviceAccountName: admin-account version: semver: 1.0.2 status: componentDescriptor: componentDescriptorRef: name: ocm.software-podinfo-1.0.2-2456627037531301773 namespace: ocm-system name: ocm.software/podinfo references: - componentDescriptorRef: name: ocm.software-podinfo-backend-1.0.0-3945706267509967991 namespace: ocm-system name: backend version: 1.0.0 - componentDescriptorRef: name: ocm.software-podinfo-frontend-1.0.8-11612684200430752646 namespace: ocm-system name: frontend version: 1.0.8 - componentDescriptorRef: name: ocm.software-redis-1.0.0-6199010409340612397 namespace: ocm-system name: redis version: 1.0.0 version: 1.0.2 conditions: - lastTransitionTime: \u0026#34;2023-06-21T10:59:22Z\u0026#34; message: \u0026#39;Applied version: \u0026#39; observedGeneration: 1 reason: Succeeded status: \u0026#34;True\u0026#34; type: Ready observedGeneration: 1 reconciledVersion: 1.0.2\rThe important bits here are the references. These are all the components that the top component contains. These references are used to fetch and identify component dependencies. This component will also contain which version was last reconciled.\nComponentDescriptor We can also examine the component descriptors using the following command:\nkubectl get componentdescriptors\rapiVersion: delivery.ocm.software/v1alpha1 kind: ComponentDescriptor metadata: name: ocm.software-podinfo-backend-1.0.0-3945706267509967991 namespace: ocm-system spec: resources: - access: globalAccess: digest: sha256:4a9fd7d9d861aff437746c170b199d15539044405f1b822e316ef49ac5f99db8 mediaType: application/yaml ref: ghcr.io/skarlso/podify/component-descriptors/ocm.software/podinfo/backend size: 354 type: ociBlob localReference: sha256:4a9fd7d9d861aff437746c170b199d15539044405f1b822e316ef49ac5f99db8 mediaType: application/yaml type: localBlob name: config relation: local type: configdata.ocm.software version: 1.0.0 - access: imageReference: ghcr.io/stefanprodan/podinfo:6.2.0 type: ociArtifact name: image relation: external type: ociImage version: 6.2.0 - access: globalAccess: digest: sha256:c61bc74d0b5ecfcca20b447c10d97d07a3cec649e1fc57a25f08fc93fcf42fde mediaType: application/x-tgz ref: ghcr.io/skarlso/podify/component-descriptors/ocm.software/podinfo/backend size: 963 type: ociBlob localReference: sha256:c61bc74d0b5ecfcca20b447c10d97d07a3cec649e1fc57a25f08fc93fcf42fde mediaType: application/x-tgz type: localBlob name: manifests relation: local type: kustomize.ocm.fluxcd.io version: 1.0.0 version: 1.0.0\rThis descriptor specifies the location of the component\u0026rsquo;s resource based on the current context (globalAccess). We can use this information to retrieve the resource from a storage layer that is accessible within our current environment.\nLocalizations, Configurations and FluxDeployer Here, we will create the localization and configuration YAML by hand and then apply it to the cluster.\nWe have to create three of each of these components. Localization, Configuration and a FluxDeployer. One for each component version.\nBackend Both, localization and configuration, are in the ConfigData object. So we point to that. The controller will use the image resource to localize the backend image. This is how it\u0026rsquo;s defined in the localizations rule:\nlocalization: - resource: name: image file: deploy.yaml image: spec.template.spec.containers[0].image\rNow, let\u0026rsquo;s construct these objects:\n# Localization apiVersion: delivery.ocm.software/v1alpha1 kind: Localization metadata: name: backend-localization namespace: ocm-system spec: configRef: kind: ComponentVersion name: podinfocomponent-version namespace: ocm-system resourceRef: name: config referencePath: - name: backend version: 1.0.0 interval: 10m0s sourceRef: kind: ComponentVersion name: podinfocomponent-version namespace: ocm-system resourceRef: name: manifests referencePath: - name: backend version: 1.0.0\r# Configuration apiVersion: delivery.ocm.software/v1alpha1 kind: Configuration metadata: name: backend-configuration namespace: ocm-system spec: configRef: kind: ComponentVersion name: podinfocomponent-version namespace: ocm-system resourceRef: name: config referencePath: - name: backend version: 1.0.0 interval: 10m0s sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: Localization name: backend-localization namespace: ocm-system\rFinally, let\u0026rsquo;s add the FluxDeployer too, which makes sure that this component is deployed to the target location.\n# FluxDeployer apiVersion: delivery.ocm.software/v1alpha1 kind: FluxDeployer metadata: name: backend-kustomization namespace: ocm-system spec: kustomizationTemplate: prune: true targetNamespace: default sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: Configuration name: backend-configuration namespace: ocm-system\rAnd that\u0026rsquo;s it.\nThe components can be found under podinfo/backend/components.\nTo apply them, simply run the following command from the podinfo root:\nkubectl apply -f backend/components\rFrontend We do the same for the Frontend component:\napiVersion: delivery.ocm.software/v1alpha1 kind: Localization metadata: name: frontend-localization namespace: ocm-system spec: configRef: kind: ComponentVersion name: podinfocomponent-version namespace: ocm-system resourceRef: name: config referencePath: - name: frontend version: 1.0.0 interval: 10m0s sourceRef: kind: ComponentVersion name: podinfocomponent-version namespace: ocm-system resourceRef: name: manifests referencePath: - name: frontend version: 1.0.0\rapiVersion: delivery.ocm.software/v1alpha1 kind: Configuration metadata: name: frontend-configuration namespace: ocm-system spec: configRef: kind: ComponentVersion name: podinfocomponent-version namespace: ocm-system resourceRef: name: config referencePath: - name: frontend version: 1.0.0 interval: 10m0s sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: Localization name: frontend-localization namespace: ocm-system\rapiVersion: delivery.ocm.software/v1alpha1 kind: FluxDeployer metadata: name: frontend-kustomization namespace: ocm-system spec: kustomizationTemplate: prune: true targetNamespace: default sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: Configuration name: frontend-configuration namespace: ocm-system\rTo apply them, simply run this command from the podinfo root:\nkubectl apply -f frontend/components\rRedis Redis is exactly the same as the above two. Just with different names and pointing to the redis resource. Try creating these yourself to see if you understood the structure. If you get stuck, you can always take a peek under podinfo/redis/components.\nTo apply them, simply run this command from the podinfo root:\nkubectl apply -f redis/components\rUnderstanding the moving parts How does the whole flow work?\nThe ocm-controller creates ComponentDescriptor resources for each referenced component version. Those component descriptors contain all the resources that those versions have, such as manifest files, configuration files, deployment files, etc.\nIt will use this dependency graph to lookup resource data in the right component version.\nLet\u0026rsquo;s take a look at each object in the cluster next.\nkubectl get localizations -A NAMESPACE NAME READY SOURCE VERSION CONFIG VERSION AGE ocm-system backend-localization True 1.0.16 1.0.16 5m ocm-system cache-localization True 1.0.16 1.0.16 5m ocm-system frontend-localization True 1.0.16 1.0.16 5m ➜ k get configuration -A NAMESPACE NAME READY SOURCE VERSION CONFIG VERSION AGE ocm-system backend-configuration True 1.0.16 1.0.16 4m25s ocm-system cache-configuration True 1.0.16 1.0.16 4m25s ocm-system frontend-configuration True 1.0.16 1.0.16 4m25s ➜ k get fluxdeployer -A NAMESPACE NAME READY AGE ocm-system backend-kustomization True 3m55s ocm-system cache-kustomization True 3m45s ocm-system frontend-kustomization True 3m35s ➜ k get snapshot -A NAMESPACE NAME READY STATUS ocm-system backend-configuration-v5l2oag True Snapshot with name \u0026#39;backend-configuration-v5l2oag\u0026#39; is ready ocm-system backend-localization-uvnrzql True Snapshot with name \u0026#39;backend-localization-uvnrzql\u0026#39; is ready ocm-system cache-configuration-kcjiqzy True Snapshot with name \u0026#39;cache-configuration-kcjiqzy\u0026#39; is ready ocm-system cache-localization-u2h3old True Snapshot with name \u0026#39;cache-localization-u2h3old\u0026#39; is ready ocm-system frontend-configuration-ut3u6pm True Snapshot with name \u0026#39;frontend-configuration-ut3u6pm\u0026#39; is ready ocm-system frontend-localization-tgqfwwk True Snapshot with name \u0026#39;frontend-localization-tgqfwwk\u0026#39; is ready ➜ k get componentversion -A NAMESPACE NAME READY VERSION AGE STATUS ocm-system podinfocomponent-version True 1.0.16 9m8s Applied version: 1.0.16 ➜ k get componentdescriptor -A NAMESPACE NAME AGE ocm-system ocm.software-podinfo-1.0.16-2456627037531301773 9m27s ocm-system ocm.software-podinfo-backend-1.0.0-3945706267509967991 9m25s ocm-system ocm.software-podinfo-frontend-1.0.8-11612684200430752646 9m23s ocm-system ocm.software-redis-1.0.0-6199010409340612397 9m21s\rAll of the components should have their Localization, Configuration, and FluxDeployer.\nLocalization A localization should look something like this:\napiVersion: delivery.ocm.software/v1alpha1 kind: Localization metadata: name: backend-localization namespace: ocm-system spec: configRef: kind: ComponentVersion name: podinfocomponent-version namespace: ocm-system resourceRef: name: config referencePath: - name: backend version: 1.0.0 interval: 10m0s sourceRef: kind: ComponentVersion name: podinfocomponent-version namespace: ocm-system resourceRef: name: manifests referencePath: - name: backend version: 1.0.0 status: conditions: - lastTransitionTime: \u0026#34;2023-06-20T12:28:47Z\u0026#34; message: Reconciliation success observedGeneration: 1 reason: Succeeded status: \u0026#34;True\u0026#34; type: Ready latestConfigVersion: 1.0.16 latestSourceVersion: 1.0.16 observedGeneration: 1 snapshotName: backend-localization-uvnrzql\rThe important fields are configRef and sourceRef. The configRef points to the resource that contains our localization rules:\nlocalization: - resource: name: image file: deploy.yaml image: spec.template.spec.containers[0].image\rThis will change the image in our deployment in the file deploy.yaml to the image resource we have in the podinfo example.\nThe sourceRef is pointing to the component version to fetch the manifests from.\nConfiguration Let\u0026rsquo;s take a look at the configuration object next (very similar to localization):\napiVersion: delivery.ocm.software/v1alpha1 kind: Configuration metadata: name: backend-configuration namespace: ocm-system spec: configRef: kind: ComponentVersion name: podinfocomponent-version namespace: ocm-system resourceRef: name: config referencePath: - name: backend version: 1.0.0 interval: 10m0s sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: Localization name: backend-localization namespace: ocm-system status: conditions: - lastTransitionTime: \u0026#34;2023-06-20T12:28:47Z\u0026#34; message: Reconciliation success observedGeneration: 2 reason: Succeeded status: \u0026#34;True\u0026#34; type: Ready latestConfigVersion: 1.0.16 latestSourceVersion: 1.0.16 observedGeneration: 2 snapshotName: backend-configuration-v5l2oag\rThe important details here are the configRef field and the sourceRef field. The configRef field defines where the configuration values are located at:\nconfiguration: defaults: message: \u0026#34;Welcome to the backend service\u0026#34; schema: type: object additionalProperties: false properties: replicas: type: string message: type: string rules: - value: (( message )) file: configmap.yaml path: data.PODINFO_UI_MESSAGE\rNote. This configuration has a source that is pointing at the Localization resource that we created. This is important because the configuration needs to work on the localized entities. Once reconciled, it will create a Snapshot. That snapshot contains the input resources that have been transformed using the supplied configuration rules.\nFluxDeployer Next, comes the FluxDeployer. The FluxDeployer will point to the last Snapshot in the chain of transformations which is the Configuration. It looks something like this:\napiVersion: delivery.ocm.software/v1alpha1 kind: FluxDeployer metadata: name: backend-kustomization namespace: ocm-system spec: kustomizationTemplate: prune: true targetNamespace: default sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: Configuration name: backend-configuration namespace: ocm-system status: conditions: - lastTransitionTime: \u0026#34;2023-06-20T12:29:23Z\u0026#34; message: FluxDeployer \u0026#39;backend-kustomization\u0026#39; is ready observedGeneration: 2 reason: Succeeded status: \u0026#34;True\u0026#34; type: Ready kustomization: ocm-system/backend-kustomization observedGeneration: 2\rThis creates a Kustomization object. The Kustomization object is used to reconcile the created component into the target namespace. We have three of these for each component for which we would like to apply the results.\nTroubleshooting Once all objects are applied, we should see podinfo deployed in the default namespace:\nkubectl get pods NAME READY STATUS RESTARTS AGE backend-6dd8f5fbf8-xfdmq 1/1 Running 0 54m frontend-56ff5b9864-h8fgh 1/1 Running 0 54m redis-7475dd84c4-hzp2b 1/1 Running 0 54m\rNote: The pod count might vary based on the default settings in the configuration data.\nIf the deployment isn\u0026rsquo;t appearing, there are several places to check for errors:\nFlux:\nMaybe Flux didn\u0026rsquo;t kick in yet. Try to force a reconcile by running:\nflux reconcile source git flux-system -n flux-system\rEvents:\nKubernetes Events could hold some extra information. List the most recent ones with:\nkubectl events -A\rLogs:\nSometimes, you can see errors in the source-controller failing to get the right resources. Or kustomize-controller doesn\u0026rsquo;t understand something. We\u0026rsquo;ll go into getting logs in Controller Logs section.\nObject Status:\nMany of the objects have a status with the most recent error on them. The relevant objects in this case are the FluxDeployer and the OCIRepository objects. Make sure they have successful statuses.\nkubectl get ocirepositories -A NAMESPACE NAME URL READY STATUS AGE ocm-system backend-kustomization oci://registry.ocm-system.svc.cluster.local:5000/sha-3644589785534619751 True stored artifact for digest \u0026#39;2234@sha256:12100267c60d3eb5acfc564b56eb94288e33fa875c7f2191ec0a662594283ad0\u0026#39; 5m17s ocm-system cache-kustomization oci://registry.ocm-system.svc.cluster.local:5000/sha-3644589785534619751 True stored artifact for digest \u0026#39;2393@sha256:f12873dff8d8f91b5d917711f0d7d20ebc85dbfc1652bf01c8b50dc198d7f32d\u0026#39; 4m57s ocm-system frontend-kustomization oci://registry.ocm-system.svc.cluster.local:5000/sha-3644589785534619751 True stored artifact for digest \u0026#39;2539@sha256:1a37fdfbf0f109498b813bbd784a81c8b1a818d4770a49a319cc2562621dcf40\u0026#39; 4m47s\rkubectl get fluxdeployer -A NAMESPACE NAME READY AGE ocm-system backend-kustomization True 8m13s ocm-system cache-kustomization True 7m53s ocm-system frontend-kustomization True 7m43s\rController Logs There are several controllers to sift through in case something doesn\u0026rsquo;t happen the way it should.\nocm-controller To get the ocm-controller logs run:\nkubectl logs `k get pods --template \u0026#39;{{range .items}}{{.metadata.name}}{{end}}\u0026#39; --selector=app=ocm-controller -n ocm-system` -n ocm-system\rIf everything goes according to plan, there should be no errors in the logs.\nFlux controllers Flux has a couple of controllers we can check if things don\u0026rsquo;t start up (especially if we don\u0026rsquo;t see any resources in the cluster, or if we don\u0026rsquo;t see the podinfo deployment being started).\nsource-controller: This controller will contain information about the latest applied code from the repository. If there is an error here it means that the source, or rather our modifications, weren\u0026rsquo;t applied.\nkustomize-controller: This controller will contain information about reconciled objects. A Kustomization source is usually either a GitRepository or an OCIRepository. In this case, the source will be an OCIRepositoy. That repository is pointing to the in-cluster OCI repository. A snapshot creates these entries and that\u0026rsquo;s where it loads the data from.\nThe helm-controller and notification-controller aren\u0026rsquo;t relevant.\nObject statuses ComponentVersion:\nThe ComponentVersion object contains information about what components have been reconciled. We talked about that earlier at Component Version. The Status section contains any errors that could have occurred when reconciling information.\nComponentDescriptor:\nThe ComponentDescriptor holds information about each component and their resources. Read more at ComponentDescriptors.\nIf the resources section is empty in the status, there is something wrong reconciling the individual items.\nLocalization:\nThe status section contains information about the snapshot that this object created. The snapshot is used to point to the right repository in the internal OCI cache. It also contains the last applied version. The conditions section will contain any errors while reconciling the resource.\nConfiguration:\nThe status section contains information about the snapshot that this object created. The snapshot is used to point to the right repository in the internal OCI cache. It also contains the last applied version. The conditions section will contain any errors while reconciling the resource.\nSnapshots:\nThe Snapshot, most of the time, is transparent to the user. The sources are Snapshot providers. That means any object that can produce a Snapshot can be a source to a Localization, Configuration or a Resource object. A Source is a thing from which to fetch resource data such as Manifests, rules, Markdown files, descriptors, etc.\nWe can also use Snapshots to look for errors in reconciling resource data. A Snapshot\u0026rsquo;s status contains information.\napiVersion: delivery.ocm.software/v1alpha1 kind: Snapshot metadata: creationTimestamp: \u0026#34;2023-06-21T10:49:35Z\u0026#34; finalizers: - finalizers.snapshot.ocm.software generation: 2 name: backend-configuration-2agwrnt namespace: ocm-system ownerReferences: - apiVersion: delivery.ocm.software/v1alpha1 kind: Configuration name: backend-configuration uid: dfb8dede-5234-406c-8077-fc5e382ec8fd resourceVersion: \u0026#34;4591\u0026#34; uid: b8c0b983-9c27-4597-92b1-fe19aad2abca spec: digest: sha256:1f5f6173f3180c2fda00dd1267ca190628a2e8b5fa707232cebc9059f7845e29 identity: component-name: ocm.software-podinfo-1.0.16-2456627037531301773 component-version: 1.0.16 resource-name: config resource-version: 1.0.0 tag: \u0026#34;1533\u0026#34; status: conditions: - lastTransitionTime: \u0026#34;2023-06-21T10:49:35Z\u0026#34; message: Snapshot with name \u0026#39;backend-configuration-2agwrnt\u0026#39; is ready observedGeneration: 2 reason: Succeeded status: \u0026#34;True\u0026#34; type: Ready digest: sha256:1f5f6173f3180c2fda00dd1267ca190628a2e8b5fa707232cebc9059f7845e29 observedGeneration: 2 repositoryURL: http://registry.ocm-system.svc.cluster.local:5000/sha-2819236492453137798 tag: \u0026#34;1533\u0026#34;\rThis Snapshot contains a lot of information about what has been replicated in the internal registry. We can use crane to fetch it and check the generated content.\nFluxDeployer:\nFluxDeployer is used to apply the generated objects to a cluster. In the background, it\u0026rsquo;s leveraging Flux\u0026rsquo;s Kustomization object. This object\u0026rsquo;s status will contain any errors that could occur during applying generated content, like invalid data, invalid CRDs, invalid yaml, no access to the cluster, permission issues, etc. Each component has a FluxDeployer applying some kind of component data to the cluster such as, Deployments, ConfigMaps, ReplicaSets, etc.\nOCIRepository:\nThere should be one OCIRepository resource per component. The OCIRepository is created by the FluxDeployer. OCIRepository will contain any errors regarding the content of the internal registry.\nKustomization:\nKustomization objects are also created by the FluxDeployer. These objects will contain applying errors.\nCommon issues tar header invalid:\nUsually, this means that the content we are trying to sync from the OCIRepository is not a tar file. This can happen if the resource wasn\u0026rsquo;t a Directory or if the fetching of the data somehow failed.\nTo verify, we can use crane to check the content.\nTo run crane, first, expose the internal registry using port-forward like this:\nkubectl port-forward service/registry -n ocm-system 5000:5000\rThen, verify that the connection is working by running a catalog command:\ncrane catalog http://127.0.0.1:5000\rThis should list something like this:\ncrane catalog 127.0.0.1:5000 sha-10883673987458280187 sha-16809550111814969680 sha-1990151198423805921 sha-2092408510764941850 sha-2819236492453137798 sha-6687852683187729914 sha-9139473762086563639\rTo identify which of these contains our failed resource, check the failing OCIRepository object.\nkubectl get ocirepository -A NAMESPACE NAME URL READY STATUS AGE ocm-system podinfo oci://registry.ocm-system.svc.cluster.local:5000/sha-10883673987458280187 False failed to extract layer contents from artifact: tar error: archive/tar: invalid tar header 21h\rNow we know which of these contains the invalid resource. We can further identify which blob it is by either, describing the relevant snapshot, or by running a manifest command with crane.\ncrane manifest 127.0.0.1:5000/sha-10883673987458280187:1.0.0|jq { \u0026#34;schemaVersion\u0026#34;: 2, \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.docker.distribution.manifest.v2+json\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.docker.container.image.v1+json\u0026#34;, \u0026#34;size\u0026#34;: 233, \u0026#34;digest\u0026#34;: \u0026#34;sha256:6e3b5d3bfbd044c33125f20d83c2b82cd1c348b58422df4859678bc0e6c8aed5\u0026#34; }, \u0026#34;layers\u0026#34;: [ { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.layer.v1.tar+gzip\u0026#34;, \u0026#34;size\u0026#34;: 1044, \u0026#34;digest\u0026#34;: \u0026#34;sha256:eae39564a446ee92d1fec8728ef0c27077995d01bbedc25e0688a1cbb7582adc\u0026#34; } ] }\rOne of these will not be what they seem. To fetch a blob run:\ncrane blob 127.0.0.1:5000/sha-10883673987458280187@sha256:eae39564a446ee92d1fec8728ef0c27077995d01bbedc25e0688a1cbb7582adc \u0026gt; temp.tar\rAnd then check what that temp.tar looks like. If the content is human-readable, there is a problem. If you encounter the component descriptor file, you can skip that. That\u0026rsquo;s not what you are looking for.\nConclusion We saw how to deploy a complex, multi-service architecture using the podinfo application.\n","date":"0001-01-01","id":32,"permalink":"/docs/tutorials/structuring-and-deploying-software-products-with-ocm/","summary":"\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eIn this specification software products are comprised of logical units called \u003ca href=\"https://github.com/open-component-model/ocm-spec/blob/main/doc/01-model/02-elements-toplevel.md#components-and-component-versions\"\u003e\u003cstrong\u003ecomponents\u003c/strong\u003e\u003c/a\u003e. A component version consists of a set of technical \u003ca href=\"https://github.com/open-component-model/ocm-spec/blob/main/doc/04-extensions/01-artifact-types/README.md\"\u003eartifacts\u003c/a\u003e (e.g., Docker images, Helm charts, binaries, configuration data, etc.). Such artifacts are called \u003cstrong\u003eresources\u003c/strong\u003e in this specification. Resources are usually built from something, e.g., code in a git repo. Those are named \u003cstrong\u003esources\u003c/strong\u003e in this specification.\u003c/p\u003e","tags":[],"title":"Structuring and Deploying Software Products with OCM"},{"content":"Introduction This tutorial will demonstrate how to get started deploying applications using the Open Component Model \u0026amp; Flux.\nIn this guide, we will leverage Flux and the ocm-controller to deploy an existing component to a Kubernetes cluster. Specifically, we will deploy the phoban.io/podinfo component that contains the resources needed to launch the podinfo application.\nHere\u0026rsquo;s a diagram showing what we\u0026rsquo;ll be building:\nAs you can see, we\u0026rsquo;ll add some manifests to a git repository that will be deployed by Flux. These will, in turn, deploy a resource from an OCM repository, in this case, a Deployment of the podinfo microservice.\nIf you\u0026rsquo;d like to learn how to build a component, then check out our Getting Started guide.\nTable of Contents Introduction Table of Contents Requirements Environment Setup Deploy the OCM Controller Deploy the Component Wrapping Up Requirements OCM command line tool kubectl git gh kind flux Environment Setup First of all, let\u0026rsquo;s create a cluster using kind:\nkind create cluster\rWith the cluster created, we can now bootstrap Flux to automate the deployment of our component. Flux can create a repository and clone it to our local environment by running the following shell command:\nexport GITHUB_REPOSITORY=podinfo-flux-repo flux bootstrap github \\ --owner $GITHUB_USER \\ --repository $GITHUB_REPOSITORY \\ --path ./clusters/kind \\ --personal\rThis command will create a GitHub repository named podinfo-flux-repo, configure Flux to use it, and deploy the resources in the ./clusters/kind directory to our Kubernetes cluster.\nLet\u0026rsquo;s now clone the repository flux has created and put in place the manifests required to deploy components:\ngh repo clone $GITHUB_REPOSITORY \u0026amp;\u0026amp; cd $GITHUB_REPOSITORY\rWe\u0026rsquo;ll add a Kustomization to the ./clusters/kind directory in order to reconcile any resources found in the ./components directory:\ncat \u0026gt; ./clusters/kind/components_kustomization.yaml \u0026lt;\u0026lt;EOF apiVersion: kustomize.toolkit.fluxcd.io/v1beta2 kind: Kustomization metadata: name: components namespace: flux-system spec: interval: 1m0s prune: true targetNamespace: ocm-system sourceRef: kind: GitRepository name: flux-system path: ./components EOF\rCommit this file, push, and then ensure Flux has reconciled the resource:\ngit add ./clusters/kind/components_kustomization.yaml git commit -m \u0026#34;add components kustomization\u0026#34; git push # trigger an immediate reconciliation of our repo flux reconcile source git flux-system # view kustomizations and their status flux get kustomizations\rDeploy the OCM Controller We can use the OCM CLI to install the controller:\nocm controller install\rDeploy the Component Now that we have flux configured and the ocm-controller installed, we can started deploying components.\nWe told flux that our component manifests will live in ./components, so let\u0026rsquo;s create that directory:\nmkdir -p ./components\rTo make the component accessible within the cluster, create the following ComponentVersion:\ncat \u0026gt; ./components/component_version.yaml \u0026lt;\u0026lt;EOF apiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion metadata: name: podinfo namespace: ocm-system spec: interval: 1m0s component: phoban.io/podinfo version: semver: \u0026#34;\u0026gt;=v6.3.5\u0026#34; repository: url: ghcr.io/phoban01 EOF\rThen create a Resource to retrieve the deployment resource from the component:\ncat \u0026gt; ./components/resource.yaml \u0026lt;\u0026lt;EOF apiVersion: delivery.ocm.software/v1alpha1 kind: Resource metadata: name: podinfo-deployment namespace: ocm-system spec: interval: 1m0s sourceRef: kind: ComponentVersion name: podinfo resourceRef: name: deployment version: latest EOF\rFinally, create a FluxDeployer to deploy the Resource contents using Flux:\ncat \u0026gt; ./components/deployer.yaml \u0026lt;\u0026lt;EOF apiVersion: delivery.ocm.software/v1alpha1 kind: FluxDeployer metadata: name: podinfo namespace: ocm-system spec: sourceRef: kind: Resource name: podinfo-deployment kustomizationTemplate: interval: 1m0s path: ./ prune: true targetNamespace: default EOF\rAt this point we can commit these files, push to the remote repository, and tell flux to reconcile the changes:\ngit add ./components git commit -m \u0026#34;add ocm manifests\u0026#34; git push flux reconcile source git flux-system\rWithin a few moments we will see the deployment spinning up:\nkubectl get po -n default NAME READY STATUS RESTARTS AGE podinfo-84cb98c9b6-75rx5 1/1 Running 0 1m podinfo-84cb98c9b6-k4lk8 1/1 Running 0 1m\rWrapping Up That\u0026rsquo;s it! That\u0026rsquo;s how easy it is to get started using the Open Component Model and Flux.\nIf you want to know more about working with OCM and GitOps, check out these guides:\nAir-gapped GitOps with OCM \u0026amp; Flux GitOps Driven Configuration of OCM Applications ","date":"0001-01-01","id":33,"permalink":"/docs/tutorials/ocm-and-gitops/deploying-applications-with-ocm-gitops/","summary":"\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eThis tutorial will demonstrate how to get started deploying applications using the Open Component Model \u0026amp; Flux.\u003c/p\u003e\n\u003cp\u003eIn this guide, we will leverage Flux and the \u003ccode\u003eocm-controller\u003c/code\u003e to deploy an existing component to a Kubernetes cluster. Specifically, we will deploy the \u003ccode\u003ephoban.io/podinfo\u003c/code\u003e component that contains the resources needed to launch the \u003ca href=\"https://github.com/stefanprodan/podinfo\"\u003epodinfo\u003c/a\u003e application.\u003c/p\u003e","tags":[],"title":"Deploying Applications with OCM \u0026 GitOps"},{"content":"Introduction This guide is the final part of our series exploring OCM, the ocm-controller, and how to drive GitOps processes using OCM as the source of truth.\nCheck out the previous guides if you haven\u0026rsquo;t already:\nDeploy Applications with OCM \u0026amp; GitOps Air-gapped GitOps with OCM \u0026amp; Flux In this guide we will pick-up where we left off in the air-gapped example.\nWe have successfully transferred a component to our private environment and deployed it using the ocm-controller. However, the Kubernetes Deployment for podinfo is failing because it does not have permission to access our private container images.\nLet\u0026rsquo;s fix that.\nTable of Contents Introduction Table of Contents Requirements Component Content Recap GitOps \u0026amp; Configuration Verify Deployment Conclusion Requirements OCM command line tool kubectl git gh kind flux Component Content Recap We saw previously that the podinfo component contains three resources:\npodinfo container image kubernetes deployment manifest for podinfo configuration file read by the ocm-controller We can list these resources using the ocm CLI:\nocm get resources ghcr.io/phoban01//phoban.io/podinfo -c v6.3.5 NAME VERSION IDENTITY TYPE RELATION config 6.3.5 PlainText local deployment 6.3.5 Directory local image 6.3.5 ociImage external\rLet\u0026rsquo;s examine the config resource once again and this time focus on a section named configuration:\nocm download resource ghcr.io/phoban01//phoban.io/podinfo -c v6.3.5 config -O - apiVersion: config.ocm.software/v1alpha1 kind: ConfigData metadata: name: ocm-config configuration: defaults: serviceAccountName: default # this is the default value for our variable rules: - value: (( serviceAccountName )) # this variable file: deployment.yaml # will be inserted into this file path: spec.template.spec.serviceAccountName # at this path schema: # allows us to define constraints for configuration values type: object additionalProperties: false properties: serviceAccountName: type: string ...\rThe configuration section contains a set of rules, some default values, and a schema.\nThese can be used to provide configuration values, which will be inserted into our resources at runtime by the ocm-controller.\nIn the above resource we can see that there is a variable named serviceAccountName and a rule which specifies that this variable should be inserted into the path spec.template.spec.serviceAccountName in the deployment.yaml file.\nGitOps \u0026amp; Configuration Similar to how we Localized our deployment resource in the previous guide, we create another Custom Resource with the type Configuration in order to apply our configuration rules:\ncat \u0026gt; ./components/localization.yaml \u0026gt;\u0026gt;EOF apiVersion: delivery.ocm.software/v1alpha1 kind: Configuration metadata: name: podinfo-deployment namespace: ocm-system spec: interval: 1m sourceRef: kind: Localization name: podinfo-deployment # this is the podinfo deployment localization configRef: kind: ComponentVersion name: podinfo resourceRef: name: config # here we reference the configuration resource values: serviceAccountName: app-ops EOF\rYou can see that this time we have used the Localization resource as the input for the Configuration and have provided the configuration rules using the spec.configRef field. Finally, we specify our service account name in the spec.values.serviceAccountName field.\nOnce again we need to update the FluxDeployer so that it consumes the Configuration rather than the Localization:\napiVersion: delivery.ocm.software/v1alpha1 kind: FluxDeployer metadata: name: podinfo namespace: ocm-system spec: sourceRef: kind: Configuration name: podinfo-deployment kustomizationTemplate: interval: 1m0s path: ./ prune: true targetNamespace: default\rBefore we push these changes, we need to actually create the ServiceAccount and image-pull Secret in the target namespace.\nLet\u0026rsquo;s create the secret as we did previously (Note that in a real world scenario there are a number of ways to manage secrets when doing Gitops):\nkubectl create secret docker-registry -n default ghcr-cred \\ --docker-server=ghcr.io \\ --docker-username=$GITHUB_USER \\ --docker-password=$GITHUB_TOKEN\rNow let\u0026rsquo;s add the ServiceAccount:\ncat \u0026gt; ./clusters/kind/service_account.yaml \u0026lt;\u0026lt;EOF apiVersion: v1 kind: ServiceAccount metadata: name: app-ops namespace: default imagePullSecrets: - name: ghcr-cred\rFinally we are ready commit, push, and reconcile these changes:\ngit add ./components ./clusters git commit -m \u0026#34;move to air-gapped repository\u0026#34; git push flux reconcile source git flux-system\rVerify Deployment Flux should now be reconciling the Configured manifest with image references pointing to our private OCM repository and the correct ServiceAccount configured.\nWe can verify this using kubectl:\nkubectl get deployment -n default podinfo -oyaml | grep serviceAccountName | xargs serviceAccountName: app-ops\rkubectl get deployment -n default podinfo -oyaml | grep image | xargs image: ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5\rKubernetes can now retrieve the image and all pods should be happily running.\nConclusion We have shown how OCM and Flux can be combined to configure applications at runtime.\nGitOps driven configuration in tandem with the powerful Localization functionality provided by OCM offers tremendous flexibility, reliability, and scalability when deploying your applications to any kind of compute environment, be it public, private or edge.\n","date":"0001-01-01","id":34,"permalink":"/docs/tutorials/ocm-and-gitops/gitops-driven-configuration-of-ocm-applications/","summary":"\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eThis guide is the final part of our series exploring OCM, the \u003ccode\u003eocm-controller\u003c/code\u003e, and how to drive GitOps processes using OCM as the source of truth.\u003c/p\u003e","tags":[],"title":"GitOps Driven Configuration of OCM Applications"},{"content":" Overview Input Types binary dir docker dockermulti file helm ociImage spiff utf-8 Access Types gitHub helm npm ociArtifact s3 Overview The Open Component Model spec supports multiple methods how to add resources to a component version. There are two different ways to add content: Input Type and Access Type.\nAn Input type adds content by value, along with the component descriptor and stores it in the same target repository where the component is stored. After pushing the content to the target registry this always resolves to the attribute\nrelation: local\rin a component descriptor.\nAn Access Type just adds content by reference to an external location, e.g., an OCI registry. It is a kind of pointer in a component descriptor. It resolves to the attribute\nrelation: external\rin a component descriptor.\nThe following input types are supported:\nbinary dir docker dockermulti file helm ociImage spiff utf-8 Please use the latest ocm-cli to check available input types:\nocm add resources --help | grep \u0026#39; - Input type\u0026#39; | sort -f\rThe following list of access types is supported:\ngitHub localBlob ociArtifact ociBlob s3 Please use the latest ocm-cli to check available access types:\nocm ocm-accessmethods | grep \u0026#39; - Access type\u0026#39; | sort -f\rNot all access and input types can be combined in useful ways with all artifact types. But the OCM specification does not define any restrictions on possible combinations.\nThe following sections give an overview and typical usage examples for access and input types. It does not describe the full list of possible fields and their meaning. For a complete list of attributes, please see the command reference. The examples below are meant to be used in a component that looks like this:\n- name: github.com/open-component-model/megacomponent version: 0.1.0\rInput Types binary Allows to define resources with binary content being base64 encoded. Should only be used for smaller blobs.\nresources: - name: noticeencoded type : blob input: data: VGhpcyBpcyBzb21lIGJhc2U2NCBlbmNvZGVkIGRhdGEK mediaType: text/plain compress: false type: binary\rdir Defines a resource from content of a directory in the local file system. It is packed with tar and optionally compressed.\nresources: - name: megadir type : fileSystem input: type: dir path: ./logos\rdocker Takes an image from the local docker registry and adds it as a resource. Requires a running docker daemon.\nresources: - name: megaimage type : ociImage input: type: docker repository: images/mega path: megacomp:${VERSION}\rif VERSION is set to 0.1.0 the following image is imported:\ndocker image ls REPOSITORY TAG IMAGE ID CREATED SIZE megacomp 0.1.0 9aab9cbca56e 5 days ago 7.46MB\rThe target location of the image can be set with the repository field. Here the resulting image will be stored at \u0026lt;REPO_URL\u0026gt;/github.com/open-component-model/megacomponent/images/mega:1.10.\ndockermulti Takes multiple images from the local docker registry and adds them as single multi-arch image. Requires a running docker daemon. The images have to be built for different architectures/os and need a unique tag identifying them. As docker does not support multi-arch images at the time of writing this is a workaround.\nresources: - name: megaimagemulti type : ociImage input: type: dockermulti repository: images/megamulti variants: - megacomp:${VERSION}-linux-amd64 - megacomp:${VERSION}-linux-arm64\rif VERSION is set to 0.1.0 the following image is imported:\ndocker image ls REPOSITORY TAG IMAGE ID CREATED SIZE megacomp 0.1.0-linux-amd64 96659c4f7a35 5 days ago 7.05MB megacomp 0.1.0-linux-arm64 64f209acb814 5 days ago 7.46MB\rThe target location of the image can be set with the repository field. Here the resulting image will be stored at \u0026lt;REPO_URL\u0026gt;/github.com/open-component-model/megacomponent/images/megamulti:1.10.\nfile Imports a file from the local file system and adds it as a resource.\nresources: - name: mega-file type: blob input: type: file path: ./logos/logo-image.png\rhelm Imports a helm chart from the local file system and adds it as a resource.\nresources: - name: mega-chart type: helmChart input: type: helm path: ./megachart repository: charts/mega\rAfter transporting the corresponding component version to an OCI registry, the helm chart will be made available under charts/mega prefixed by the name of the component version. This auto-prefix can be disabled by using a leading slash /charts/mega. If the repository tag is omitted, the name of the helm chart from Chart.yaml will be used.\nIt is also possible to import a helm chart from a helm chart repository:\nresources: - name: mariadb-chart type: helmChart input: type: helm helmRepository: https://charts.bitnami.com/bitnami path: mariadb version: 12.2.7 repository: charts/mariadb\rHere the helm chart version 12.2.7 is copied from the path mariadb in helm chart repository https://charts.bitnami.com/bitnami. After transporting the corresponding component version to an OCI registry, the helm chart will be made available under charts/mariadb prefixed by the name of the component version. This auto-prefix can be disabled by using a leading slash /charts/mariadb. If the repository tag is omitted, the name of the helm chart from Chart.yaml will be used. There are additional optional fields caCert and caCertFile to specify a TLS certificate for the helm chart repository.\nociImage Takes an image that is located in an OCI registry and adds it as a resource.\nresources: - name: mega-image type: ociImage input: type: ociImage path: gcr.io/google_containers/echoserver:1.10 repository: images/echo\rThe target location of the image after transporting to an OCI registry can be set with the repository field. Here the resulting image will be prefixed with the name of the component version, e.g., github.com/open-component-model/megacomponent/images/echo:1.10. This auto-prefix can be disabled by using a leading slash /images/echo.\nspiff Processes a resource using the spiff templater and can provide values for variables.\nresources: - name: mega-package type: toiPackage input: type: spiff mediaType: application/vnd.toi.ocm.software.package.v1+yaml path: packagespec.yaml values: RELEASE_NAME: megacomp\rutf-8 Adds a resource from inline text.\nresources: - name: noticeplain type : blob input: text: \u0026#34;Here is some text\u0026#34; mediaType: text/plain compress: false type: utf8\rAccess Types gitHub Refers to a Git repository at a certain commit or tag.\nresources: - name: git-ocm type: blob version: ${VERSION} access: type: gitHub repoUrl: https://github.com/open-component-model/ocm commit: 42cc249aec77aa64984b2b91eb0f3b96dd63aacd\rhelm Refers to a helm chart located in a helm chart repository.\n- name: mariadb-chart type: helmChart version: ${VERSION} access: type: helm helmChart: mariadb:12.2.7 helmRepository: https://charts.bitnami.com/bitnami\rnpm Refers to an npm package located in a Javascript package registry.\n- name: prime-npm type: ocm/npmPackage version: ${VERSION} access: type: npm package: random-prime version: 4.0.0 registry: https://registry.npmjs.org\rociArtifact Refers to an image in an (external) OCI registry.\nresources: - name: echo-image version: \u0026#34;1.10\u0026#34; type: ociImage access: type: ociArtifact imageReference: gcr.io/google_containers/echoserver:1.10\rs3 Refers to an object in an AWS S3 store.\nresources: - name: gardenlinux-meta type: blob version: ${VERSION} access: type: s3 bucket: gardenlinux key: meta/singles/gcp-cloud-gardener-_prod-890.0-53b732\r","date":"0001-01-01","id":35,"permalink":"/docs/tutorials/input-and-access-types/","summary":"\u003cul\u003e\n\u003cli\u003e\u003ca href=\"#overview\"\u003eOverview\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"#input-types\"\u003eInput Types\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"#binary\"\u003ebinary\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#dir\"\u003edir\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#docker\"\u003edocker\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#dockermulti\"\u003edockermulti\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#file\"\u003efile\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#helm\"\u003ehelm\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#ociimage\"\u003eociImage\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#spiff\"\u003espiff\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#utf-8\"\u003eutf-8\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#access-types\"\u003eAccess Types\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"#github\"\u003egitHub\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#helm-1\"\u003ehelm\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#npm\"\u003enpm\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#ociartifact\"\u003eociArtifact\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#s3\"\u003es3\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"overview\"\u003eOverview\u003c/h2\u003e\n\u003cp\u003eThe Open Component Model spec supports multiple methods how to add resources to a component version. There are two different ways to add content: Input Type and Access Type.\u003c/p\u003e","tags":[],"title":"Input and Access Types"},{"content":"","date":"2023-11-07","id":36,"permalink":"/docs/examples/","summary":"","tags":[],"title":"Examples"},{"content":"The source code for the demo can be found at https://github.com/open-component-model/demo-secure-delivery. A video guide can be found here.\nFully guided walkthrough This walkthrough deploys a full end-to-end scenario demonstrating how OCM and Flux can be employed to continuously deploy applications in air-gapped environments.\nThe demo environment consists of Gitea, Tekton, Flux and the OCM controller.\nTo be able to show that provider and consumer are really disconnected, two distinct Gitea organizations are created:\nsoftware-provider software-consumer Software Provider The provider organization contains a repository which models the podinfo application. When a new release is created a Tekton pipeline will be triggered that builds the OCM component and pushes it to the software provider\u0026rsquo;s OCI registry.\nSoftware Consumer The software consumer organization models an air-gapped scenario where applications are deployed from a secure OCI registry rather than directly from an arbitrary public upstream source.\nThe software consumer organization contains a repository named ocm-applications. During the setup of the demo a PR is created which contains a set of Kubernetes manifests required to deploy the OCM component published by the software provider.\nOnce this pull request is merged the Flux machinery will deploy podinfo component. Capacitor can be used to understand the state of the cluster.\nWalkthrough Instructions are provided to guide you through the process of deploying the demo environment, cutting a release for \u0026ldquo;podinfo,\u0026rdquo; verifying the release automation, installing the component, viewing the Capacitor GitOps dashboard, accessing the deployed application, applying configuration changes, monitoring the application update, and cutting a new release with updated features.\n1. Setup demo environment To deploy the demo environment execute the following:\nmake run\nOnce the environment has been created, login to Gitea using the following credentials:\nusername: ocm-admin password: password\r2. Cut a release for podinfo Next navigate to: https://gitea.ocm.dev/software-provider/podinfo-component/releases and click \u0026ldquo;New Release\u0026rdquo;.\nEnter \u0026ldquo;v1.0.0\u0026rdquo; for both the tag name and release name, and then click \u0026ldquo;Publish Release\u0026rdquo;.\n3. Verify the release Once the release is published, navigate to https://ci.ocm.dev/#/namespaces/tekton-pipelines/pipelineruns and follow the progress of the release automation.\n4. Install the Component When the release pipeline has been completed we can install the component. Navigate to https://gitea.ocm.dev/software-consumer/ocm-applications/pulls/1 and merge the pull request.\n5. View the Capacitor Dashboard After certificates are created the Capacitor component and the dashboard will be accessible at https://capacitor.ocm.dev. Give it a minute to spin up\u0026hellip;\n5. View the application We can view the podinfo Helm release that\u0026rsquo;s been deployed in the default namespace: https://capacitor.ocm.dev/\nWe can also view the running application at https://podinfo.ocm.dev\n6. Apply configuration The application can be configured using the parameters exposed in values.yaml. Now that podinfo is deployed we can tweak a few parameters. Navigate to https://gitea.ocm.dev/software-consumer/ocm-applications/_edit/main/values.yaml\nand add the following:\npodinfo: replicas: 2 message: \u0026#34;Hello Open Component Model!\u0026#34; serviceAccountName: ocm-ops\r7. View the configured application The changes will soon be reconciled by Flux and visible at https://podinfo.ocm.dev. Note how the pod id changes now that we have 2 replicas of our application running.\n8. Cut a new release Let\u0026rsquo;s jump back to the provider repository and cut another release. This release will contain a new feature that changes the image displayed by the podinfo application. Follow the same process as before to create a release, bumping the version to v1.1.0.\n9. Verify the release Once the release is published, navigate to https://ci.ocm.dev/#/namespaces/tekton-pipelines/pipelineruns and follow the progress of the release automation.\n10. Monitor the application update Jump back to https://capacitor.ocm.dev to view the rollout of the new release.\n11. View the updated application Finally, navigate to https://podinfo.ocm.dev which now displays the OCM logo in place of the cuttlefish and the updated application version of 6.3.6\nConclusion By leveraging the capabilities of Gitea, Tekton, Flux, and the OCM controller, this demo showcases the seamless deployment of components and dependencies in a secure manner. The use of secure OCI registries and automated release pipelines ensures the integrity and reliability of the deployment process.\nUsers can easily set up the demo environment, cut releases, monitor release automation, view the Capacitor GitOps dashboard and observe the deployment and update of applications. We have presented a practical illustration of how OCM and Flux can be employed to facilitate the deployment and management of applications in air-gapped environments, offering a robust and efficient solution for secure software delivery.\nContributing Code contributions, feature requests, bug reports, and help requests are very welcome. Please refer to the Contributing Guide in the Community repository for more information on how to contribute to OCM.\nOCM follows the CNCF Code of Conduct.\nLicensing Copyright 2024-2025 SAP SE or an SAP affiliate company and Open Component Model contributors. Please see our LICENSE for copyright and license information. Detailed information including third-party components and their licensing/copyright information is available via the REUSE tool.\n","date":"2023-11-07","id":37,"permalink":"/docs/examples/secure-software-delivery-with-flux-and-ocm/","summary":"\u003cp\u003eThe source code for the demo can be found at \u003ca href=\"https://github.com/open-component-model/demo-secure-delivery\"\u003ehttps://github.com/open-component-model/demo-secure-delivery\u003c/a\u003e.\nA video guide can be found \u003ca href=\"https://share.vidyard.com/watch/NjNrZF2926RUTSUvkU4MdR\"\u003ehere\u003c/a\u003e.\u003c/p\u003e\n\u003ch2 id=\"fully-guided-walkthrough\"\u003eFully guided walkthrough\u003c/h2\u003e\n\u003cp\u003e\r\n\r\n\u003cimg\r\n src=\"/new_diagram_7403461049610658471_hu955974254496665239.webp\"\r\n width=\"3036\"\r\n height=\"1956\"\r\n decoding=\"async\"\r\n fetchpriority=\"auto\"\r\n loading=\"lazy\"\r\n alt=\"workflow\"id=\"h-rh-i-0\"\r\n/\u003e\u003c/p\u003e","tags":[],"title":"Secure software delivery with Flux and OCM"},{"content":"","date":"2020-10-06","id":38,"permalink":"/docs/roadmap/","summary":"","tags":[],"title":"Roadmap"},{"content":"You can checkout the Project Roadmap on GitHub which is based on issues and PRs from the OCM project repository.\n","date":"2020-10-06","id":39,"permalink":"/docs/roadmap/our-roadmap/","summary":"\u003cp\u003eYou can checkout the \u003ca href=\"https://github.com/orgs/open-component-model/projects/10/views/5\"\u003eProject Roadmap on GitHub\u003c/a\u003e which is based on issues and PRs from the \u003ca href=\"https://github.com/open-component-model/ocm-project\"\u003eOCM project repository\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003e\r\n\r\n\u003cimg\r\n src=\"/images/roadmap_Q2-2024_hu3456875650843085168.webp\"\r\n width=\"3335\"\r\n height=\"1386\"\r\n decoding=\"async\"\r\n fetchpriority=\"auto\"\r\n loading=\"lazy\"\r\n alt=\"roadmap\"id=\"h-rh-i-0\"\r\n/\u003e\u003c/p\u003e","tags":[],"title":"Our Roadmap"},{"content":"","date":"2020-10-06","id":40,"permalink":"/docs/support/","summary":"","tags":[],"title":"Support"},{"content":"We are here to help you with any questions you have about OCM. Here are a few ways to get support:\nMake sure you’ve read the basic documentation: OCM Overview Getting Started Check the Glossary of the OCM specification for definitions of terms. Ask a question in the OCM Slack Channel in the Kubernetes Workspace. Check and read existing issues in the OCM repositories, report a bug, or request a new feature. ","date":"2020-10-06","id":41,"permalink":"/docs/support/how-to-get-support/","summary":"\u003cp\u003eWe are here to help you with any questions you have about OCM. Here are a few ways to get support:\u003c/p\u003e","tags":[],"title":"How to get Support"},{"content":"GitHub You can stay updated with OCM\u0026rsquo;s latest advancements, join our active conversations, and delve into our enhancement proposals on each project\u0026rsquo;s GitHub issues page specifically for OCM.\nIf you\u0026rsquo;re just starting with OCM, we recommend beginning with the \u0026lsquo;good first issue\u0026rsquo; label in our repositories.\nReady to contribute directly to OCM? Whether adding code, writing tests, or assisting with our documentation, please adhere to the guidelines provided in the \u0026lsquo;contributing\u0026rsquo; documentation of the relevant OCM repository.\nSlack Join #open-component-model on Kubernetes Slack and talk to us and other community members.\nKubernetes Slack Membership\nIf you aren\u0026rsquo;t already a member on the Kubernetes Slack workspace, please request an invitation.\nOur team is passionate about delving into diverse deployment processes, exploring patterns, aiding in design, and troubleshooting issues. Who knows? Your inquiry might inspire the development of the next OCM feature!\nCommunity Meetings The OCM team holds regular community meetings to discuss new developments in the project and any topics of interest to the Open Component Model community. Please monitor the OCM slack channel for announcement notices.\nPlease consult our community documentation for more details about the Open Component Model Community.\n","date":"2022-08-12","id":42,"permalink":"/docs/support/community/","summary":"\u003ch2 id=\"github\"\u003eGitHub\u003c/h2\u003e\n\u003cp\u003eYou can stay updated with OCM\u0026rsquo;s latest advancements, join our active conversations, and delve into our enhancement proposals on each project\u0026rsquo;s GitHub issues page specifically for OCM.\u003c/p\u003e","tags":[],"title":"The OCM Community"},{"content":"","date":"2020-10-06","id":43,"permalink":"/docs/contribution/","summary":"","tags":[],"title":"Contribute"},{"content":"Welcome to the OCM community!\nThank you for taking the time to contribute to OCM.\nDCO Support Channels Ways to Contribute Find an Issue Local Development Submitting Pull Requests Licensing and Copyright information on file level Pull Request Checklist Pull Request Process Style Guidelines Release Process Guideline for AI-generated code contributions to SAP Open Source Software Projects DCO By contributing to this project you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution.\nWe require all commits to be signed. By signing off with your signature, you certify that you wrote the patch or otherwise have the right to contribute the material by the rules of the DCO:\nSigned-off-by: Jane Doe \u0026lt;jane.doe@example.com\u0026gt;\nIf your user.name and user.email are configured in your Git config, you can sign your commit automatically with git commit -s.\nSupport Channels Before opening a new issue or submitting a Pull Request, make sure to search through the docs, open and closed issues, open and merged Pull Requests, and the Discussions board to check whether your question has been raised or answered already.\nPlease open an issue in any of the repositories in the open-component-model organisation if you wish to request a new feature or report a bug.\nIf you wish to propose or discuss a more involved feature or change to any of the OCM projects, you could start a new thread in the ocm Discussion Board. For example, this could be helpful if you wish to vet an idea before writing a feature request. It is a space to discuss in public with maintainers, contributors, users, and other interested parties. After reaching some form of consensus, the proposed changes can go through the pull request process where implementation details are reviewed, approved, or rejected by maintainers.\nWays to Contribute We welcome all types of contributions, including:\nNew features Bug reports/fixes Reviewing/updating documentation Refactoring Backfilling tests Joining discussions Web design Release management Reviews Board discussions You may find it helpful to start a new thread in the ocm Discussion Board for questions, help requests, feature requests, or any other type of discussion about OCM. A maintainer will reach out to you as soon as possible.\nFind an Issue Take a look at the OCM issues to find out more about what is currently in the works and what is planned. If you find something that you are interested in picking up, please leave a comment and wait for a maintainer to give you the green light to claim it and start working on it.\nIf you would like to contribute but are unsure about where to start, feel free to let the maintainers know through the ocm Discussion Board and someone will reach out to you.\nLocal Development Each project has its own setup for local development.\nSubmitting Pull Requests Ready to contribute? Read and follow the sections below to get your contribution to the finish line.\nLicensing and Copyright information on file level In general all files of the project are created under Apache 2.0 license. The project uses the REUSE process and tooling that supports maintaining licensing information centrally in a .reuse/dep5 config file on repository level. This means that in general there SHOULD NOT be any license and copyright specifiy SPDX headers on file level. Only in cases where content is copied from sources that use a different license and already use headers like\n// SPDX-FileCopyrightText: Copyright 2010 The Go Authors. All rights reserved. // // SPDX-License-Identifier: BSD-3-Clause\rthe headers of the source file should be kept and eventually aggregated with the Apache 2.0 license. Please check the REUSE FAQ for details.\nSuch files should be explicitly added as deviating from the .reuse/dep5 config file using the Files-Excluded field. Excluding the file /pkg/foo.go and pkg/bar.go from the general rule to add the Apache 2.0 license to all files, would look like this:\nFiles: ** Copyright: 2022 SAP SE or an SAP affiliate company and Open Component Model contributors License: Apache-2.0 Files-Excluded: /pkg/foo.go pkg/bar.go Pull Request Checklist Fork the repository, push your changes to a branch on your fork, then open a PR from that branch to the source repository\u0026rsquo;s main branch. Add as much information as possible in your PR description about what changed, why, as well as steps to test these changes. Sign your commits. Ensure that the branch is up to date with main. Write a neat title that is ready to be added to future release notes. Update documentation (either in the docs or README) that cover your changes. Add unit tests and integration tests to cover your changes. Ensure that the linter and all unit and integration tests are successful. Bonus: Backfill tests/documentation to make the world a better place. Pull Request Process Create PR. Please refer to the Pull Request Checklist before marking a PR as ready to be reviewed. Triage. A maintainer will triage the Pull Request by adding the appropriate label for the issue. Assign reviews. A maintainer will be assigned to review the changes in the Pull Request. Review/Discussion. One or more maintainer will review the Pull Request. Checkout the style guidelines section for some things reviewers will look for. Address comments by answering questions or changing code. Approve/Merge. A review should be approved by at least two other maintainers. If the PR was opened by a community contributor, they should wait for a maintainer to merge the Pull Request. Style Guidelines For Go standards, it is recommended to take a look at the Go Code Review Comments and the Formatting and style section of Peter Bourgon\u0026rsquo;s Go: Best Practices for Production Environments.\nRelease Process Follow these steps to do a release:\nCreate a PR with the following: Update the version. For example, in the ocm repository, this is located in pkg/version/release.go. Add the release notes. Use the draft release notes generated by the release-drafter GitHub Action that can be found in github.com/open-component-model/\u0026lt;repository\u0026gt;/releases. Add these to the repository\u0026rsquo;s docs/releasenotes/v0.x.0.md for a given minor version. For example, for v0.2.0 (or a release candidate for this version), create docs/releasenotes/v0.2.0.md. Request reviews for the PR \u0026amp; merge it once it is approved. Navigate to the Release GitHub Action. Tick the box if this is a Release Candidate, otherwise leave it blank, and click to start the action. This will run the tests and linter, check that the release notes are present for this version, create a branch and a tag, and finally trigger the release using goreleaser. Guideline for AI-generated code contributions to SAP Open Source Software Projects As artificial intelligence evolves, AI-generated code is becoming valuable for many software projects, including open-source initiatives. While we recognize the potential benefits of incorporating AI-generated content into our open-source projects there a certain requirements that need to be reflected and adhered to when making contributions.\nWhen using AI-generated code contributions in OSS Projects, their usage needs to align with Open-Source Software values and legal requirements. We have established these essential guidelines to help contributors navigate the complexities of using AI tools while maintaining compliance with open-source licenses and the broader Open-Source Definition.\nAI-generated code or content can be contributed to SAP Open Source Software projects if the following conditions are met:\nCompliance with AI Tool Terms and Conditions: Contributors must ensure that the AI tool\u0026rsquo;s terms and conditions do not impose any restrictions on the tool\u0026rsquo;s output that conflict with the project\u0026rsquo;s open-source license or intellectual property policies. This includes ensuring that the AI-generated content adheres to the Open Source Definition.\nFiltering Similar Suggestions: Contributors must use features provided by AI tools to suppress responses that are similar to third-party materials or flag similarities. We only accept contributions from AI tools with such filtering options. If the AI tool flags any similarities, contributors must review and ensure compliance with the licensing terms of such materials before including them in the project.\nManagement of Third-Party Materials: If the AI tool\u0026rsquo;s output includes pre-existing copyrighted materials, including open-source code authored or owned by third parties, contributors must verify that they have the necessary permissions from the original owners. This typically involves ensuring that there is an open-source license or public domain declaration that is compatible with the project\u0026rsquo;s licensing policies. Contributors must also provide appropriate notice and attribution for these third-party materials, along with relevant information about the applicable license terms.\nEmployer Policies Compliance: If AI-generated content is contributed in the context of employment, contributors must also adhere to their employer’s policies. This ensures that all contributions are made with proper authorization and respect for relevant corporate guidelines.\n","date":"0001-01-01","id":44,"permalink":"/docs/contribution/contributing-guideline/","summary":"\u003cp\u003eWelcome to the OCM community!\u003c/p\u003e\n\u003cp\u003eThank you for taking the time to contribute to OCM.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"#dco\"\u003eDCO\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#support-channels\"\u003eSupport Channels\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#ways-to-contribute\"\u003eWays to Contribute\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"#find-an-issue\"\u003eFind an Issue\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#local-development\"\u003eLocal Development\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#submitting-pull-requests\"\u003eSubmitting Pull Requests\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"#licensing-and-copyright-information-on-file-level\"\u003eLicensing and Copyright information on file level\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#pull-request-checklist\"\u003ePull Request Checklist\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#pull-request-process\"\u003ePull Request Process\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#style-guidelines\"\u003eStyle Guidelines\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#release-process\"\u003eRelease Process\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#guideline-for-ai-generated-code-contributions-to-sap-open-source-software-projects\"\u003eGuideline for AI-generated code contributions to SAP Open Source Software Projects\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"dco\"\u003eDCO\u003c/h2\u003e\n\u003cp\u003eBy contributing to this project you agree to the Developer Certificate of Origin (\u003ca href=\"https://raw.githubusercontent.com/open-component-model/.github/main/DCO\"\u003eDCO\u003c/a\u003e). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution.\u003c/p\u003e","tags":[],"title":"Contributing Guideline"},{"content":"Report a Vulnerability Please do not report security vulnerabilities through public GitHub issues!\nInstead, please report them via the SAP Trust Center at https://www.sap.com/about/trust-center/security/incident-management.html.\nIf you prefer to submit via email, please send an email to secure@sap.com. If possible, encrypt your message with the SAP PGP key; please download it from the SAP Trust Center.\nPlease include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:\nThe repository name or URL Type of issue (buffer overflow, SQL injection, cross-site scripting, etc.) Full paths of the source file(s) related to the manifestation of the issue The location of the affected source code (tag/branch/commit or direct URL) Any particular configuration required to reproduce the issue Step-by-step instructions to reproduce the issue Proof-of-concept or exploit code (if possible) Impact of the issue, including how an attacker might exploit the issue This information will help us triage your report more quickly\nFurther details may be found here: https://github.com/open-component-model/ocm/security/policy\nAdvisories Advisories will be published directly on the affected repositories, e.g:\nhttps://github.com/open-component-model/ocm/security/advisories https://github.com/open-component-model/ocm-controller/security/advisories https://github.com/open-component-model/vscode-ocm-tools/security/advisories ","date":"2022-08-12","id":45,"permalink":"/docs/contribution/security-guideline/","summary":"\u003ch2 id=\"report-a-vulnerability\"\u003eReport a Vulnerability\u003c/h2\u003e\n\u003cdiv class=\"callout callout-note d-flex flex-row mt-4 mb-4 pt-4 pe-4 pb-2 ps-3\"\u003e\r\n \r\n \u003cdiv class=\"callout-content\"\u003e\r\n \r\n \u003cdiv class=\"callout-body\"\u003e\r\n \u003cp\u003ePlease do not report security vulnerabilities through public GitHub issues!\u003c/p\u003e","tags":[],"title":"Security Guideline"},{"content":"This tutorial shows you how to bootstrap MPAS to a Kubernetes cluster and deploy a simple application.\nPrerequisites A Kubernetes cluster A GitHub access token with repo scope kubectl Objectives Bootstrap MPAS to a Kubernetes cluster Deploy a simple application Install the MPAS CLI The MPAS CLI is the primary tool for interacting with MPAS. It can be used to bootstrap MPAS to a Kubernetes cluster.\nTo install the MPAS CLI using brew:\nbrew install open-component-model/tap/mpas\rFor other installation methods, see the installation guide.\nBootstrap MPAS Export your GitHub access token The MPAS CLI uses your GitHub access token to authenticate with GitHub. To create a GitHub access token, see the GitHub documentation. In addition to that we need to export your GitHub user and an your email address as they are used later.\nexport GITHUB_TOKEN=\u0026lt;your-github-access-token\u0026gt; export GITHUB_USER=\u0026lt;your-username\u0026gt; export MY_EMAIL=\u0026lt;your-email-address\u0026gt;\rBootstrap To bootstrap MPAS to your Kubernetes cluster, run the following command. If nothing is specified it will use the KUBECONFIG specified in the user\u0026rsquo;s environment. It is also possible to specify a dedicated config using the \u0026ndash;kubeconfig option.\nmpas bootstrap github \\ --owner=$GITHUB_USER \\ --repository=mpas-bootstrap \\ --path=./clusters/my-cluster \\ --personal\rThis command will create a new Github repository called mpas-bootstrap and bootstrap MPAS to your Kubernetes cluster. The following components will be installed:\nFlux: A Kubernetes operator that will install and manage the other components. ocm-controller: A Kubernetes controller that enables the automated deployment of software components using the Open Component Model and Flux. git-controller: A Kubernetes controller that will create pull requests in the target Github repository when changes are made to the cluster. replication-controller: A Kubernetes controller that keeps keep component versions in the cluster up-to-date with a version defined by the consumer in the ComponentSubscription resource. mpas-product-controller: A Kubernetes controller, responsible for creating a product. Reconciles the Product resource. mpas-project-controller: A Kubernetes controller responsible for bootstrapping a whole project. Creates relevant access credentials, service accounts, roles and the main GitOps repository and reconciles the Project resource. The output of the bootstrap is similar to the following:\nRunning mpas bootstrap ... ✓ Preparing Management repository mpas-bootstrap ✓ Fetching bootstrap component from ghcr.io/open-component-model/mpas-bootstrap-component ✓ Installing flux with version v2.1.0 ✓ Installing cert-manager with version v1.13.1 ✓ Reconciling infrastructure components ✓ Waiting for cert-manager to be available ✓ Generating external-secrets-operator manifest with version v0.9.6 ✓ Generating git-controller manifest with version v0.9.0 ✓ Generating mpas-product-controller manifest with version v0.6.0 ✓ Generating mpas-project-controller manifest with version v0.5.0 ✓ Generating ocm-controller manifest with version v0.14.1 ✓ Generating replication-controller manifest with version v0.8.0 ✓ Generate certificate manifests ✓ Reconciling infrastructure components ✓ Waiting for components to be ready Bootstrap completed successfully!\rAfter completing the bootstrap process, the target github repository will contain yaml manifests for the components to be installed on the cluster and Flux will apply all of them to get the components installed. Furthermore the installed Flux components will be configured to watch the target github repository for changes in the path ./clusters/my-cluster.\nClone the git repository Clone the mpas-bootstrap repository to your local machine:\ngit clone https://github.com/$GITHUB_USER/mpas-bootstrap cd mpas-bootstrap\rDeploy podinfo application The podinfo application has been packaged as an OCM component and can be retrieved from Github.\nCreate a secret containing your GitHub credentials that will be used by MPAS to create your project repository.\nkubectl create secret generic \\ github-access \\ --from-literal=username=$GITHUB_USER \\ --from-literal=password=$GITHUB_TOKEN \\ -n mpas-system\rCreate a project that will contain the podinfo application.\nLet\u0026rsquo;s create a directory for the project:\nmkdir -p ./clusters/my-cluster/podinfo\rThen, create a project.yaml file in the ./clusters/my-cluster/podinfo directory:\nmpas create project podinfo-application \\ --owner=$GITHUB_USER \\ --provider=github \\ --visibility=public \\ --already-exists-policy=fail \\ --branch=main \\ --secret-ref=github-access \\ --email=$MY_EMAIL \\ --message=xxx \\ --author=mpas-admin \\ --maintainers=$GITHUB_USER \\ --prune \\ --personal \\ --export \u0026gt;\u0026gt; ./clusters/my-cluster/podinfo/project.yaml\rThen, apply the project to the cluster in a GitOps fashion:\ngit add --all \u0026amp;\u0026amp; git commit -m \u0026#34;Add podinfo project\u0026#34; \u0026amp;\u0026amp; git push\rFlux will detect the changes and apply the project to the cluster.\nThis will create a namespace for the project, a serviceaccount, and RBAC in the cluster. It will also create a GitHub repository for the project, and configure Flux to manage the project\u0026rsquo;s resources.\nAdd the needed secrets to the namespace\nFlux is used to deploy all workloads in a GitOps way. Flux needs a secret in the project namespace that will be used to communicate with github:\nkubectl create secret generic \\ github-access \\ --from-literal=username=$GITHUB_USER \\ --from-literal=password=$GITHUB_TOKEN \\ -n mpas-podinfo-application\rNote The credentials should have access to GitHub packages.\nAs part of step 2, a serviceaccount was created for the project. We will use this service account to provide the necessary permissions to pull from the ghcr registry.\nFirst, create a secret containing the credentials for the service account:\nkubectl create secret docker-registry github-registry-key --docker-server=ghcr.io \\ --docker-username=$GITHUB_USER --docker-password=$GITHUB_TOKEN \\ --docker-email=$MY_EMAIL -n mpas-podinfo-application\rThen, patch the service account to use the secret:\nkubectl patch serviceaccount mpas-podinfo-application -p \u0026#39;{\u0026#34;imagePullSecrets\u0026#34;: [{\u0026#34;name\u0026#34;: \u0026#34;github-registry-key\u0026#34;}]}\u0026#39; \\ -n mpas-podinfo-application\rClone the project repository\ngit clone https://github.com/$GITHUB_USER/mpas-podinfo-application cd mpas-podinfo-application\rAdd the podinfo ComponentSubscription\nCreate a file under ./subscriptions/ that will contain the subscription declaration.\nmpas create cs podinfo-subscription \\ --component=ocm.software/mpas/podinfo \\ --semver=\u0026#34;\u0026gt;=v1.0.0\u0026#34; \\ --source-url=ghcr.io/open-component-model/mpas \\ --source-secret-ref=github-access \\ --target-url=ghcr.io/$GITHUB_USER \\ --target-secret-ref=github-access \\ --namespace=mpas-podinfo-application \\ --export \u0026gt;\u0026gt; ./subscriptions/podinfo.yaml\rThen, apply the ComponentSubscription to the project in a GitOps fashion:\ngit add --all \u0026amp;\u0026amp; git commit -m \u0026#34;Add podinfo subscription\u0026#34; \u0026amp;\u0026amp; git push\rFlux will detect the changes and apply the subscription to the cluster.\nThis will replicate the product referenced by the field spec.component in the ComponentSubscription resource from the defined registry in spec.source.url to the spec.destination.url registry.\nAdd a Target for the podinfo application\nThe target will define where the application will be installed\ncat \u0026lt;\u0026lt;EOF \u0026gt;\u0026gt; ./targets/podinfo.yaml apiVersion: mpas.ocm.software/v1alpha1 kind: Target metadata: name: podinfo-kubernetes-target namespace: mpas-podinfo-application labels: target.mpas.ocm.software/ingress-enabled: \u0026#34;true\u0026#34; # This label is defined by the component that will use it to select an appropriate target to deploy to. spec: type: kubernetes access: targetNamespace: podinfo serviceAccountName: podinfo-sa selector: matchLabels: mpas.ocm.software/target-selector: podinfo-kubernetes-target interval: 5m0s EOF\rThen, apply the Target to the project in a GitOps fashion:\ngit add --all \u0026amp;\u0026amp; git commit -m \u0026#34;Add a target for podinfo\u0026#34; \u0026amp;\u0026amp; git push\rFlux will detect the changes and apply the target to the cluster.\nIn order for the Target to reach a Ready state, the needed secrets should be created in the podinfo namespace.\nFirst, create a secret containing the credentials for the service account:\nkubectl create secret docker-registry github-registry-key --docker-server=ghcr.io \\ --docker-username=$GITHUB_USER --docker-password=$GITHUB_TOKEN \\ --docker-email=$MY_EMAIL -n podinfo\rThen, add a label to allow the target to select it using the label selector:\nkubectl label secret github-registry-key mpas.ocm.software/target-selector=podinfo-kubernetes-target -n podinfo\rDeploy the podinfo application\nIn order to deploy the podinfo application, we need to create a ProductDeploymentGenerator resource:\nmpas create pdg podinfo \\ --service-account=mpas-podinfo-application \\ --subscription-name=podinfo-subscription \\ --subscription-namespace=mpas-podinfo-application \\ --namespace=mpas-podinfo-application \\ --export \u0026gt;\u0026gt; ./generators/podinfo.yaml\rThen, apply the ProductDeploymentGenerator to the project in a GitOps fashion:\ngit add --all \u0026amp;\u0026amp; git commit -m \u0026#34;Add podinfo deployment generator\u0026#34; \u0026amp;\u0026amp; git push\rFlux will detect the changes and apply the resource to the cluster.\nThis will create a pull request in the project repository with the ProductDeployment resource that will deploy the podinfo application.\nGo to the project repository and retrieve the pull request. It should contain a ProductDeployment declaration that provides the configuration and all steps needed to deploy the product, as well as a values.yaml file. The values file contains values that should be used to configure the different resources that are part of the product to be deployed. There is a check that should pass before merging the pull request.\nOnce the pull request is merged, Flux will detect the changes and deploy the application to the cluster.\nAfter a moment the ProductDeployment should be deployed successfully. It is possible to verify this with the command:\nk describe productdeployment -n mpas-podinfo-application\rThe result should look something like:\nName: podinfo Namespace: mpas-podinfo-application Labels: kustomize.toolkit.fluxcd.io/name=mpas-podinfo-application-products kustomize.toolkit.fluxcd.io/namespace=mpas-system API Version: mpas.ocm.software/v1alpha1 Kind: ProductDeployment Metadata: ... Status: Conditions: Last Transition Time: 2023-09-14T10:14:41Z Message: Reconciliation success Observed Generation: 1 Reason: Succeeded Status: True Type: Ready Observed Generation: 1\rThe application is deployed in the podinfo namespace.\n","date":"2023-09-12","id":46,"permalink":"/mpas/getting_started/","summary":"\u003cp\u003eThis tutorial shows you how to bootstrap MPAS to a Kubernetes cluster and deploy\na simple application.\u003c/p\u003e\n\u003ch2 id=\"prerequisites\"\u003ePrerequisites\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eA Kubernetes cluster\u003c/li\u003e\n\u003cli\u003eA GitHub access token with \u003ccode\u003erepo\u003c/code\u003e scope\u003c/li\u003e\n\u003cli\u003ekubectl\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"objectives\"\u003eObjectives\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eBootstrap MPAS to a Kubernetes cluster\u003c/li\u003e\n\u003cli\u003eDeploy a simple application\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"install-the-mpas-cli\"\u003eInstall the MPAS CLI\u003c/h2\u003e\n\u003cp\u003eThe MPAS CLI is the primary tool for interacting with MPAS. It can be used to\nbootstrap MPAS to a Kubernetes cluster.\u003c/p\u003e","tags":[],"title":"Get Started with MPAS"},{"content":"Install using Binaries To install the MPAS CLI, you can download the binaries for major platforms from the GitHub releases page.\nHomebrew You can also install via homebrew for macOS and Linux:\nbrew install open-component-model/tap/mpas\rBash To install with bash for macOS or Linux execute the following command:\ncurl -sfL https://raw.githubusercontent.com/open-component-model/mpas/main/install.sh | sh -\r","date":"2023-09-12","id":47,"permalink":"/mpas/installation/","summary":"\u003ch2 id=\"install-using-binaries\"\u003eInstall using Binaries\u003c/h2\u003e\n\u003cp\u003eTo install the MPAS CLI, you can download the binaries for major platforms from the GitHub \u003ca href=\"https://github.com/open-component-model/mpas/releases\"\u003ereleases page\u003c/a\u003e.\u003c/p\u003e","tags":[],"title":"Installation"},{"content":"This section describes the core concepts of MPAS and what Kubernetes controllers and custom resources are contained. To learn more about the MPAS architecture, see Architecture.\nProduct A Product is a package of software that can be deployed to target environments such as Kubernetes clusters, virtual machines or bare-metal devices.\nProducts are made available to the MPAS system as OCM Components via a Subscription. Multiple instances of a Product may be installed that refer to the same Subscription.\nA ProductDeployment is a Kubernetes Custom Resource that represents a product to be deployed to a target. The ProductDeployment is reconciled by the MPAS Product Controller which will generate the necessary Kubernetes resources to deploy the product to the cluster.\nA ProductDeploymentGenerator is a Kubernetes Custom Resource that represents a ProductDeployment to be deployed to a Kubernetes cluster. The ProductDeploymentGenerator is reconciled by the MPAS Product Controller in order to generate the ProductDeployment resource.\nA ProductDescription is a manifest that describes a product. It specifies the set of resources that are needed to deploy the product in a form of pipeline steps. The ProductDescription is retrieved by the MPAS Product Controller in order to generate the ProductDeployment resource during a ProductDeploymentGenerator reconciliation.\nA ProductDeploymentPipeline is a Kubernetes Custom Resource that defines a resource that needs to be deployed as part of the ProductDeployment. The ProductDeploymentPipeline is reconciled by the MPAS Product Controller as part of the ProductDeployment deployment.\nProject A Project is a Kubernetes Custom Resource that is used to manage the lifecycle of a MPAS project. A Project is reconciled by the MPAS Project Controller which will generate a project namespace and a git repository for the project containing the project folder structure. The controller will also generate the necessary Flux kustomization resources in the mpas-system namespace in order to update the cluster with the project resources from the git repository. All items that the MPAS Project Controller created during reconcile, are visible in the status subresource of a Project CR.\nThe project git repository is designed to be used as a GitOps repository for the project. It contains all the product custom resources in order to be deployed to the cluster.\nSubscription The purpose of a Subscription is to replicate OCM components containing a particular product from a delivery registry into a target registry in the MPAS customer\u0026rsquo;s environment.\nA ComponentSubscription is a Kubernetes Custom Resource that represents a subscription to a component. The ComponentSubscription is reconciled by the Replication Controller which will transfer the OCM component into the target registry using the OCM library.\nTarget A Target is a Kubernetes Custom Resource that represents a target environment where a Product should be deployed. The MPAS Product Controller controller reconciles the Target and creates any necessary prerequisite that needs to exist in the target environment, e.g. a namespace and a service account.\n","date":"2023-09-12","id":48,"permalink":"/mpas/core_concepts/","summary":"\u003cp\u003eThis section describes the core concepts of \u003ccode\u003eMPAS\u003c/code\u003e and what Kubernetes controllers and custom resources are contained.\nTo learn more about the \u003ccode\u003eMPAS\u003c/code\u003e architecture,\nsee \u003ca href=\"https://github.com/open-component-model/MPAS/tree/main/docs/concepts\"\u003eArchitecture\u003c/a\u003e.\u003c/p\u003e","tags":[],"title":"Core Concepts"},{"content":"The mpas bootstrap command deploys the following components to your cluster:\nFlux: A Kubernetes operator that will install and manage the other components. ocm-controller: A Kubernetes controller that enables the automated deployment of software using the Open Component Model and Flux. git-controller: A Kubernetes controller that will create pull requests in the target Github repository when changes are made to the cluster. replication-controller: A Kubernetes controller that replicates everything defined and bundled in an OCM component version (and that the consumer subscribed to) into the local OCI registry of the cluster. mpas-product-controller: A Kubernetes controller responsible for creating the custom resource Product. mpas-project-controller: A Kubernetes controller responsible for bootstrapping a whole project and creating relevant access credentials, service accounts, roles and the main repository. It reconciles the Project resource. Besides the above components, the mpas bootstrap command will also push the corresponding component manifests to the target Git repository and configure Flux to continuously update the installed components from the target Git repository.\nAfter the mpas bootstrap command is executed, the cluster is ready to deploy software in a GitOps fashion using the Open Component Model and MPAS.\nCluster Admin Rights\nTo bootstrap MPAS, the person running the command must have cluster admin rights for the target Kubernetes cluster. It is also required that the person running the command to be the owner of the GitHub repository, or to have admin rights of a GitHub organization.\nBootstrap for GitHub GitHub Personal Access Token (PAT) For accessing the GitHub API, the boostrap command requires a GitHub personal access token (PAT) with administration permissions.\nThe GitHub PAT can be exported as environment variable:\nexport GITHUB_TOKEN=\u0026lt;your-github-pat\u0026gt;\rIf the GITHUB_TOKEN environment variable is not set, the mpas bootstrap command will prompt for the GitHub PAT.\nToken in Secret\nNote that the GitHub PAT is stored in the cluster as a Kubernetes Secret named flux-system inside the flux-system namespace.\nPersonal account Run the bootstrap for a repository on your personal GitHub account:\nmpas bootstrap github \\ --owner=\u0026lt;your-github-username\u0026gt; \\ --repository=\u0026lt;your-github-repository\u0026gt; \\ --path=clusters/my-cluster \\ --dev \\ --personal\rIf the specified repository does not exist, the mpas bootstrap command will create it as a private repository. If you wish to create a public repository, you can use the --private=false flag.\nOrganization If you want to bootstrap MPAS for a repository owned by an GitHub organization, it is recommended to create a dedicated GitHub user for MPAS and use that user to bootstrap the repository.\nRun the bootstrap for a repository owned by a GitHub organization:\nmpas bootstrap github \\ --owner=\u0026lt;your-github-organization\u0026gt; \\ --repository=\u0026lt;your-github-repository\u0026gt; \\ --path=clusters/my-cluster \\ --dev\rBootstrap for Gitea Gitea API token For accessing the Gitea API, the boostrap command requires a Gitea API token with administration permissions.\nThe Gitea API Token can be exported as an environment variable:\nexport GITEA_TOKEN=\u0026lt;your-gitea-api-token\u0026gt;\rIf the GITEA_TOKEN environment variable is not set, the mpas bootstrap command will prompt for the Gitea API token.\nToken in Secret\nNote that the Gitea API Token is stored in the cluster as a Kubernetes Secret named flux-system inside the flux-system namespace.\nPersonal account Run bootstrap for a repository on your personal Gitea account:\nmpas bootstrap gitea \\ --owner=\u0026lt;your-gite -username\u0026gt; \\ --repository=\u0026lt;your-gitea-repository\u0026gt; \\ --path=clusters/my-cluster \\ --dev \\ --personal\rIf the specified repository does not exist, the mpas bootstrap command will create it as a private repository. If you wish to create a public repository, you can use the --private=false flag.\nOrganization If you want to bootstrap MPAS for a repository owned by an Gitea organization, it is recommended to create a dedicated Gitea user for MPAS and use that user to bootstrap the repository.\nRun the bootstrap for a repository owned by a Gitea organization:\nmpas bootstrap gitea \\ --owner=\u0026lt;your-gitea-organization\u0026gt; \\ --repository=\u0026lt;your-gitea-repository\u0026gt; \\ --path=clusters/my-cluster \\ --dev\rBootstrap for an air-gapped environment If you want to bootstrap MPAS for a repository in an air-gapped environment, only Gitea is supported at the moment.\nExport the bootstrap components bundle To bootstrap MPAS in an air-gapped environment, you need to export the bootstrap components bundle from the MPAS default registry.\nmpas bootstrap \\ --export \\ --export-path=/tmp\rThe above command will export the bootstrap components archive to /tmp/mpas-bundle.tar.gz.\nIt is then possible to import the bootstrap components bundle into an air-gapped environment registry and use it to bootstrap MPAS for a repository in that environment.\nmpas bootstrap gitea \\ --owner=\u0026lt;your-gitea-organization\u0026gt; \\ --repository=\u0026lt;your-gitea-repository\u0026gt; \\ --from-file=/tmp/mpas-bundle.tar.gz \\ --registry=\u0026lt;your-air-gapped-registry\u0026gt; \\ --path=clusters/my-cluster \\ --dev\rThe above command will copy the bootstrap components from the bundle archive to the specified air-gapped registry and bootstrap MPAS for the specified repository.\n","date":"2023-09-12","id":49,"permalink":"/mpas/bootstrap/","summary":"\u003cp\u003eThe \u003ccode\u003empas bootstrap\u003c/code\u003e command deploys the following components to your cluster:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://fluxcd.io/docs/components/\"\u003eFlux\u003c/a\u003e: A Kubernetes operator that will\ninstall and manage the other components.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/open-component-model/ocm-controller\"\u003eocm-controller\u003c/a\u003e: A Kubernetes controller\nthat enables the automated deployment of software using the Open Component Model and \u003ccode\u003eFlux\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/open-component-model/git-controller\"\u003egit-controller\u003c/a\u003e: A\nKubernetes controller that will create pull requests in the target Github repository\nwhen changes are made to the cluster.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/open-component-model/git-controller\"\u003ereplication-controller\u003c/a\u003e: A Kubernetes controller that replicates\neverything defined and bundled in an OCM component version (and that the consumer subscribed to)\ninto the local OCI registry of the cluster.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/open-component-model/mpas-product-controller\"\u003empas-product-controller\u003c/a\u003e: A Kubernetes controller responsible\nfor creating the custom resource \u003ccode\u003eProduct\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/open-component-model/mpas-project-controller\"\u003empas-project-controller\u003c/a\u003e: A Kubernetes controller responsible\nfor bootstrapping a whole project and creating relevant access credentials, service accounts, roles and the main repository.\nIt reconciles the \u003ccode\u003eProject\u003c/code\u003e resource.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eBesides the above components, the \u003ccode\u003empas bootstrap\u003c/code\u003e command will also push the corresponding\ncomponent manifests to the target Git repository and configure \u003ccode\u003eFlux\u003c/code\u003e to continuously update\nthe installed components from the target Git repository.\u003c/p\u003e","tags":[],"title":"Bootstrap"},{"content":"Demo of MPAS\n","date":"2024-04-02","id":50,"permalink":"/mpas/demo_of_mpas/","summary":"\u003cp\u003e\u003ca href=\"https://sapvideoa35699dc5.hana.ondemand.com/?entry_id=1_2u4p4u7z\"\u003eDemo of MPAS\u003c/a\u003e\u003c/p\u003e","tags":[],"title":"MPAS Demo Video"},{"content":"Overview The OCM command line client can be configured by supplying it with a configuration file. By default, the CLI looks for configuration in $HOME/.ocmconfig, if it exists.\nThe configuration file can be used in particular to specify the credentials, which are required for the CLI to be able to access the artifact repositories referenced in CLI commands.\nExamples This page contains basic examples of credentials configuration for a few most common artifact repository types. The examples below are complete .ocmconfig files, not snippets.\nFor comprehensive documentation on the credentials topic, including usage of certificates or HashiCorp Vault, execute the command ocm credential-handling.\nRepositories and Consumers In the examples below, some configuration is located under configurations[0].repositories, and some other under configurations[0].consumers. This chapter explains the difference between repositories and consumers, which is potentially not as obvious as one could think.\nIn this context, repository is a place where credentials can be stored, i.e., it is a credentials repository. For example, Docker\u0026rsquo;s config.json can store multiple credentials, and in that sense the file serves as a repository that can store and provide credentials. That is why its location is configured under repositories. Other examples of credentials repositories can be the NPM\u0026rsquo;s .npmrc file or a HashiCorp Vault instance.\nA consumer is something the credentials are required for. For example, if you need to configure credentials that are required to log in to an OCI registry, one could say that the registry will be consuming these credentials, i.e., the registry is a credentials consumer. That is why it is configured under consumers.\nReuse Credentials Configured for Docker This .ocmconfig file will tell the OCM CLI to use credentials configuration from Docker\u0026rsquo;s config.json file.\ntype: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software repositories: - repository: type: DockerConfig/v1 dockerConfigFile: \u0026#34;~/.docker/config.json\u0026#34;\rReuse Credentials Configured for npm This .ocmconfig file will tell OCM CLI to use credentials configuration from npm\u0026rsquo;s .npmrc file.\ntype: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software repositories: - repository: type: NPMConfig/v1 npmrcFile: \u0026#39;~/.npmrc\u0026#39;\rAccessing OCI Registries HTTPS and Path To access artifacts in https://ghcr.io/open-component-model:\nThe different parts of the URL have to be specified in separate fields: scheme, hostname, and pathprefix The fields scheme and pathprefix are optional. If not specified, the OCM CLI will use the credentials for all schemes and paths on that host The password is the user\u0026rsquo;s basic authentication password. Some OCI registries allow to generate user access tokens, which can also be used for basic authentication type: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software consumers: - identity: type: OCIRegistry scheme: https hostname: ghcr.io pathprefix: open-component-model credentials: - type: Credentials properties: username: some-user password: some-token\rHTTP, Port Number, Empty Path To access artifacts in http://127.0.0.1:5001:\nThe fields scheme and port are optional. If not specified, the OCM CLI will use the credentials for all schemes and ports on that host As the URL has no path behind the port number, the pathprefix element can be removed type: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software consumers: - identity: type: OCIRegistry scheme: http hostname: 127.0.0.1 port: 5001 credentials: - type: Credentials properties: username: admin password: admin\rAccessing Helm Chart Repositories Similar to OCI registries, but uses HelmChartRepository as identity type.\ntype: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software consumers: - identity: type: HelmChartRepository hostname: ghcr.io pathprefix: open-component-model credentials: - type: Credentials properties: username: some-user password: some-token\rAccessing Maven Repositories Similar to OCI registries, but uses MavenRepository as identity type.\ntype: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software consumers: - identity: type: MavenRepository hostname: maven.repo.host pathprefix: path/to/repo credentials: - type: Credentials properties: username: some-user password: some-password\rAccessing npm Registries Similar to OCI registries, but uses NpmRegistry as identity type. In addition, it is required to specify the email address matching with the one in the user record in the npm registry.\ntype: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software consumers: - identity: type: NpmRegistry hostname: npm.registry.host pathprefix: path/to/registry credentials: - type: Credentials properties: username: some-user password: some-password email: foo.bar@acme.org\rAccessing GitHub Repositories To access code in https://my.github.enterprise/my-org/my-repo:\nUse Github as identity type hostname is the domain name of the GitHub instance pathprefix is a combination of organization and repository names token is a personal access token generated in GitHub Developer Settings type: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software consumers: - identity: type: Github hostname: my.github.enterprise pathprefix: my-org/my-repo credentials: - type: Credentials properties: token: ghp_my_personal_access_token\rAccessing Several Systems It is, of course, possible to configure credentials for several systems in the same .ocmconfig file. To do that, you can combine as many repositories and consumers as you need.\nThe example below instructs OCM CLI to look for credentials in Docker\u0026rsquo;s config.json, and in addition specifies dedicated credentials for an OCI registry and a GitHub repository.\ntype: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software repositories: - repository: type: DockerConfig/v1 dockerConfigFile: \u0026#34;~/.docker/config.json\u0026#34; propagateConsumerIdentity: true consumers: - identity: type: OCIRegistry hostname: ghcr.io pathprefix: open-component-model credentials: - type: Credentials properties: username: some-user password: some-token - identity: type: Github hostname: my.github.enterprise pathprefix: my-org/my-repo credentials: - type: Credentials properties: token: ghp_my_personal_access_token\r","date":"2024-09-04","id":51,"permalink":"/docs/examples/credentials-in-an-.ocmconfig-file/","summary":"\u003ch2 id=\"overview\"\u003eOverview\u003c/h2\u003e\n\u003cp\u003eThe \u003ca href=\"https://github.com/open-component-model/ocm/blob/main/docs/reference/ocm.md\"\u003eOCM command line client\u003c/a\u003e can be configured by supplying it with a \u003ca href=\"https://github.com/open-component-model/ocm/blob/main/docs/reference/ocm_configfile.md\"\u003econfiguration file\u003c/a\u003e. By default, the CLI looks for configuration in \u003ccode\u003e$HOME/.ocmconfig\u003c/code\u003e, if it exists.\u003c/p\u003e","tags":[],"title":"Credentials in an .ocmconfig file"},{"content":"","date":"2024-09-04","id":52,"permalink":"/docs/","summary":"","tags":[],"title":"Docs"},{"content":"","date":"2024-04-02","id":53,"permalink":"/mpas/","summary":"","tags":[],"title":"Mpas"},{"content":"","date":"2020-10-06","id":54,"permalink":"/","summary":"","tags":[],"title":"Open Component Model"},{"content":"Usage ocm add [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for add\rSee Also Sub Commands ocm add componentversions\t— add component version(s) to a (new) transport archive ocm add references\t— add aggregation information to a component version ocm add resource-configuration\t— add a resource specification to a resource config file ocm add resources\t— add resources to a component version ocm add routingslips\t— add routing slip entry ocm add source-configuration\t— add a source specification to a source config file ocm add sources\t— add source information to a component version ","date":"0001-01-01","id":55,"permalink":"/docs/cli-reference/add/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm add [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for add\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/add/componentversions/\"\u003eocm add \u003cb\u003ecomponentversions\u003c/b\u003e\u003c/a\u003e\t — add component version(s) to a (new) transport archive\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/add/references/\"\u003eocm add \u003cb\u003ereferences\u003c/b\u003e\u003c/a\u003e\t — add aggregation information to a component version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/add/resource-configuration/\"\u003eocm add \u003cb\u003eresource-configuration\u003c/b\u003e\u003c/a\u003e\t — add a resource specification to a resource config file\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/add/resources/\"\u003eocm add \u003cb\u003eresources\u003c/b\u003e\u003c/a\u003e\t — add resources to a component version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/add/routingslips/\"\u003eocm add \u003cb\u003eroutingslips\u003c/b\u003e\u003c/a\u003e\t — add routing slip entry\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/add/source-configuration/\"\u003eocm add \u003cb\u003esource-configuration\u003c/b\u003e\u003c/a\u003e\t — add a source specification to a source config file\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/add/sources/\"\u003eocm add \u003cb\u003esources\u003c/b\u003e\u003c/a\u003e\t — add source information to a component version\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"add"},{"content":"Usage ocm describe artifacts [\u0026lt;options\u0026gt;] {\u0026lt;artifact-reference\u0026gt;}\rOptions -h, --help help for artifacts --layerfiles list layer files -o, --output string output mode (JSON, json, yaml) --repo string repository name or spec\rDescription Describe lists all artifact versions specified, if only a repository is specified all tagged artifacts are listed. Per version a detailed, potentially recursive description is printed.\nIf the repository/registry option is specified, the given names are interpreted relative to the specified registry using the syntax\n\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as extended OCI artifact references.\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e]/\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] The \u0026ndash;repo option takes a repository/OCI registry specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz are possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nArtifactSet: v1 CommonTransportFormat: v1 DockerDaemon: v1 Empty: v1 OCIRegistry: v1 oci: v1 ociRegistry With the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json yaml Examples $ ocm describe artifact ghcr.io/open-component-model/ocm/component-descriptors/ocm.software/ocmcli:0.17.0 $ ocm describe artifact ghcr.io/open-component-model/ocm/ocm.software/ocmcli/ocmcli-image:0.17.0\rSee Also ocm describe\t— Describe various elements by using appropriate sub commands. ","date":"0001-01-01","id":56,"permalink":"/docs/cli-reference/describe/artifacts/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm describe artifacts [\u0026lt;options\u0026gt;] {\u0026lt;artifact-reference\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for artifacts\n --layerfiles list layer files\n -o, --output string output mode (JSON, json, yaml)\n --repo string repository name or spec\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eDescribe lists all artifact versions specified, if only a repository is specified\nall tagged artifacts are listed.\nPer version a detailed, potentially recursive description is printed.\u003c/p\u003e","tags":[],"title":"artifacts"},{"content":"Usage ocm download artifacts [\u0026lt;options\u0026gt;] {\u0026lt;artifact\u0026gt;} Options --dirtree extract as effective filesystem content -h, --help help for artifacts --layers ints extract dedicated layers -O, --outfile string output file or directory --repo string repository name or spec -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\rDescription Download artifacts from an OCI registry. The result is stored in artifact set format, without the repository part\nThe files are named according to the artifact repository name.\nIf the repository/registry option is specified, the given names are interpreted relative to the specified registry using the syntax\n\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as extended OCI artifact references.\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e]/\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] The \u0026ndash;repo option takes a repository/OCI registry specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz are possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nArtifactSet: v1 CommonTransportFormat: v1 DockerDaemon: v1 Empty: v1 OCIRegistry: v1 oci: v1 ociRegistry With option \u0026ndash;layers it is possible to request the download of dedicated layers, only. Option \u0026ndash;dirtree expects the artifact to be a layered filesystem (for example OCI Image) and provided the effective filesystem content.\nThe \u0026ndash;type option accepts a file format for the target archive to use. It is only evaluated if the target archive does not exist yet. The following formats are supported:\ndirectory tar tgz The default format is directory.\nSee Also ocm download\t— Download oci artifacts, resources or complete components ","date":"0001-01-01","id":57,"permalink":"/docs/cli-reference/download/artifacts/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm download artifacts [\u0026lt;options\u0026gt;] {\u0026lt;artifact\u0026gt;} \u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --dirtree extract as effective filesystem content\n -h, --help help for artifacts\n --layers ints extract dedicated layers\n -O, --outfile string output file or directory\n --repo string repository name or spec\n -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eDownload artifacts from an OCI registry. The result is stored in\nartifact set format, without the repository part\u003c/p\u003e","tags":[],"title":"artifacts"},{"content":"Usage ocm get artifacts [\u0026lt;options\u0026gt;] {\u0026lt;artifact-reference\u0026gt;}\rOptions -a, --attached show attached artifacts -h, --help help for artifacts -o, --output string output mode (JSON, json, tree, wide, yaml) -r, --recursive follow index nesting --repo string repository name or spec -s, --sort stringArray sort fields\rDescription Get lists all artifact versions specified, if only a repository is specified all tagged artifacts are listed.\nIf the repository/registry option is specified, the given names are interpreted relative to the specified registry using the syntax\n\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as extended OCI artifact references.\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e]/\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] The \u0026ndash;repo option takes a repository/OCI registry specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz are possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nArtifactSet: v1 CommonTransportFormat: v1 DockerDaemon: v1 Empty: v1 OCIRegistry: v1 oci: v1 ociRegistry With the option \u0026ndash;recursive the complete reference tree of a index is traversed.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json tree wide yaml Examples $ ocm get artifact ghcr.io/open-component-model/ocm/component-descriptors/ocm.software/ocmcli $ ocm get artifact ghcr.io/open-component-model/ocm/ocm.software/ocmcli/ocmcli-image:0.17.0\rSee Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":58,"permalink":"/docs/cli-reference/get/artifacts/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get artifacts [\u0026lt;options\u0026gt;] {\u0026lt;artifact-reference\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -a, --attached show attached artifacts\n -h, --help help for artifacts\n -o, --output string output mode (JSON, json, tree, wide, yaml)\n -r, --recursive follow index nesting\n --repo string repository name or spec\n -s, --sort stringArray sort fields\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eGet lists all artifact versions specified, if only a repository is specified\nall tagged artifacts are listed.\u003c/p\u003e","tags":[],"title":"artifacts"},{"content":"Usage ocm transfer artifacts [\u0026lt;options\u0026gt;] {\u0026lt;artifact-reference\u0026gt;} \u0026lt;target\u0026gt;\rOptions -h, --help help for artifacts --repo string repository name or spec -R, --repo-name transfer repository name\rDescription Transfer OCI artifacts from one registry to another one. Several transfer scenarios are supported:\ncopy a set of artifacts (for the same repository) into another registry copy a set of artifacts (for the same repository) into another repository copy artifacts from multiple repositories into another registry copy artifacts from multiple repositories into another registry with a given repository prefix (option -R) By default, the target is seen as a single repository if a repository is specified. If a complete registry is specified as target, option -R is implied, but the source must provide a repository. THis combination does not allow an artifact set as source, which specifies no repository for the artifacts.\nSources may be specified as\ndedicated artifacts with repository and version or tag repository (without version), which is resolved to all available tags registry, if the specified registry implementation supports a namespace/repository lister, which is not the case for registries conforming to the OCI distribution specification. Note that there is an indirection of \u0026ldquo;ocm oci artifact\u0026rdquo; to \u0026ldquo;ocm transfer artifact\u0026rdquo; out of convenience.\nIf the repository/registry option is specified, the given names are interpreted relative to the specified registry using the syntax\n\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as extended OCI artifact references.\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e]/\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] The \u0026ndash;repo option takes a repository/OCI registry specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz are possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nArtifactSet: v1 CommonTransportFormat: v1 DockerDaemon: v1 Empty: v1 OCIRegistry: v1 oci: v1 ociRegistry Examples # Simple: $ ocm transfer artifact ghcr.io/open-component-model/ocm/ocm.software/ocmcli/ocmcli-image:0.17.0 ghcr.io/MY_USER/ocmcli:0.17.0 $ ocm transfer artifact ghcr.io/open-component-model/ocm/ocm.software/ocmcli/ocmcli-image ghcr.io/MY_USER/ocmcli $ ocm transfer artifact ghcr.io/open-component-model/ocm/ocm.software/ocmcli/ocmcli-image gcr.io $ ocm transfer artifact transfer /tmp/ctf ghcr.io/MY_USER/ocmcli # Equivalent to ocm transfer artifact: $ ocm oci artifact transfer # Complex: # Transfer an artifact from a CTF into an OCI Repository: # 1. Get the link to all artifacts in the CTF with \u0026#34;ocm get artifact $PATH_TO_CTF\u0026#34;, $ ocm get artifact $PATH_TO_CTF REGISTRY REPOSITORY CommonTransportFormat::$PATH_TO_CTF/ component-descriptors/ocm.software/ocmcli # 2. Then use any combination to form an artifact reference: $ ocm transfer artifact CommonTransportFormat::$PATH_TO_CTF//component-descriptors/ocm.software/ocmcli ghcr.io/open-component-model/ocm:latest\rSee Also ocm transfer\t— Transfer artifacts or components ","date":"0001-01-01","id":59,"permalink":"/docs/cli-reference/transfer/artifacts/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm transfer artifacts [\u0026lt;options\u0026gt;] {\u0026lt;artifact-reference\u0026gt;} \u0026lt;target\u0026gt;\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for artifacts\n --repo string repository name or spec\n -R, --repo-name transfer repository name\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eTransfer OCI artifacts from one registry to another one.\nSeveral transfer scenarios are supported:\u003c/p\u003e","tags":[],"title":"artifacts"},{"content":"Description The OCM library supports a set of attributes, which can be used to influence the behaviour of various functions. The CLI also supports setting of those attributes using the config file (see ocm configfile) or by command line options of the main command (see ocm).\nThe following options are available in the currently used version of the OCM library:\ngithub.com/mandelsoft/logforward [logfwd]: logconfig Logging config structure used for config forwarding\nThis attribute is used to specify a logging configuration intended to be forwarded to other tools. (For example: TOI passes this config to the executor)\ngithub.com/mandelsoft/oci/cache [cache]: string\nFilesystem folder to use for caching OCI blobs\ngithub.com/mandelsoft/ocm/compat [compat]: bool\nCompatibility mode: Avoid generic local access methods and prefer type specific ones.\ngithub.com/mandelsoft/ocm/hasher: JSON\nPreferred hash algorithm to calculate resource digests. The following digesters are supported:\nNO-DIGEST SHA-256 (default) SHA-512 github.com/mandelsoft/ocm/keeplocalblob [keeplocalblob]: bool\nKeep local blobs when importing OCI artifacts to OCI registries from localBlob access methods. By default, they will be expanded to OCI artifacts with the access method ociRegistry. If this option is set to true, they will be stored as local blobs, also. The access method will still be localBlob but with a nested ociRegistry access method for describing the global access.\ngithub.com/mandelsoft/ocm/mapocirepo [mapocirepo]: bool|YAML\nWhen uploading an OCI artifact blob to an OCI based OCM repository and the artifact is uploaded as OCI artifact, the repository path part is shortened, either by hashing all but the last repository name part or by executing some prefix based name mappings.\nIf a boolean is given the short hash or none mode is enabled. The YAML flavor uses the following fields:\nmode string: hash, shortHash, prefixMapping or none. If unset, no mapping is done. prefixMappings: map[string]string repository path prefix mapping. prefix: string repository prefix to use (replaces potential sub path of OCM repo). or none. prefixMapping: map[string]string repository path prefix mapping. Notes:\nThe mapping only occurs in transfer commands and only when transferring to OCI registries (e.g. when transferring to a CTF archive this option will be ignored). The mapping in mode prefixMapping requires a full prefix of the composed final name. Partial matches are not supported. The host name of the target will be skipped. The artifact name of the component-descriptor is not mapped. If the mapping is provided on the command line it must be JSON format and needs to be properly escaped (see example below). Example:\nAssume a component named github.com/my_org/myexamplewithalongname and a chart name echo in the Charts.yaml of the chart archive. The following input to a resource.yaml creates a component version:\nname: mychart type: helmChart input: type: helm path: charts/mychart.tgz --- name: myimage type: ociImage version: 0.1.0 input: type: ociImage repository: ocm/ocm.software/ocmcli/ocmcli-image path: ghcr.io/acme/ocm/ocm.software/ocmcli/ocmcli-image:0.1.0 The following command:\nocm \"-X mapocirepo={\\\"mode\\\":\\\"mapping\\\",\\\"prefixMappings\\\":{\\\"acme/github.com/my_org/myexamplewithalongname/ocm/ocm.software/ocmcli\\\":\\\"acme/cli\\\", \\\"acme/github.com/my_org/myexamplewithalongnameabc123\\\":\\\"acme/mychart\\\"}}\" transfer ctf -f --copy-resources ./ctf ghcr.io/acme will result in the following artifacts in ghcr.io/my_org:\nmychart/echo cli/ocmcli-image Note that the host name part of the transfer target ghcr.io/acme is excluded from the prefix but the path acme is considered.\nThe same using a config file .ocmconfig:\ntype: generic.config.ocm.software/v1 configurations: ... - type: attributes.config.ocm.software attributes: ... mapocirepo: mode: mapping prefixMappings: acme/github.com/my\\_org/myexamplewithalongname/ocm/ocm.software/ocmcli: acme/cli acme/github.com/my\\_org/myexamplewithalongnameabc123: acme/mychart ocm transfer ca -f --copy-resources ./ca ghcr.io/acme github.com/mandelsoft/ocm/ociuploadrepo [ociuploadrepo]: oci base repository ref\nUpload local OCI artifact blobs to a dedicated repository.\ngithub.com/mandelsoft/ocm/plugindir [plugindir]: plugin directory\nDirectory to look for OCM plugin executables.\ngithub.com/mandelsoft/ocm/rootcerts [rootcerts]: JSON\nGeneral root certificate settings given as JSON document with the following format:\n{ \"rootCertificates\": [ { \"data\": \"\"\u0026lt;base64\u003e\" }, { \"path\": \"\"\u0026lt;file path\u003e\" } ] } One of following data fields are possible:\ndata: base64 encoded binary data stringdata: plain text data path: a file path to read the data from github.com/mandelsoft/ocm/signing: JSON\nPublic and private Key settings given as JSON document with the following format:\n{ \"publicKeys\": [ \"\u0026lt;provider\u003e\": { \"data\": \"\"\u0026lt;base64\u003e\" } ], \"privateKeys\"\": [ \"\u0026lt;provider\u003e\": { \"path\": \"\"\u0026lt;file path\u003e\" } ] } One of following data fields are possible:\ndata: base64 encoded binary data stringdata: plain text data path: a file path to read the data from github.com/mandelsoft/tempblobcache [blobcache]: string Foldername for temporary blob cache\nThe temporary blob cache is used to accessing large blobs from remote systems. The are temporarily stored in the filesystem, instead of the memory, to avoid blowing up the memory consumption.\nocm.software/cliconfig [cliconfig]: cliconfig Configuration Object passed to command line plugin.\nocm.software/compositionmode [compositionmode]: bool (default: false)\nComposition mode decouples a component version provided by a repository implementation from the backend persistence. Added local blobs will and other changes will not be forwarded to the backend repository until an AddVersion is called on the component. If composition mode is disabled blobs will directly be forwarded to the backend and descriptor updated will be persisted on AddVersion or closing a provided existing component version.\nocm.software/signing/sigstore [sigstore]: sigstore config Configuration to use for sigstore based signing.\nThe following fields are used.\nfulcioURL string default is https://fulcio.sigstore.dev rekorURL string default is https://rekor.sigstore.dev OIDCIssuer string default is https://oauth2.sigstore.dev/auth OIDCClientID string default is sigstore See Also ","date":"0001-01-01","id":60,"permalink":"/docs/cli-reference/help/attributes/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eThe OCM library supports a set of attributes, which can be used to influence\nthe behaviour of various functions. The CLI also supports setting of those\nattributes using the config file (see \u003ca href=\"/docs/cli-reference/help/configfile/\"\u003eocm configfile\u003c/a\u003e) or by\ncommand line options of the main command (see \u003ca href=\"/docs/cli-reference/\"\u003eocm\u003c/a\u003e).\u003c/p\u003e","tags":[],"title":"attributes"},{"content":"Usage ocm clean cache [\u0026lt;options\u0026gt;]\rOptions -b, --before string time since last usage -s, --dry-run show size to be removed -h, --help help for cache\rDescription Cleanup all blobs stored in oci blob cache (if given).\nExamples $ ocm clean cache\rSee Also ocm clean\t— Cleanup/re-organize elements ","date":"0001-01-01","id":61,"permalink":"/docs/cli-reference/clean/cache/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm clean cache [\u0026lt;options\u0026gt;]\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -b, --before string time since last usage\n -s, --dry-run show size to be removed\n -h, --help help for cache\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eCleanup all blobs stored in oci blob cache (if given).\u003c/p\u003e","tags":[],"title":"cache"},{"content":"Usage ocm describe cache [\u0026lt;options\u0026gt;]\rOptions -h, --help help for cache\rDescription Show details about the OCI blob cache (if given).\nExamples $ ocm cache info\rSee Also ocm describe\t— Describe various elements by using appropriate sub commands. ","date":"0001-01-01","id":62,"permalink":"/docs/cli-reference/describe/cache/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm describe cache [\u0026lt;options\u0026gt;]\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for cache\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eShow details about the OCI blob cache (if given).\u003c/p\u003e","tags":[],"title":"cache"},{"content":"","date":"0001-01-01","id":63,"permalink":"/categories/","summary":"","tags":[],"title":"Categories"},{"content":"Usage ocm check [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for check\rSee Also Sub Commands ocm check componentversions\t— Check completeness of a component version in an OCM repository ","date":"0001-01-01","id":64,"permalink":"/docs/cli-reference/check/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm check [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for check\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/check/componentversions/\"\u003eocm check \u003cb\u003ecomponentversions\u003c/b\u003e\u003c/a\u003e\t — Check completeness of a component version in an OCM repository\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"check"},{"content":"Usage ocm clean [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for clean\rSee Also Sub Commands ocm clean cache\t— cleanup oci blob cache ","date":"0001-01-01","id":65,"permalink":"/docs/cli-reference/clean/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm clean [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for clean\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/clean/cache/\"\u003eocm clean \u003cb\u003ecache\u003c/b\u003e\u003c/a\u003e\t — cleanup oci blob cache\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"clean"},{"content":"Usage ocm download cli [\u0026lt;options\u0026gt;] [\u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}]\rOptions -c, --constraints constraints version constraint -h, --help help for cli -O, --outfile string output file or directory -p, --path lookup executable in PATH --repo string repository name or spec --use-verified enable verification store --verified string file used to remember verifications for downloads (default \u0026#34;~/.ocm/verified\u0026#34;) --verify verify downloads\rDescription Download an OCM CLI executable. By default, the standard publishing component and repository is used. Optionally, another component or repo and even a resource can be specified. Resources are specified by identities. An identity consists of a name argument followed by optional \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; arguments.\nThe option -O is used to declare the output destination. The default location is the location of the ocm executable in the actual PATH.\nIf the option \u0026ndash;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.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 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 \u0026ndash;download-handlers option. Otherwise the resource as returned by the access method is stored.\nIf the verification store is enabled, resources downloaded from signed or verified component versions are verified against their digests provided by the component version.(not supported for using downloaders for the resource download).\nThe usage of the verification store is enabled by \u0026ndash;use-verified or by specifying a verification file with \u0026ndash;verified.\nSee Also ocm download\t— Download oci artifacts, resources or complete components ","date":"0001-01-01","id":66,"permalink":"/docs/cli-reference/download/cli/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm download cli [\u0026lt;options\u0026gt;] [\u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}]\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -c, --constraints constraints version constraint\n -h, --help help for cli\n -O, --outfile string output file or directory\n -p, --path lookup executable in PATH\n --repo string repository name or spec\n --use-verified enable verification store\n --verified string file used to remember verifications for downloads (default \u0026#34;~/.ocm/verified\u0026#34;)\n --verify verify downloads\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eDownload an OCM CLI executable. By default, the standard publishing component\nand repository is used. Optionally, another component or repo and even a resource\ncan be specified. Resources are specified by identities. An identity consists of\na name argument followed by optional \u003ccode\u003e\u0026lt;key\u0026gt;=\u0026lt;value\u0026gt;\u003c/code\u003e\narguments.\u003c/p\u003e","tags":[],"title":"cli"},{"content":"Options -X, --attribute stringArray attribute setting --ca-cert stringArray additional root certificate authorities (for signing certificates) --config stringArray configuration file --config-set strings apply configuration set -C, --cred stringArray credential setting -h, --help help for ocm -I, --issuer stringArray issuer name or distinguished name (DN) (optionally for dedicated signature) ([\u0026lt;name\u0026gt;:=]\u0026lt;dn\u0026gt;) --logJson log as json instead of human readable logs --logconfig string log config -L, --logfile string set log file --logkeys stringArray log tags/realms(with leading /) to be enabled ([/[+]]name{,[/[+]]name}[=level]) -l, --loglevel string set log level -K, --private-key stringArray private key setting -k, --public-key stringArray public key setting -v, --verbose deprecated: enable logrus verbose logging --version show version\rIntroduction The Open Component Model command line client supports the work with OCM artifacts, like Component Archives, Common Transport Archive, Component Repositories, and Component Versions.\nAdditionally it provides some limited support for the docker daemon, OCI artifacts and registries.\nIt can be used in two ways:\nverb/operation first: here the sub commands follow the pattern \u0026lt;verb\u0026gt; \u0026lt;object kind\u0026gt; \u0026lt;arguments\u0026gt; area/kind first: here the area and/or object kind is given first followed by the operation according to the pattern [\u0026lt;area\u0026gt;] \u0026lt;object kind\u0026gt; \u0026lt;verb/operation\u0026gt; \u0026lt;arguments\u0026gt; The command accepts some top level options, they can only be given before the sub commands.\nA configuration according to ocm configfile is read from a .ocmconfig file located in the HOME directory. With the option \u0026ndash;config other file locations can be specified. If nothing is specified and no file is found at the default location a default configuration is composed according to known type specific configuration files.\nThe following configuration sources are used:\nThe docker configuration file at ~/.docker/config.json is read to feed in the configured credentials for OCI registries.\nThe npm configuration file at ~/.npmrc is read to feed in the configured credentials for NPM registries.\nWith the option \u0026ndash;cred it is possible to specify arbitrary credentials for various environments on the command line. Nevertheless it is always preferable to use the cli config file. Every credential setting is related to a dedicated consumer and provides a set of credential attributes. All this can be specified by a sequence of \u0026ndash;cred options.\nEvery option value has the format\n--cred [:]\u0026lt;attr\u003e=\u0026lt;value\u003e Consumer identity attributes are prefixed with the colon \u0026lsquo;:\u0026rsquo;. A credential settings always start with a sequence of at least one identity attributes, followed by a sequence of credential attributes. If a credential attribute is followed by an identity attribute a new credential setting is started.\nThe first credential setting may omit identity attributes. In this case it is used as default credential, always used if no dedicated match is found.\nFor example:\n--cred :type=OCIRegistry --cred :hostname=ghcr.io --cred username=mandelsoft --cred password=xyz With the option -X it is possible to pass global settings of the form\n-X \u0026lt;attribute\u003e=\u0026lt;value\u003e The \u0026ndash;log* options can be used to configure the logging behaviour. For details see ocm logging.\nThere is a quick config option \u0026ndash;logkeys to configure simple tag/realm based condition rules. The comma-separated names build an AND rule. Hereby, names starting with a slash (/) denote a realm (without the leading slash). A realm is a slash separated sequence of identifiers. If the realm name starts with a plus (+) character the generated rule will match the realm and all its sub-realms, otherwise, only the dedicated realm is affected. For example /+ocm=trace will enable all log output of the OCM library.\nA tag directly matches the logging tags. Used tags and realms can be found under topic ocm logging. The ocm coding basically uses the realm ocm. The default level to enable is info. Separated by an equal sign (=) optionally a dedicated level can be specified. Log levels can be (error, warn, info, debug and trace. The default level is warn. The \u0026ndash;logconfig* options can be used to configure a complete logging configuration (yaml/json) via command line. If the argument starts with an @, the logging configuration is taken from a file.\nThe value can be a simple type or a JSON/YAML string for complex values (see ocm attributes). The following attributes are supported:\ngithub.com/mandelsoft/logforward [logfwd]: logconfig Logging config structure used for config forwarding\nThis attribute is used to specify a logging configuration intended to be forwarded to other tools. (For example: TOI passes this config to the executor)\ngithub.com/mandelsoft/oci/cache [cache]: string\nFilesystem folder to use for caching OCI blobs\ngithub.com/mandelsoft/ocm/compat [compat]: bool\nCompatibility mode: Avoid generic local access methods and prefer type specific ones.\ngithub.com/mandelsoft/ocm/hasher: JSON\nPreferred hash algorithm to calculate resource digests. The following digesters are supported:\nNO-DIGEST SHA-256 (default) SHA-512 github.com/mandelsoft/ocm/keeplocalblob [keeplocalblob]: bool\nKeep local blobs when importing OCI artifacts to OCI registries from localBlob access methods. By default, they will be expanded to OCI artifacts with the access method ociRegistry. If this option is set to true, they will be stored as local blobs, also. The access method will still be localBlob but with a nested ociRegistry access method for describing the global access.\ngithub.com/mandelsoft/ocm/mapocirepo [mapocirepo]: bool|YAML\nWhen uploading an OCI artifact blob to an OCI based OCM repository and the artifact is uploaded as OCI artifact, the repository path part is shortened, either by hashing all but the last repository name part or by executing some prefix based name mappings.\nIf a boolean is given the short hash or none mode is enabled. The YAML flavor uses the following fields:\nmode string: hash, shortHash, prefixMapping or none. If unset, no mapping is done. prefixMappings: map[string]string repository path prefix mapping. prefix: string repository prefix to use (replaces potential sub path of OCM repo). or none. prefixMapping: map[string]string repository path prefix mapping. Notes:\nThe mapping only occurs in transfer commands and only when transferring to OCI registries (e.g. when transferring to a CTF archive this option will be ignored). The mapping in mode prefixMapping requires a full prefix of the composed final name. Partial matches are not supported. The host name of the target will be skipped. The artifact name of the component-descriptor is not mapped. If the mapping is provided on the command line it must be JSON format and needs to be properly escaped (see example below). Example:\nAssume a component named github.com/my_org/myexamplewithalongname and a chart name echo in the Charts.yaml of the chart archive. The following input to a resource.yaml creates a component version:\nname: mychart type: helmChart input: type: helm path: charts/mychart.tgz --- name: myimage type: ociImage version: 0.1.0 input: type: ociImage repository: ocm/ocm.software/ocmcli/ocmcli-image path: ghcr.io/acme/ocm/ocm.software/ocmcli/ocmcli-image:0.1.0 The following command:\nocm \"-X mapocirepo={\\\"mode\\\":\\\"mapping\\\",\\\"prefixMappings\\\":{\\\"acme/github.com/my_org/myexamplewithalongname/ocm/ocm.software/ocmcli\\\":\\\"acme/cli\\\", \\\"acme/github.com/my_org/myexamplewithalongnameabc123\\\":\\\"acme/mychart\\\"}}\" transfer ctf -f --copy-resources ./ctf ghcr.io/acme will result in the following artifacts in ghcr.io/my_org:\nmychart/echo cli/ocmcli-image Note that the host name part of the transfer target ghcr.io/acme is excluded from the prefix but the path acme is considered.\nThe same using a config file .ocmconfig:\ntype: generic.config.ocm.software/v1 configurations: ... - type: attributes.config.ocm.software attributes: ... mapocirepo: mode: mapping prefixMappings: acme/github.com/my\\_org/myexamplewithalongname/ocm/ocm.software/ocmcli: acme/cli acme/github.com/my\\_org/myexamplewithalongnameabc123: acme/mychart ocm transfer ca -f --copy-resources ./ca ghcr.io/acme github.com/mandelsoft/ocm/ociuploadrepo [ociuploadrepo]: oci base repository ref\nUpload local OCI artifact blobs to a dedicated repository.\ngithub.com/mandelsoft/ocm/plugindir [plugindir]: plugin directory\nDirectory to look for OCM plugin executables.\ngithub.com/mandelsoft/ocm/rootcerts [rootcerts]: JSON\nGeneral root certificate settings given as JSON document with the following format:\n{ \"rootCertificates\": [ { \"data\": \"\"\u0026lt;base64\u003e\" }, { \"path\": \"\"\u0026lt;file path\u003e\" } ] } One of following data fields are possible:\ndata: base64 encoded binary data stringdata: plain text data path: a file path to read the data from github.com/mandelsoft/ocm/signing: JSON\nPublic and private Key settings given as JSON document with the following format:\n{ \"publicKeys\": [ \"\u0026lt;provider\u003e\": { \"data\": \"\"\u0026lt;base64\u003e\" } ], \"privateKeys\"\": [ \"\u0026lt;provider\u003e\": { \"path\": \"\"\u0026lt;file path\u003e\" } ] } One of following data fields are possible:\ndata: base64 encoded binary data stringdata: plain text data path: a file path to read the data from github.com/mandelsoft/tempblobcache [blobcache]: string Foldername for temporary blob cache\nThe temporary blob cache is used to accessing large blobs from remote systems. The are temporarily stored in the filesystem, instead of the memory, to avoid blowing up the memory consumption.\nocm.software/cliconfig [cliconfig]: cliconfig Configuration Object passed to command line plugin.\nocm.software/compositionmode [compositionmode]: bool (default: false)\nComposition mode decouples a component version provided by a repository implementation from the backend persistence. Added local blobs will and other changes will not be forwarded to the backend repository until an AddVersion is called on the component. If composition mode is disabled blobs will directly be forwarded to the backend and descriptor updated will be persisted on AddVersion or closing a provided existing component version.\nocm.software/signing/sigstore [sigstore]: sigstore config Configuration to use for sigstore based signing.\nThe following fields are used.\nfulcioURL string default is https://fulcio.sigstore.dev rekorURL string default is https://rekor.sigstore.dev OIDCIssuer string default is https://oauth2.sigstore.dev/auth OIDCClientID string default is sigstore For several options (like -X) it is possible to pass complex values using JSON or YAML syntax. To pass those arguments the escaping of the used shell must be used to pass quotes, commas, curly brackets or newlines. for the bash the easiest way to achieve this is to put the complete value into single quotes.\n-X 'mapocirepo={\"mode\": \"shortHash\"}'. Alternatively, quotes and opening curly brackets can be escaped by using a backslash (\\). Often a tagged value can also be substituted from a file with the syntax\n\u0026lt;attr\u003e=@\u0026lt;filepath\u003e The \u0026ndash;public-key and \u0026ndash;private-key options can be used to define public and private keys on the command line. The options have an argument of the form \u0026lt;name\u0026gt;=\u0026lt;filepath\u0026gt;. The name is the name of the key and represents the context is used for (For example the signature name of a component version)\nAlternatively a key can be specified as base64 encoded string if the argument start with the prefix ! or as direct string with the prefix =.\nWith \u0026ndash;issuer it is possible to declare expected issuer constraints for public key certificates provided as part of a signature required to accept the provisioned public key (besides the successful validation of the certificate). By default, the issuer constraint is derived from the signature name. If it is not a formal distinguished name, it is assumed to be a plain common name.\nWith \u0026ndash;ca-cert it is possible to define additional root certificates for signature verification, if public keys are provided by a certificate delivered with the signature.\nSee Also Sub Commands ocm add\t— Add elements to a component repository or component version ocm check\t— check components in OCM repository ocm clean\t— Cleanup/re-organize elements ocm create\t— Create transport or component archive ocm describe\t— Describe various elements by using appropriate sub commands. ocm download\t— Download oci artifacts, resources or complete components ocm get\t— Get information about artifacts and components ocm list\t— List information about components ocm set\t— Set information about OCM repositories ocm show\t— Show tags or versions ocm sign\t— Sign components or hashes ocm transfer\t— Transfer artifacts or components ocm verify\t— Verify component version signatures Additional Help Topics ocm attributes\t— configuration attributes used to control the behaviour ocm configfile\t— configuration file ocm credential-handling\t— Provisioning of credentials for credential consumers ocm logging\t— Configured logging keys ocm oci-references\t— notation for OCI references ocm ocm-accessmethods\t— List of all supported access methods ocm ocm-downloadhandlers\t— List of all available download handlers ocm ocm-labels\t— Labels and Label Merging ocm ocm-pubsub\t— List of all supported publish/subscribe implementations ocm ocm-references\t— notation for OCM references ocm ocm-uploadhandlers\t— List of all available upload handlers ocm toi-bootstrapping\t— Tiny OCM Installer based on component versions ","date":"0001-01-01","id":67,"permalink":"/docs/cli-reference/","summary":"\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -X, --attribute stringArray attribute setting\n --ca-cert stringArray additional root certificate authorities (for signing certificates)\n --config stringArray configuration file\n --config-set strings apply configuration set\n -C, --cred stringArray credential setting\n -h, --help help for ocm\n -I, --issuer stringArray issuer name or distinguished name (DN) (optionally for dedicated signature) ([\u0026lt;name\u0026gt;:=]\u0026lt;dn\u0026gt;)\n --logJson log as json instead of human readable logs\n --logconfig string log config\n -L, --logfile string set log file\n --logkeys stringArray log tags/realms(with leading /) to be enabled ([/[+]]name{,[/[+]]name}[=level])\n -l, --loglevel string set log level\n -K, --private-key stringArray private key setting\n -k, --public-key stringArray public key setting\n -v, --verbose deprecated: enable logrus verbose logging\n --version show version\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"introduction\"\u003eIntroduction\u003c/h3\u003e\n\u003cp\u003eThe Open Component Model command line client supports the work with OCM\nartifacts, like Component Archives, Common Transport Archive,\nComponent Repositories, and Component Versions.\u003c/p\u003e","tags":[],"title":"cli-reference"},{"content":"Usage ocm transfer commontransportarchive [\u0026lt;options\u0026gt;] \u0026lt;ctf\u0026gt; \u0026lt;target\u0026gt;\rOptions -L, --copy-local-resources transfer referenced local resources by-value -V, --copy-resources transfer referenced resources by-value --copy-sources transfer referenced sources by-value --enforce enforce transport as if target version were not present -h, --help help for commontransportarchive --lookup stringArray repository name or spec for closure lookup fallback --no-update don\u0026#39;t touch existing versions in target -N, --omit-access-types strings omit by-value transfer for resource types -f, --overwrite overwrite existing component versions -r, --recursive follow component reference nesting --script string config name of transfer handler script -s, --scriptFile string filename of transfer handler script -E, --stop-on-existing stop on existing component version in target repository -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;) --uploader \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; repository uploader (\u0026lt;name\u0026gt;[:\u0026lt;artifact type\u0026gt;[:\u0026lt;media type\u0026gt;[:\u0026lt;priority\u0026gt;]]]=\u0026lt;JSON target config\u0026gt;) (default [])\rDescription Transfer content of a Common Transport Archive to the given target repository.\nWith the option \u0026ndash;recursive the complete reference tree of a component reference is traversed.\nWith the option \u0026ndash;no-update existing versions in the target repository will not be touched at all. An additional specification of the option \u0026ndash;overwrite is ignored. By default, updates of volatile (non-signature-relevant) information is enabled, but the modification of non-volatile data is prohibited unless the overwrite option is given.\nIf the option \u0026ndash;overwrite is given, component versions in the target repository will be overwritten, if they already exist, but with different digest. If the option \u0026ndash;enforce is given, component versions in the target repository will be transported as if they were not present on the target side, regardless of their state (this is independent on their actual state, even identical versions are re-transported).\nIf a component lookup for building a reference closure is required the \u0026ndash;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.\nThe \u0026ndash;type option accepts a file format for the target archive to use. It is only evaluated if the target archive does not exist yet. The following formats are supported:\ndirectory tar tgz The default format is directory.\nIf the option \u0026ndash;copy-resources is given, all referential resources will potentially be localized, mapped to component version local resources in the target repository. If the option \u0026ndash;copy-local-resources is given, instead, only resources with the relation local will be transferred. This behaviour can be further influenced by specifying a transfer script with the script option family.\nIf the option \u0026ndash;copy-sources is given, all referential sources 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.\nIf the option \u0026ndash;omit-access-types is given, by-value transfer is omitted completely for the given resource types.\nIf the option \u0026ndash;stop-on-existing is given together with the \u0026ndash;recursive option, the recursion is stopped for component versions already existing in the target repository. This behaviour can be further influenced by specifying a transfer script with the script option family.\nIf the \u0026ndash;uploader option is specified, appropriate uploader handlers are configured for the operation. It has the following format\n\u0026lt;name\u003e:\u0026lt;artifact type\u003e:\u0026lt;media type\u003e=\u0026lt;yaml target config\u003e The uploader name may be a path expression with the following possibilities:\nocm/mavenPackage: uploading maven artifacts\nThe ocm/mavenPackage uploader is able to upload maven artifacts (whole GAV only!) as artifact archive according to the maven artifact spec. If registered the default mime type is: application/x-tgz\nIt accepts a plain string for the URL or a config with the following field: \u0026lsquo;url\u0026rsquo;: the URL of the maven repository.\nocm/npmPackage: uploading npm artifacts\nThe ocm/npmPackage uploader is able to upload npm artifacts as artifact archive according to the npm package spec. If registered the default mime type is: application/x-tgz\nIt accepts a plain string for the URL or a config with the following field: \u0026lsquo;url\u0026rsquo;: the URL of the npm repository.\nocm/ociArtifacts: downloading OCI artifacts\nThe ociArtifacts downloader is able to download OCI artifacts as artifact archive according to the OCI distribution spec. The following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar application/vnd.oci.image.manifest.v1+tar+gzip application/vnd.oci.image.index.v1+tar application/vnd.oci.image.index.v1+tar+gzip application/vnd.docker.distribution.manifest.v2+tar application/vnd.docker.distribution.manifest.v2+tar+gzip application/vnd.docker.distribution.manifest.list.v2+tar application/vnd.docker.distribution.manifest.list.v2+tar+gzip By default, it is registered for these mimetypes.\nIt accepts a config with the following fields:\nnamespacePrefix: a namespace prefix used for the uploaded artifacts ociRef: an OCI repository reference repository: an OCI repository specification for the target OCI registry Alternatively, a single string value can be given representing an OCI repository reference.\nplugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\nSee ocm ocm-uploadhandlers for further details on using upload handlers.\nIt is possible to use a dedicated transfer script based on spiff. The option \u0026ndash;scriptFile can be used to specify this script by a file name. With \u0026ndash;script it can be taken from the CLI config using an entry of the following format:\ntype: scripts.ocm.config.ocm.software scripts: \u0026lt;name\u003e: path: \u0026lt;filepath\u003e script: \u0026lt;scriptdata\u003e Only one of the fields path or script can be used.\nIf no script option is given and the cli config defines a script default this one is used.\nExamples $ ocm transfer ctf ctf.tgz ghcr.io/mandelsoft/components\rSee Also ocm transfer\t— Transfer artifacts or components ","date":"0001-01-01","id":68,"permalink":"/docs/cli-reference/transfer/commontransportarchive/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm transfer commontransportarchive [\u0026lt;options\u0026gt;] \u0026lt;ctf\u0026gt; \u0026lt;target\u0026gt;\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -L, --copy-local-resources transfer referenced local resources by-value\n -V, --copy-resources transfer referenced resources by-value\n --copy-sources transfer referenced sources by-value\n --enforce enforce transport as if target version were not present\n -h, --help help for commontransportarchive\n --lookup stringArray repository name or spec for closure lookup fallback\n --no-update don\u0026#39;t touch existing versions in target\n -N, --omit-access-types strings omit by-value transfer for resource types\n -f, --overwrite overwrite existing component versions\n -r, --recursive follow component reference nesting\n --script string config name of transfer handler script\n -s, --scriptFile string filename of transfer handler script\n -E, --stop-on-existing stop on existing component version in target repository\n -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\n --uploader \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; repository uploader (\u0026lt;name\u0026gt;[:\u0026lt;artifact type\u0026gt;[:\u0026lt;media type\u0026gt;[:\u0026lt;priority\u0026gt;]]]=\u0026lt;JSON target config\u0026gt;) (default [])\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eTransfer content of a Common Transport Archive to the given target repository.\u003c/p\u003e","tags":[],"title":"commontransportarchive"},{"content":"Usage ocm create componentarchive [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; \u0026lt;version\u0026gt; --provider \u0026lt;provider-name\u0026gt; {--provider \u0026lt;label\u0026gt;=\u0026lt;value\u0026gt;} {\u0026lt;label\u0026gt;=\u0026lt;value\u0026gt;}\rOptions -F, --file string target file/directory (default \u0026#34;component-archive\u0026#34;) -f, --force remove existing content -h, --help help for componentarchive -p, --provider stringArray provider attribute -S, --scheme string schema version (default \u0026#34;v2\u0026#34;) -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\rDescription Create a new component archive. This might be either a directory prepared to host component version content or a tar/tgz file (see option \u0026ndash;type).\nA provider must be specified, additional provider labels are optional.\nThe \u0026ndash;type option accepts a file format for the target archive to use. It is only evaluated if the target archive does not exist yet. The following formats are supported:\ndirectory tar tgz The default format is directory.\nIf the option \u0026ndash;scheme is given, the specified component descriptor format is used/generated.\nThe following schema versions are supported for explicit conversions:\nocm.software/v3alpha1 v2 (default) Examples $ ocm create componentarchive --file myfirst --provider acme.org --provider email=alice@acme.org acme.org/demo 1.0\rSee Also ocm create\t— Create transport or component archive ","date":"0001-01-01","id":69,"permalink":"/docs/cli-reference/create/componentarchive/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm create componentarchive [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; \u0026lt;version\u0026gt; --provider \u0026lt;provider-name\u0026gt; {--provider \u0026lt;label\u0026gt;=\u0026lt;value\u0026gt;} {\u0026lt;label\u0026gt;=\u0026lt;value\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -F, --file string target file/directory (default \u0026#34;component-archive\u0026#34;)\n -f, --force remove existing content\n -h, --help help for componentarchive\n -p, --provider stringArray provider attribute\n -S, --scheme string schema version (default \u0026#34;v2\u0026#34;)\n -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eCreate a new component archive. This might be either a directory prepared\nto host component version content or a tar/tgz file (see option \u0026ndash;type).\u003c/p\u003e","tags":[],"title":"componentarchive"},{"content":"Usage ocm transfer componentarchive [\u0026lt;options\u0026gt;] \u0026lt;source\u0026gt; \u0026lt;target\u0026gt;\rOptions -L, --copy-local-resources transfer referenced local resources by-value -V, --copy-resources transfer referenced resources by-value --copy-sources transfer referenced sources by-value --enforce enforce transport as if target version were not present -h, --help help for componentarchive --lookup stringArray repository name or spec for closure lookup fallback --no-update don\u0026#39;t touch existing versions in target -f, --overwrite overwrite existing component versions -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\rDescription Transfer a component archive to some component repository. This might be a CTF Archive or a regular repository. If the type CTF is specified the target must already exist, if CTF flavor is specified it will be created if it does not exist.\nBesides those explicitly known types a complete repository spec might be configured, either via inline argument or command configuration file and name.\nThe \u0026ndash;type option accepts a file format for the target archive to use. It is only evaluated if the target archive does not exist yet. The following formats are supported:\ndirectory tar tgz The default format is directory.\nIf a component lookup for building a reference closure is required the \u0026ndash;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.\nWith the option \u0026ndash;no-update existing versions in the target repository will not be touched at all. An additional specification of the option \u0026ndash;overwrite is ignored. By default, updates of volatile (non-signature-relevant) information is enabled, but the modification of non-volatile data is prohibited unless the overwrite option is given.\nIf the option \u0026ndash;overwrite is given, component versions in the target repository will be overwritten, if they already exist, but with different digest. If the option \u0026ndash;enforce is given, component versions in the target repository will be transported as if they were not present on the target side, regardless of their state (this is independent on their actual state, even identical versions are re-transported).\nIf the option \u0026ndash;copy-resources is given, all referential resources will potentially be localized, mapped to component version local resources in the target repository. If the option \u0026ndash;copy-local-resources is given, instead, only resources with the relation local will be transferred. This behaviour can be further influenced by specifying a transfer script with the script option family.\nIf the option \u0026ndash;copy-sources is given, all referential sources 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.\nSee Also ocm transfer\t— Transfer artifacts or components ","date":"0001-01-01","id":70,"permalink":"/docs/cli-reference/transfer/componentarchive/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm transfer componentarchive [\u0026lt;options\u0026gt;] \u0026lt;source\u0026gt; \u0026lt;target\u0026gt;\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -L, --copy-local-resources transfer referenced local resources by-value\n -V, --copy-resources transfer referenced resources by-value\n --copy-sources transfer referenced sources by-value\n --enforce enforce transport as if target version were not present\n -h, --help help for componentarchive\n --lookup stringArray repository name or spec for closure lookup fallback\n --no-update don\u0026#39;t touch existing versions in target\n -f, --overwrite overwrite existing component versions\n -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eTransfer a component archive to some component repository. This might\nbe a CTF Archive or a regular repository.\nIf the type CTF is specified the target must already exist, if CTF flavor\nis specified it will be created if it does not exist.\u003c/p\u003e","tags":[],"title":"componentarchive"},{"content":"Usage ocm add componentversions [\u0026lt;options\u0026gt;] [--version \u0026lt;version\u0026gt;] [\u0026lt;ctf archive\u0026gt;] {\u0026lt;component-constructor.yaml\u0026gt;}\rOptions --addenv access environment for templating -C, --complete include all referenced component version -L, --copy-local-resources transfer referenced local resources by-value -V, --copy-resources transfer referenced resources by-value -c, --create (re)create archive --dry-run evaluate and print component specifications -F, --file string target file/directory (default \u0026#34;transport-archive\u0026#34;) -f, --force remove existing content -h, --help help for componentversions --lookup stringArray repository name or spec for closure lookup fallback -O, --output string output file for dry-run -P, --preserve-signature preserve existing signatures -R, --replace replace existing elements -S, --scheme string schema version (default \u0026#34;v2\u0026#34;) -s, --settings stringArray settings file with variable settings (yaml) --skip-digest-generation skip digest creation --templater string templater to use (go, none, spiff, subst) (default \u0026#34;subst\u0026#34;) -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;) --uploader \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; repository uploader (\u0026lt;name\u0026gt;[:\u0026lt;artifact type\u0026gt;[:\u0026lt;media type\u0026gt;[:\u0026lt;priority\u0026gt;]]]=\u0026lt;JSON target config\u0026gt;) (default []) -v, --version string default version for components\rDescription Add component versions specified by a constructor file to a Common Transport Archive. The archive might be either a directory prepared to host component version content or a tar/tgz file (see option \u0026ndash;type).\nIf option \u0026ndash;create is given, the archive is created first. An additional option \u0026ndash;force will recreate an empty archive if it already exists.\nIf option \u0026ndash;complete is given all component versions referenced by the added one, will be added, also. Therefore, the \u0026ndash;lookup is required to specify an OCM repository to lookup the missing component versions. If additionally the -V is given, the resources of those additional components will be added by value.\nThe \u0026ndash;replace option allows users to specify whether adding an element with the same name and extra identity but different version as an existing element, append (false) or replace (true) the existing element.\nThe \u0026ndash;preserve-signature option prohibits changes of signature relevant elements.\nThe source, resource and reference list can be composed according to the commands ocm add sources, ocm add resources, ocm add references, respectively.\nThe description file might contain:\na single component as shown in the example a list of components under the key components a list of yaml documents with a single component or component list The optional field meta.configuredSchemaVersion for a component entry can be used to specify a dedicated serialization format to use for the component descriptor. If given it overrides the \u0026ndash;schema option of the command. By default, v2 is used.\nVarious elements support to add arbitrary information by using labels (see ocm ocm-labels).\nThe \u0026ndash;type option accepts a file format for the target archive to use. It is only evaluated if the target archive does not exist yet. The following formats are supported:\ndirectory tar tgz The default format is directory.\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" If a component lookup for building a reference closure is required the \u0026ndash;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.\nIf the option \u0026ndash;copy-resources is given, all referential resources will potentially be localized, mapped to component version local resources in the target repository. If the option \u0026ndash;copy-local-resources is given, instead, only resources with the relation local will be transferred. This behaviour can be further influenced by specifying a transfer script with the script option family.\nIf the \u0026ndash;uploader option is specified, appropriate uploader handlers are configured for the operation. It has the following format\n\u0026lt;name\u003e:\u0026lt;artifact type\u003e:\u0026lt;media type\u003e=\u0026lt;yaml target config\u003e The uploader name may be a path expression with the following possibilities:\nocm/mavenPackage: uploading maven artifacts\nThe ocm/mavenPackage uploader is able to upload maven artifacts (whole GAV only!) as artifact archive according to the maven artifact spec. If registered the default mime type is: application/x-tgz\nIt accepts a plain string for the URL or a config with the following field: \u0026lsquo;url\u0026rsquo;: the URL of the maven repository.\nocm/npmPackage: uploading npm artifacts\nThe ocm/npmPackage uploader is able to upload npm artifacts as artifact archive according to the npm package spec. If registered the default mime type is: application/x-tgz\nIt accepts a plain string for the URL or a config with the following field: \u0026lsquo;url\u0026rsquo;: the URL of the npm repository.\nocm/ociArtifacts: downloading OCI artifacts\nThe ociArtifacts downloader is able to download OCI artifacts as artifact archive according to the OCI distribution spec. The following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar application/vnd.oci.image.manifest.v1+tar+gzip application/vnd.oci.image.index.v1+tar application/vnd.oci.image.index.v1+tar+gzip application/vnd.docker.distribution.manifest.v2+tar application/vnd.docker.distribution.manifest.v2+tar+gzip application/vnd.docker.distribution.manifest.list.v2+tar application/vnd.docker.distribution.manifest.list.v2+tar+gzip By default, it is registered for these mimetypes.\nIt accepts a config with the following fields:\nnamespacePrefix: a namespace prefix used for the uploaded artifacts ociRef: an OCI repository reference repository: an OCI repository specification for the target OCI registry Alternatively, a single string value can be given representing an OCI repository reference.\nplugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\nSee ocm ocm-uploadhandlers for further details on using upload handlers.\nExamples $ ocm add componentversions --file ctf --version 1.0 component-constructor.yaml and a file \u0026lt;code\u0026gt;component-constructor.yaml\u0026lt;/code\u0026gt;: name: ocm.software/demo/test version: 1.0.0 provider: name: ocm.software labels: - name: city value: Karlsruhe labels: - name: purpose value: test resources: - name: text type: PlainText input: type: file path: testdata - name: data type: PlainText input: type: binary data: IXN0cmluZ2RhdGE= The resource \u0026lt;code\u0026gt;text\u0026lt;/code\u0026gt; is taken from a file \u0026lt;code\u0026gt;testdata\u0026lt;/code\u0026gt; located next to the description file.\rSee Also ocm add\t— Add elements to a component repository or component version ","date":"0001-01-01","id":71,"permalink":"/docs/cli-reference/add/componentversions/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm add componentversions [\u0026lt;options\u0026gt;] [--version \u0026lt;version\u0026gt;] [\u0026lt;ctf archive\u0026gt;] {\u0026lt;component-constructor.yaml\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --addenv access environment for templating\n -C, --complete include all referenced component version\n -L, --copy-local-resources transfer referenced local resources by-value\n -V, --copy-resources transfer referenced resources by-value\n -c, --create (re)create archive\n --dry-run evaluate and print component specifications\n -F, --file string target file/directory (default \u0026#34;transport-archive\u0026#34;)\n -f, --force remove existing content\n -h, --help help for componentversions\n --lookup stringArray repository name or spec for closure lookup fallback\n -O, --output string output file for dry-run\n -P, --preserve-signature preserve existing signatures\n -R, --replace replace existing elements\n -S, --scheme string schema version (default \u0026#34;v2\u0026#34;)\n -s, --settings stringArray settings file with variable settings (yaml)\n --skip-digest-generation skip digest creation\n --templater string templater to use (go, none, spiff, subst) (default \u0026#34;subst\u0026#34;)\n -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\n --uploader \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; repository uploader (\u0026lt;name\u0026gt;[:\u0026lt;artifact type\u0026gt;[:\u0026lt;media type\u0026gt;[:\u0026lt;priority\u0026gt;]]]=\u0026lt;JSON target config\u0026gt;) (default [])\n -v, --version string default version for components\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAdd component versions specified by a constructor file to a Common Transport\nArchive. The archive might be either a directory prepared to host component version\ncontent or a tar/tgz file (see option \u0026ndash;type).\u003c/p\u003e","tags":[],"title":"componentversions"},{"content":"Usage ocm check componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\rOptions --fail-on-error fail on validation error -h, --help help for componentversions -R, --local-resources check also for describing resources with local access method, only -S, --local-sources check also for describing sources with local access method, only -o, --output string output mode (JSON, json, wide, yaml) --repo string repository name or spec -s, --sort stringArray sort fields\rDescription This command checks, whether component versions are completely contained in an OCM repository with all its dependent component references.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry If the options \u0026ndash;local-resources and/or \u0026ndash;local-sources are given the check additionally assures that all resources or sources are included into the component version. This means that they are using local access methods, only.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json wide yaml Examples $ ocm check componentversion ghcr.io/open-component-model/ocm//ocm.software/ocmcli:0.17.0 $ ocm check componentversion --repo OCIRegistry::ghcr.io/open-component-model/ocm ocm.software/ocmcli:0.17.0\rSee Also ocm check\t— check components in OCM repository ","date":"0001-01-01","id":72,"permalink":"/docs/cli-reference/check/componentversions/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm check componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --fail-on-error fail on validation error\n -h, --help help for componentversions\n -R, --local-resources check also for describing resources with local access method, only\n -S, --local-sources check also for describing sources with local access method, only\n -o, --output string output mode (JSON, json, wide, yaml)\n --repo string repository name or spec\n -s, --sort stringArray sort fields\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eThis command checks, whether component versions are completely contained\nin an OCM repository with all its dependent component references.\u003c/p\u003e","tags":[],"title":"componentversions"},{"content":"Usage ocm download componentversions [\u0026lt;options\u0026gt;] {\u0026lt;components\u0026gt;} Options -h, --help help for componentversions -O, --outfile string output file or directory --repo string repository name or spec -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\rDescription Download component versions from an OCM repository. The result is stored in component archives.\nThe files are named according to the component version name.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry The \u0026ndash;type option accepts a file format for the target archive to use. It is only evaluated if the target archive does not exist yet. The following formats are supported:\ndirectory tar tgz The default format is directory.\nSee Also ocm download\t— Download oci artifacts, resources or complete components ","date":"0001-01-01","id":73,"permalink":"/docs/cli-reference/download/componentversions/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm download componentversions [\u0026lt;options\u0026gt;] {\u0026lt;components\u0026gt;} \u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for componentversions\n -O, --outfile string output file or directory\n --repo string repository name or spec\n -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eDownload component versions from an OCM repository. The result is stored in\ncomponent archives.\u003c/p\u003e","tags":[],"title":"componentversions"},{"content":"Usage ocm get componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\rOptions -c, --constraints constraints version constraint -h, --help help for componentversions --latest restrict component versions to latest --lookup stringArray repository name or spec for closure lookup fallback -o, --output string output mode (JSON, json, tree, wide, yaml) -r, --recursive follow component reference nesting --repo string repository name or spec -S, --scheme string schema version -s, --sort stringArray sort fields\rDescription Get lists all component versions specified, if only a component is specified all versions are listed.\nIf the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry With the option \u0026ndash;recursive the complete reference tree of a component reference is traversed.\nIf a component lookup for building a reference closure is required the \u0026ndash;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.\nIf the option \u0026ndash;scheme is given, the component descriptor is converted to the specified format for output. If no format is given the storage format of the actual descriptor is used or, for new ones v2 is used. With internal the internal representation is shown. The following schema versions are supported for explicit conversions:\nocm.software/v3alpha1 v2 With the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json tree wide yaml Examples $ ocm get componentversion ghcr.io/open-component-model/ocm//ocm.software/ocmcli:0.17.0 $ ocm get componentversion --repo OCIRegistry::ghcr.io/open-component-model/ocm ocm.software/ocmcli:0.17.0\rSee Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":74,"permalink":"/docs/cli-reference/get/componentversions/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -c, --constraints constraints version constraint\n -h, --help help for componentversions\n --latest restrict component versions to latest\n --lookup stringArray repository name or spec for closure lookup fallback\n -o, --output string output mode (JSON, json, tree, wide, yaml)\n -r, --recursive follow component reference nesting\n --repo string repository name or spec\n -S, --scheme string schema version\n -s, --sort stringArray sort fields\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eGet lists all component versions specified, if only a component is specified\nall versions are listed.\u003c/p\u003e","tags":[],"title":"componentversions"},{"content":"Usage ocm list componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\rOptions -c, --constraints constraints version constraint -h, --help help for componentversions --latest restrict component versions to latest --lookup stringArray repository name or spec for closure lookup fallback -o, --output string output mode (JSON, json, yaml) --repo string repository name or spec -S, --scheme string schema version -s, --sort stringArray sort fields\rDescription List lists the version names of the specified objects, if only a component is specified all versions according to the given version constraints are listed.\nIf the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry If a component lookup for building a reference closure is required the \u0026ndash;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.\nIf the option \u0026ndash;scheme is given, the component descriptor is converted to the specified format for output. If no format is given the storage format of the actual descriptor is used or, for new ones v2 is used. With internal the internal representation is shown. The following schema versions are supported for explicit conversions:\nocm.software/v3alpha1 v2 With the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json yaml Examples $ ocm list componentversion ghcr.io/open-component-model/ocm//ocm.software/ocmcli $ ocm list componentversion --repo OCIRegistry::ghcr.io/open-component-model/ocm ocm.software/ocmcli\rSee Also ocm list\t— List information about components ","date":"0001-01-01","id":75,"permalink":"/docs/cli-reference/list/componentversions/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm list componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -c, --constraints constraints version constraint\n -h, --help help for componentversions\n --latest restrict component versions to latest\n --lookup stringArray repository name or spec for closure lookup fallback\n -o, --output string output mode (JSON, json, yaml)\n --repo string repository name or spec\n -S, --scheme string schema version\n -s, --sort stringArray sort fields\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eList lists the version names of the specified objects, if only a component is specified\nall versions according to the given version constraints are listed.\u003c/p\u003e","tags":[],"title":"componentversions"},{"content":"Usage ocm sign componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\rOptions -- enable verification store -S, --algorithm string signature handler (default \u0026#34;RSASSA-PKCS1-V1_5\u0026#34;) --ca-cert stringArray additional root certificate authorities (for signing certificates) -c, --constraints constraints version constraint -H, --hash string hash algorithm (default \u0026#34;SHA-256\u0026#34;) -h, --help help for componentversions -I, --issuer stringArray issuer name or distinguished name (DN) (optionally for dedicated signature) ([\u0026lt;name\u0026gt;:=]\u0026lt;dn\u0026gt;) --keyless use keyless signing --latest restrict component versions to latest --lookup stringArray repository name or spec for closure lookup fallback -N, --normalization string normalization algorithm (default \u0026#34;jsonNormalisation/v1\u0026#34;) -K, --private-key stringArray private key setting -k, --public-key stringArray public key setting -R, --recursive recursively sign component versions --repo string repository name or spec -s, --signature stringArray signature name --tsa use timestamp authority (default server: http://timestamp.digicert.com) --tsa-url string TSA server URL --update update digest in component versions (default true) --verified string file used to remember verifications for downloads (default \u0026#34;~/.ocm/verified\u0026#34;) -V, --verify verify existing digests (default true)\rDescription Sign specified component versions.\nIf the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry The \u0026ndash;public-key and \u0026ndash;private-key options can be used to define public and private keys on the command line. The options have an argument of the form [\u0026lt;name\u0026gt;=]\u0026lt;filepath\u0026gt;. The optional name specifies the signature name the key should be used for. By default, this is the signature name specified with the option \u0026ndash;signature.\nAlternatively a key can be specified as base64 encoded string if the argument start with the prefix ! or as direct string with the prefix =.\nIf the verification store is enabled, resources downloaded from signed or verified component versions are verified against their digests provided by the component version.(not supported for using downloaders for the resource download).\nThe usage of the verification store is enabled by \u0026ndash; or by specifying a verification file with \u0026ndash;verified.\nIf in signing mode a public key is specified, existing signatures for the given signature name will be verified, instead of recreated.\nThe following signing types are supported with option \u0026ndash;algorithm:\nRSASSA-PKCS1-V1_5 (default) RSASSA-PSS rsa-signingservice rsapss-signingservice sigstore The following normalization modes are supported with option \u0026ndash;normalization:\njsonNormalisation/v1 (default) jsonNormalisation/v2 The following hash modes are supported with option \u0026ndash;hash:\nNO-DIGEST SHA-256 (default) SHA-512 If a component lookup for building a reference closure is required the \u0026ndash;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.\nExamples $ ocm sign componentversion --signature mysignature --private-key=my.key ghcr.io/open-component-model/ocm//ocm.software/ocmcli:0.17.0\rSee Also ocm sign\t— Sign components or hashes ","date":"0001-01-01","id":76,"permalink":"/docs/cli-reference/sign/componentversions/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm sign componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -- enable verification store\n -S, --algorithm string signature handler (default \u0026#34;RSASSA-PKCS1-V1_5\u0026#34;)\n --ca-cert stringArray additional root certificate authorities (for signing certificates)\n -c, --constraints constraints version constraint\n -H, --hash string hash algorithm (default \u0026#34;SHA-256\u0026#34;)\n -h, --help help for componentversions\n -I, --issuer stringArray issuer name or distinguished name (DN) (optionally for dedicated signature) ([\u0026lt;name\u0026gt;:=]\u0026lt;dn\u0026gt;)\n --keyless use keyless signing\n --latest restrict component versions to latest\n --lookup stringArray repository name or spec for closure lookup fallback\n -N, --normalization string normalization algorithm (default \u0026#34;jsonNormalisation/v1\u0026#34;)\n -K, --private-key stringArray private key setting\n -k, --public-key stringArray public key setting\n -R, --recursive recursively sign component versions\n --repo string repository name or spec\n -s, --signature stringArray signature name\n --tsa use timestamp authority (default server: http://timestamp.digicert.com)\n --tsa-url string TSA server URL\n --update update digest in component versions (default true)\n --verified string file used to remember verifications for downloads (default \u0026#34;~/.ocm/verified\u0026#34;)\n -V, --verify verify existing digests (default true)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eSign specified component versions.\u003c/p\u003e","tags":[],"title":"componentversions"},{"content":"Usage ocm transfer componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;} \u0026lt;target\u0026gt;\rOptions -B, --bom-file string file name to write the component version BOM -c, --constraints constraints version constraint -L, --copy-local-resources transfer referenced local resources by-value -V, --copy-resources transfer referenced resources by-value --copy-sources transfer referenced sources by-value --disable-uploads disable standard upload handlers for transport --enforce enforce transport as if target version were not present -h, --help help for componentversions --latest restrict component versions to latest --lookup stringArray repository name or spec for closure lookup fallback --no-update don\u0026#39;t touch existing versions in target -N, --omit-access-types strings omit by-value transfer for resource types -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 -E, --stop-on-existing stop on existing component version in target repository -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;) --uploader \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; repository uploader (\u0026lt;name\u0026gt;[:\u0026lt;artifact type\u0026gt;[:\u0026lt;media type\u0026gt;[:\u0026lt;priority\u0026gt;]]]=\u0026lt;JSON target config\u0026gt;) (default [])\rDescription 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.\nIf the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry The \u0026ndash;type option accepts a file format for the target archive to use. It is only evaluated if the target archive does not exist yet. The following formats are supported:\ndirectory tar tgz The default format is directory.\nWith the option \u0026ndash;recursive the complete reference tree of a component reference is traversed.\nIf a component lookup for building a reference closure is required the \u0026ndash;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.\nIf the option \u0026ndash;overwrite is given, component versions in the target repository will be overwritten, if they already exist, but with different digest. If the option \u0026ndash;enforce is given, component versions in the target repository will be transported as if they were not present on the target side, regardless of their state (this is independent on their actual state, even identical versions are re-transported).\nWith the option \u0026ndash;no-update existing versions in the target repository will not be touched at all. An additional specification of the option \u0026ndash;overwrite is ignored. By default, updates of volatile (non-signature-relevant) information is enabled, but the modification of non-volatile data is prohibited unless the overwrite option is given.\nIf the option \u0026ndash;copy-resources is given, all referential resources will potentially be localized, mapped to component version local resources in the target repository. If the option \u0026ndash;copy-local-resources is given, instead, only resources with the relation local will be transferred. This behaviour can be further influenced by specifying a transfer script with the script option family.\nIf the option \u0026ndash;copy-sources is given, all referential sources 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.\nIf the option \u0026ndash;omit-access-types is given, by-value transfer is omitted completely for the given resource types.\nIf the option \u0026ndash;stop-on-existing is given together with the \u0026ndash;recursive option, the recursion is stopped for component versions already existing in the target repository. This behaviour can be further influenced by specifying a transfer script with the script option family.\nIf the \u0026ndash;uploader option is specified, appropriate uploader handlers are configured for the operation. It has the following format\n\u0026lt;name\u003e:\u0026lt;artifact type\u003e:\u0026lt;media type\u003e=\u0026lt;yaml target config\u003e The uploader name may be a path expression with the following possibilities:\nocm/mavenPackage: uploading maven artifacts\nThe ocm/mavenPackage uploader is able to upload maven artifacts (whole GAV only!) as artifact archive according to the maven artifact spec. If registered the default mime type is: application/x-tgz\nIt accepts a plain string for the URL or a config with the following field: \u0026lsquo;url\u0026rsquo;: the URL of the maven repository.\nocm/npmPackage: uploading npm artifacts\nThe ocm/npmPackage uploader is able to upload npm artifacts as artifact archive according to the npm package spec. If registered the default mime type is: application/x-tgz\nIt accepts a plain string for the URL or a config with the following field: \u0026lsquo;url\u0026rsquo;: the URL of the npm repository.\nocm/ociArtifacts: downloading OCI artifacts\nThe ociArtifacts downloader is able to download OCI artifacts as artifact archive according to the OCI distribution spec. The following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar application/vnd.oci.image.manifest.v1+tar+gzip application/vnd.oci.image.index.v1+tar application/vnd.oci.image.index.v1+tar+gzip application/vnd.docker.distribution.manifest.v2+tar application/vnd.docker.distribution.manifest.v2+tar+gzip application/vnd.docker.distribution.manifest.list.v2+tar application/vnd.docker.distribution.manifest.list.v2+tar+gzip By default, it is registered for these mimetypes.\nIt accepts a config with the following fields:\nnamespacePrefix: a namespace prefix used for the uploaded artifacts ociRef: an OCI repository reference repository: an OCI repository specification for the target OCI registry Alternatively, a single string value can be given representing an OCI repository reference.\nplugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\nSee ocm ocm-uploadhandlers for further details on using upload handlers.\nIt is possible to use a dedicated transfer script based on spiff. The option \u0026ndash;scriptFile can be used to specify this script by a file name. With \u0026ndash;script it can be taken from the CLI config using an entry of the following format:\ntype: scripts.ocm.config.ocm.software scripts: \u0026lt;name\u003e: path: \u0026lt;filepath\u003e script: \u0026lt;scriptdata\u003e Only one of the fields path or script can be used.\nIf no script option is given and the cli config defines a script default this one is used.\nExamples $ ocm transfer components -t tgz ghcr.io/open-component-model/ocm//ocm.software/ocmcli:0.17.0 ./ctf.tgz $ ocm transfer components --latest -t tgz --repo OCIRegistry::ghcr.io/open-component-model/ocm ocm.software/ocmcli ./ctf.tgz $ ocm transfer components --latest --copy-resources --type directory ghcr.io/open-component-model/ocm//ocm.software/ocmcli ./ctf\rSee Also ocm transfer\t— Transfer artifacts or components ","date":"0001-01-01","id":77,"permalink":"/docs/cli-reference/transfer/componentversions/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm transfer componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;} \u0026lt;target\u0026gt;\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -B, --bom-file string file name to write the component version BOM\n -c, --constraints constraints version constraint\n -L, --copy-local-resources transfer referenced local resources by-value\n -V, --copy-resources transfer referenced resources by-value\n --copy-sources transfer referenced sources by-value\n --disable-uploads disable standard upload handlers for transport\n --enforce enforce transport as if target version were not present\n -h, --help help for componentversions\n --latest restrict component versions to latest\n --lookup stringArray repository name or spec for closure lookup fallback\n --no-update don\u0026#39;t touch existing versions in target\n -N, --omit-access-types strings omit by-value transfer for resource types\n -f, --overwrite overwrite existing component versions\n -r, --recursive follow component reference nesting\n --repo string repository name or spec\n --script string config name of transfer handler script\n -s, --scriptFile string filename of transfer handler script\n -E, --stop-on-existing stop on existing component version in target repository\n -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\n --uploader \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; repository uploader (\u0026lt;name\u0026gt;[:\u0026lt;artifact type\u0026gt;[:\u0026lt;media type\u0026gt;[:\u0026lt;priority\u0026gt;]]]=\u0026lt;JSON target config\u0026gt;) (default [])\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eTransfer all component versions specified to the given target repository.\nIf only a component (instead of a component version) is specified all versions\nare transferred.\u003c/p\u003e","tags":[],"title":"componentversions"},{"content":"Usage ocm verify componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\rOptions -- enable verification store --ca-cert stringArray additional root certificate authorities (for signing certificates) -c, --constraints constraints version constraint -h, --help help for componentversions -I, --issuer stringArray issuer name or distinguished name (DN) (optionally for dedicated signature) ([\u0026lt;name\u0026gt;:=]\u0026lt;dn\u0026gt;) --keyless use keyless signing --latest restrict component versions to latest -L, --local verification based on information found in component versions, only --lookup stringArray repository name or spec for closure lookup fallback -K, --private-key stringArray private key setting -k, --public-key stringArray public key setting --repo string repository name or spec -s, --signature stringArray signature name --verified string file used to remember verifications for downloads (default \u0026#34;~/.ocm/verified\u0026#34;) -V, --verify verify existing digests\rDescription Verify signature of specified component versions.\nIf no signature name is given, only the digests are validated against the registered ones at the component version.\nIf the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry The \u0026ndash;public-key and \u0026ndash;private-key options can be used to define public and private keys on the command line. The options have an argument of the form [\u0026lt;name\u0026gt;=]\u0026lt;filepath\u0026gt;. The optional name specifies the signature name the key should be used for. By default, this is the signature name specified with the option \u0026ndash;signature.\nAlternatively a key can be specified as base64 encoded string if the argument start with the prefix ! or as direct string with the prefix =.\nIf the verification store is enabled, resources downloaded from signed or verified component versions are verified against their digests provided by the component version.(not supported for using downloaders for the resource download).\nThe usage of the verification store is enabled by \u0026ndash; or by specifying a verification file with \u0026ndash;verified.\nIf a component lookup for building a reference closure is required the \u0026ndash;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.\nExamples $ ocm verify componentversion --signature mysig --public-key=pub.key ghcr.io/open-component-model/ocm//ocm.software/ocm:0.17.0\rSee Also ocm verify\t— Verify component version signatures ","date":"0001-01-01","id":78,"permalink":"/docs/cli-reference/verify/componentversions/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm verify componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -- enable verification store\n --ca-cert stringArray additional root certificate authorities (for signing certificates)\n -c, --constraints constraints version constraint\n -h, --help help for componentversions\n -I, --issuer stringArray issuer name or distinguished name (DN) (optionally for dedicated signature) ([\u0026lt;name\u0026gt;:=]\u0026lt;dn\u0026gt;)\n --keyless use keyless signing\n --latest restrict component versions to latest\n -L, --local verification based on information found in component versions, only\n --lookup stringArray repository name or spec for closure lookup fallback\n -K, --private-key stringArray private key setting\n -k, --public-key stringArray public key setting\n --repo string repository name or spec\n -s, --signature stringArray signature name\n --verified string file used to remember verifications for downloads (default \u0026#34;~/.ocm/verified\u0026#34;)\n -V, --verify verify existing digests\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eVerify signature of specified component versions.\u003c/p\u003e","tags":[],"title":"componentversions"},{"content":"Usage ocm get config \u0026lt;options\u0026gt;\rOptions -h, --help help for config -O, --outfile string output file or directory -o, --output string output mode (JSON, json, yaml)\rDescription Evaluate the command line arguments and all explicitly or implicitly used configuration files and provide a single configuration object.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json yaml See Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":79,"permalink":"/docs/cli-reference/get/config/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get config \u0026lt;options\u0026gt;\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for config\n -O, --outfile string output file or directory\n -o, --output string output mode (JSON, json, yaml)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eEvaluate the command line arguments and all explicitly\nor implicitly used configuration files and provide\na single configuration object.\u003c/p\u003e","tags":[],"title":"config"},{"content":"Description The command line client supports configuring by a given configuration file. If existent, by default, the file $HOME/.ocmconfig will be read. Using the option \u0026ndash;config an alternative file can be specified.\nThe file format is yaml. It uses the same type mechanism used for all kinds of typed specification in the ocm area. The file must have the type of a configuration specification. Instead, the command line client supports a generic configuration specification able to host a list of arbitrary configuration specifications. The type for this spec is generic.config.ocm.software/v1.\nThe following configuration types are supported:\nattributes.config.ocm.software The config type attributes.config.ocm.software can be used to define a list of arbitrary attribute specifications:\ntype: attributes.config.ocm.software attributes: \u0026lt;name\u003e: \u0026lt;yaml defining the attribute\u003e ... cli.ocm.config.ocm.software The config type cli.ocm.config.ocm.software is used to handle the main configuration flags of the OCM command line tool.\ntype: cli.ocm.config.ocm.software aliases: \u0026lt;name\u003e: \u0026lt;OCI registry specification\u003e ... credentials.config.ocm.software The config type credentials.config.ocm.software can be used to define a list of arbitrary configuration specifications:\ntype: credentials.config.ocm.software consumers: - identity: \u0026lt;name\u003e: \u0026lt;value\u003e ... credentials: - \u0026lt;credential specification\u003e ... credential chain repositories: - repository: \u0026lt;repository specification\u003e credentials: - \u0026lt;credential specification\u003e ... credential chain aliases: \u0026lt;name\u003e: repository: \u0026lt;repository specification\u003e credentials: - \u0026lt;credential specification\u003e ... credential chain downloader.ocm.config.ocm.software The config type downloader.ocm.config.ocm.software can be used to define a list of preconfigured download handler registrations (see ocm ocm-downloadhandlers), the default priority is 200:\ntype: downloader.ocm.config.ocm.software description: \"my standard download handler configuration\" registrations: - name: oci/artifact artifactType: ociImage mimeType: ... description: ... priority: ... config: ... ... generic.config.ocm.software The config type generic.config.ocm.software can be used to define a list of arbitrary configuration specifications and named configuration sets:\ntype: generic.config.ocm.software configurations: - type: \u0026lt;any config type\u003e ... ... sets: standard: description: my selectable standard config configurations: - type: ... ... ... Configurations are directly applied. Configuration sets are just stored in the configuration context and can be applied on-demand. On the CLI, this can be done using the main command option \u0026ndash;config-set \u0026lt;name\u0026gt;.\nhasher.config.ocm.software The config type hasher.config.ocm.software can be used to define the default hash algorithm used to calculate digests for resources. It supports the field hashAlgorithm, with one of the following values:\nNO-DIGEST SHA-256 (default) SHA-512 keys.config.ocm.software The config type keys.config.ocm.software can be used to define public and private keys. A key value might be given by one of the fields:\npath: path of file with key data data: base64 encoded binary data stringdata: data a string parsed by key handler type: keys.config.ocm.software privateKeys: \u0026lt;name\u003e: path: \u0026lt;file path\u003e ... publicKeys: \u0026lt;name\u003e: data: \u0026lt;base64 encoded key representation\u003e ... rootCertificates: - path: \u0026lt;file path\u003e issuers: \u0026lt;name\u003e: commonName: acme.org Issuers define an expected distinguished name for public key certificates optionally provided together with signatures. They support the following fields:\ncommonName string organization string array organizationalUnit string array country string array locality string array province string array streetAddress string array postalCode string array At least the given values must be present in the certificate to be accepted for a successful signature validation.\nlogging.config.ocm.software The config type logging.config.ocm.software can be used to configure the logging aspect of a dedicated context type:\ntype: logging.config.ocm.software contextType: attributes.context.ocm.software settings: defaultLevel: Info rules: - ... The context type attributes.context.ocm.software is the root context of a context hierarchy.\nIf no context type is specified, the config will be applies to any target acting as logging context provider, which is not a non-root context.\nmemory.credentials.config.ocm.software The config type memory.credentials.config.ocm.software can be used to define a list of arbitrary credentials stored in a memory based credentials repository:\ntype: memory.credentials.config.ocm.software repoName: default credentials: - credentialsName: ref reference: # refer to a credential set stored in some other credential repository type: Credentials # this is a repo providing just one explicit credential set properties: username: mandelsoft password: specialsecret - credentialsName: direct credentials: # direct credential specification username: mandelsoft2 password: specialsecret2 merge.config.ocm.software The config type merge.config.ocm.software can be used to set some assignments for the merging of (label) values. It applies to a value merge handler registry, either directly or via an OCM context.\ntype: merge.config.ocm.software labels: - name: acme.org/audit/level merge: algorithm: acme.org/audit config: ... assignments: label:acme.org/audit/level@v1: algorithm: acme.org/audit config: ... ... oci.config.ocm.software The config type oci.config.ocm.software can be used to define OCI registry aliases:\ntype: oci.config.ocm.software aliases: \u0026lt;name\u003e: \u0026lt;OCI registry specification\u003e ... ocm.cmd.config.ocm.software The config type ocm.cmd.config.ocm.software can be used to configure predefined aliases for dedicated OCM repositories and OCI registries.\ntype: ocm.cmd.config.ocm.software ocmRepositories: \u0026lt;name\u003e: \u0026lt;specification of OCM repository\u003e ... ociRepositories: \u0026lt;name\u003e: \u0026lt;specification of OCI registry\u003e ... ocm.config.ocm.software The config type ocm.config.ocm.software can be used to set some configurations for an OCM context;\ntype: ocm.config.ocm.software aliases: myrepo: type: \u0026lt;any repository type\u003e \u0026lt;specification attributes\u003e ... resolvers: - repository: type: \u0026lt;any repository type\u003e \u0026lt;specification attributes\u003e ... prefix: ghcr.io/open-component-model/ocm priority: 10 With aliases repository alias names can be mapped to a repository specification. The alias name can be used in a string notation for an OCM repository.\nResolvers define a list of OCM repository specifications to be used to resolve dedicated component versions. These settings are used to compose a standard component version resolver provided for an OCM context. Optionally, a component name prefix can be given. It limits the usage of the repository to resolve only components with the given name prefix (always complete name segments). An optional priority can be used to influence the lookup order. Larger value means higher priority (default 10).\nAll matching entries are tried to lookup a component version in the following order:\nhighest priority first longest matching sequence of component name segments first. If resolvers are defined, it is possible to use component version names on the command line without a repository. The names are resolved with the specified resolution rule. They are also used as default lookup repositories to lookup component references for recursive operations on component versions (\u0026ndash;lookup option).\nplugin.config.ocm.software The config type plugin.config.ocm.software can be used to configure a plugin.\ntype: plugin.config.ocm.software plugin: \u0026lt;plugin name\u003e config: \u0026lt;arbitrary configuration structure\u003e disableAutoRegistration: \u0026lt;boolean flag to disable auto registration for up- and download handlers\u003e rootcerts.config.ocm.software The config type rootcerts.config.ocm.software can be used to define general root certificates. A certificate value might be given by one of the fields:\npath: path of file with key data data: base64 encoded binary data stringdata: data a string parsed by key handler rootCertificates: - path: \u0026lt;file path\u003e scripts.ocm.config.ocm.software The config type scripts.ocm.config.ocm.software can be used to define transfer scripts:\ntype: scripts.ocm.config.ocm.software scripts: \u0026lt;name\u003e: path: \u0026lt;\u003efile path\u003e \u0026lt;other name\u003e: script: \u0026lt;\u003enested script as yaml\u003e transport.ocm.config.ocm.software The config type transport.ocm.config.ocm.software can be used to define transfer scripts:\ntype: transport.ocm.config.ocm.software recursive: true overwrite: true localResourcesByValue: false resourcesByValue: true sourcesByValue: false keepGlobalAccess: false stopOnExistingVersion: false omitAccessTypes: - s3 uploader.ocm.config.ocm.software The config type uploader.ocm.config.ocm.software can be used to define a list of preconfigured upload handler registrations (see ocm ocm-uploadhandlers), the default priority is 200:\ntype: uploader.ocm.config.ocm.software description: \"my standard upload handler configuration\" registrations: - name: oci/artifact artifactType: ociImage config: ociRef: ghcr.io/open-component-model/... ... Examples type: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software repositories: - repository: type: DockerConfig/v1 dockerConfigFile: \u0026#34;~/.docker/config.json\u0026#34; propagateConsumerIdentity: true - type: attributes.config.ocm.software attributes: # map of attribute settings compat: true # - type: scripts.ocm.config.ocm.software # scripts: # \u0026#34;default\u0026#34;: # script: # process: true\rSee Also ","date":"0001-01-01","id":80,"permalink":"/docs/cli-reference/help/configfile/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eThe command line client supports configuring by a given configuration file.\nIf existent, by default, the file \u003ccode\u003e$HOME/.ocmconfig\u003c/code\u003e will be read.\nUsing the option \u003ccode\u003e\u0026ndash;config\u003c/code\u003e an alternative file can be specified.\u003c/p\u003e","tags":[],"title":"configfile"},{"content":"","date":"0001-01-01","id":81,"permalink":"/contributors/","summary":"","tags":[],"title":"Contributors"},{"content":"Usage ocm create [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for create\rSee Also Sub Commands ocm create componentarchive\t— create new component archive ocm create rsakeypair\t— create RSA public key pair ocm create transportarchive\t— create new OCI/OCM transport archive ","date":"0001-01-01","id":82,"permalink":"/docs/cli-reference/create/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm create [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for create\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/create/componentarchive/\"\u003eocm create \u003cb\u003ecomponentarchive\u003c/b\u003e\u003c/a\u003e\t — create new component archive\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/create/rsakeypair/\"\u003eocm create \u003cb\u003ersakeypair\u003c/b\u003e\u003c/a\u003e\t — create RSA public key pair\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/create/transportarchive/\"\u003eocm create \u003cb\u003etransportarchive\u003c/b\u003e\u003c/a\u003e\t — create new OCI/OCM transport archive\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"create"},{"content":"Description In contrast to libraries intended for a dedicated technical environment, for example the handling of OCI images in OCI registries, the OCM ecosystem cannot provide a specialized credential management for a dedicated environment.\nBecause of its extensibility working with component versions could require access to any kind of technical system, either for storing the model elements in a storage backend, or for accessing content in any kind of technical storage system. There are several kinds of credential consumers with potentially completely different kinds of credentials. Therefore, a common uniform credential management is required, capable to serve all those use cases.\nThis credential management brings together various kinds of credential consumers, for example the access to artifacts in OCI registries or accessing Git repository content, and credential providers, like vaults or local files in the filesystem (for example a technology specific credential source like the docker config json file for accessing OCI registries).\nThe used credential management model is based on four elements:\nCredentials:\nCredentials are described property set (key/value pairs).\nConsumer Ids\nBecause of the extensible nature of the OCM model, credential consumers must be formally identified. A consumer id described a concrete access, which must be authorized.\nThis is again achieved by a set of simple named attributes. There is only one defined property, which must always be present, the type attribute. It denotes the type of the technical environment credentials are required for. For example, for accessing OCI or Git registries. Additionally, there may be any number of arbitrary attributes used to describe the concrete instance of such an environment and access paths in this environment, which should be accessed (for example the OCI registry URL to describe the instance and the repository path for the set of objects, which should be accessed)\nThere are two use cases for consumer ids:\nCredential Request. They are used by a credential consumer to issue a credential request to the credential management. Hereby, they describe the concrete element, which should accessed. Credential Assignment. The credential management allows to assign credentials to consumer ids Credential Providers or repositories\nCredential repositories are dedicated kinds of implementations, which provide access to names sets of credentials stored in any kind of technical environment, for example a vault or a credentials somewhere on the local filesystem.\nIdentity Matchers\nThe credential management must resolve credential requests against a set of credential assignments. This is not necessarily a complete attribute match for the involved consumer ids. There is typically some kind of matching involved. For example, an assignment is done for an OCI registry with a dedicated server url and prefix for the repository path (type is OCIRegistry, host is ghcr.io, prefix path is open-component-model). The assigned credentials should be applicable for sub repositories. So the assignment uses a more general consumer id than the concrete credential request (for example for repository path open-component-model/ocm/ocmcli)\nThis kind of matching depend on the used attribute and is therefore in general type specific. Therefore, every consumer type uses an own identity matcher, which is then used by the credential management to find the best matching assignment.\nThe general process for a credential management then looks as follows.\ncredentials provided by credential repositories are assigned to generalized consumer ids. a concrete access operation for a technical environment calculates a detailed consumer id for the element, which should be accessed it asks the credential management for credentials for this id the management examines all defined assignments to find the best matching one based on the provided matching mechanism. it then returns the mapped credentials from the references repository. The critical task for a user of the toolset is to define those assignments. This is basically a manual task, because the credentials stored in vault (for example) could be usable for any kind of system, which typically cannot be derived from the credential values.\nBut luckily, those could partly be automated:\nthere may be credential providers, which are technology specific, for example the docker config json is used to describe credentials for OCI registries. Such providers can automatically assign the found credentials to appropriate consumer ids. If the credential store has the possibility to store custom meta data for a credential set, this metadata can be used to describe the intended consumer ids. The provider implementation then uses this info create the appropriate assignments. Consumer Types and Matchers The following credential consumer types are used/supported:\nBuildcredentials.ocm.software: Gardener config credential matcher\nIt matches the Buildcredentials.ocm.software consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type Buildcredentials.ocm.software evaluate the following credential properties:\nkey: secret key use to access the credential server Github: GitHub credential matcher\nThis matcher is a hostpath matcher.\nCredential consumers of the consumer type Github evaluate the following credential properties:\ntoken: GitHub personal access token HashiCorpVault: HashiCorp Vault credential matcher\nThis matcher matches credentials for a HashiCorp vault instance. It uses the following identity attributes:\nhostname: vault server host scheme: (optional) URL scheme port: (optional) server port namespace: vault namespace mountPath: mount path pathprefix: path prefix for secret Credential consumers of the consumer type HashiCorpVault evaluate the following credential properties:\nauthmeth: auth method token: vault token roleid: app-role role id secretid: app-role secret id The only supported auth methods, so far, are token and approle.\nHelmChartRepository: Helm chart repository\nIt matches the HelmChartRepository consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type HelmChartRepository evaluate the following credential properties:\nusername: the basic auth user name password: the basic auth password certificate: TLS client certificate privateKey: TLS private key certificateAuthority: TLS certificate authority MavenRepository: MVN repository\nIt matches the MavenRepository consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type MavenRepository evaluate the following credential properties:\nusername: the basic auth user name password: the basic auth password NpmRegistry: NPM registry\nIt matches the NpmRegistry consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type NpmRegistry evaluate the following credential properties:\nusername: the basic auth user name password: the basic auth password email: NPM registry, require an email address token: the token attribute. May exist after login at any npm registry. Check your .npmrc file! OCIRegistry: OCI registry credential matcher\nIt matches the OCIRegistry consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type OCIRegistry evaluate the following credential properties:\nusername: the basic auth username password: the basic auth password identityToken: the bearer token used for non-basic auth authorization certificateAuthority: the certificate authority certificate used to verify certificates S3: S3 credential matcher\nThis matcher is a hostpath matcher.\nCredential consumers of the consumer type S3 evaluate the following credential properties:\nawsAccessKeyID: AWS access key id awsSecretAccessKey: AWS secret for access key id token: AWS access token (alternatively) Signingserver.gardener.cloud: signing service credential matcher\nThis matcher matches credentials for a Signing Service instance. It uses the following identity attributes:\nhostname: signing server host scheme: (optional) URL scheme port: (optional) server port pathprefix: path prefix for the server URL Credential consumers of the consumer type Signingserver.gardener.cloud evaluate the following credential properties:\nclientCert: client certificate for authentication privateKey: private key for client certificate caCerts: root certificate for signing server wget: wget credential matcher\nIt matches the wget consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type wget evaluate the following credential properties:\nusername: the basic auth user name password: the basic auth password identityToken: the bearer token used for non-basic auth authorization certificateAuthority: the certificate authority certificate used to verify certificates presented by the server certificate: the certificate used to present to the server privateKey: the private key corresponding to the certificate Those consumer types provide their own matchers, which are often based on some standard generic matches. Those generic matchers and their behaviors are described in the following list:\nexact: exact match of given pattern set\nhostpath: Host and path based credential matcher\nThis matcher works on the following properties:\ntype (required if set in pattern): the identity type hostname (required if set in pattern): the hostname of a server scheme (optional): the URL scheme of a server port (optional): the port of a server pathprefix (optional): a path prefix to match. The element with the most matching path components is selected (separator is /). partial: complete match of given pattern ignoring additional attributes\nCredential Providers Credential providers offer sets of named credentials from various sources, which might be directly mapped to consumer identities (if supported by the provider type).\nThe type Credentials can be used to inline credentials in credential configuration objects to configure mappings of consumer identities to a credential set (see ocm configfile).\nThe following types are currently available:\nCredential provider Credentials\nThis repository type can be used to specify a single inline credential set. The default name is the empty string or Credentials.\nThe following versions are supported:\nVersion v1\nThe repository specification supports the following fields:\nproperties: map[string]string: direct credential fields Credential provider DockerConfig\nThis repository type can be used to access credentials stored in a file following the docker config json format. It take into account the credentials helper section, also. If enabled, the described credentials will be automatically assigned to appropriate consumer ids.\nThe following versions are supported:\nVersion v1\nThe repository specification supports the following fields:\ndockerConfigFile: string: the file path to a docker config file dockerConfig: json: an embedded docker config json propagateConsumerIdentity: bool(optional): enable consumer id propagation Credential provider HashiCorpVault\nThis repository type can be used to access credentials stored in a HashiCorp Vault.\nIt provides access to list of secrets stored under a dedicated path in a vault namespace. This list can either explicitly be specified, or it is taken from the metadata of a specified secret.\nThe following custom metadata attributes are evaluated:\nsecrets this attribute may contain a comma separated list of vault secrets, which should be exposed by this repository instance. The names are evaluated under the path prefix used for the repository. consumerId this attribute may contain a JSON encoded consumer id , this secret should be assigned to. type if no special attribute is defined this attribute indicated to use the complete custom metadata as consumer id. It uses the HashiCorpVault identity matcher and consumer type to requests credentials for the access.\nThis matcher matches credentials for a HashiCorp vault instance. It uses the following identity attributes:\nhostname: vault server host scheme: (optional) URL scheme port: (optional) server port namespace: vault namespace mountPath: mount path pathprefix: path prefix for secret It requires the following credential attributes:\nauthmeth: auth method token: vault token roleid: app-role role id secretid: app-role secret id The only supported auth methods, so far, are token and approle.\nThe following versions are supported:\nVersion v1\nThe repository specification supports the following fields:\nserverURL: string (required): the URL of the vault instance namespace: string (optional): the namespace used to evaluate secrets mountPath: string (optional): the mount path to use (default: secrets) path: string (optional): the path prefix used to lookup secrets secrets: []string (optional): list of secrets propagateConsumerIdentity: bool(optional): evaluate metadata for consumer id propagation If the secrets list is empty, all secret entries found in the given path is read.\nCredential provider NPMConfig\nThis repository type can be used to access credentials stored in a file following the NPM npmrc format (~/.npmrc). It take into account the credentials helper section, also. If enabled, the described credentials will be automatically assigned to appropriate consumer ids.\nThe following versions are supported:\nVersion v1\nThe repository specification supports the following fields:\nnpmrcFile: string: the file path to a NPM npmrc file propagateConsumerIdentity: bool(optional): enable consumer id propagation See Also ","date":"0001-01-01","id":83,"permalink":"/docs/cli-reference/help/credential-handling/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eIn contrast to libraries intended for a dedicated technical environment,\nfor example the handling of OCI images in OCI registries, the OCM\necosystem cannot provide a specialized credential management for a dedicated\nenvironment.\u003c/p\u003e","tags":[],"title":"credential-handling"},{"content":"Usage ocm get credentials {\u0026lt;consumer property\u0026gt;=\u0026lt;value\u0026gt;}\rOptions -h, --help help for credentials -m, --matcher string matcher type override -s, --sloppy sloppy matching of consumer type\rDescription Try to resolve a given consumer specification against the configured credential settings and show the found credential attributes.\nMatchers exist for the following usage contexts or consumer types:\nBuildcredentials.ocm.software: Gardener config credential matcher\nIt matches the Buildcredentials.ocm.software consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type Buildcredentials.ocm.software evaluate the following credential properties:\nkey: secret key use to access the credential server Github: GitHub credential matcher\nThis matcher is a hostpath matcher.\nCredential consumers of the consumer type Github evaluate the following credential properties:\ntoken: GitHub personal access token HashiCorpVault: HashiCorp Vault credential matcher\nThis matcher matches credentials for a HashiCorp vault instance. It uses the following identity attributes:\nhostname: vault server host scheme: (optional) URL scheme port: (optional) server port namespace: vault namespace mountPath: mount path pathprefix: path prefix for secret Credential consumers of the consumer type HashiCorpVault evaluate the following credential properties:\nauthmeth: auth method token: vault token roleid: app-role role id secretid: app-role secret id The only supported auth methods, so far, are token and approle.\nHelmChartRepository: Helm chart repository\nIt matches the HelmChartRepository consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type HelmChartRepository evaluate the following credential properties:\nusername: the basic auth user name password: the basic auth password certificate: TLS client certificate privateKey: TLS private key certificateAuthority: TLS certificate authority MavenRepository: MVN repository\nIt matches the MavenRepository consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type MavenRepository evaluate the following credential properties:\nusername: the basic auth user name password: the basic auth password NpmRegistry: NPM registry\nIt matches the NpmRegistry consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type NpmRegistry evaluate the following credential properties:\nusername: the basic auth user name password: the basic auth password email: NPM registry, require an email address token: the token attribute. May exist after login at any npm registry. Check your .npmrc file! OCIRegistry: OCI registry credential matcher\nIt matches the OCIRegistry consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type OCIRegistry evaluate the following credential properties:\nusername: the basic auth username password: the basic auth password identityToken: the bearer token used for non-basic auth authorization certificateAuthority: the certificate authority certificate used to verify certificates S3: S3 credential matcher\nThis matcher is a hostpath matcher.\nCredential consumers of the consumer type S3 evaluate the following credential properties:\nawsAccessKeyID: AWS access key id awsSecretAccessKey: AWS secret for access key id token: AWS access token (alternatively) Signingserver.gardener.cloud: signing service credential matcher\nThis matcher matches credentials for a Signing Service instance. It uses the following identity attributes:\nhostname: signing server host scheme: (optional) URL scheme port: (optional) server port pathprefix: path prefix for the server URL Credential consumers of the consumer type Signingserver.gardener.cloud evaluate the following credential properties:\nclientCert: client certificate for authentication privateKey: private key for client certificate caCerts: root certificate for signing server wget: wget credential matcher\nIt matches the wget consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type wget evaluate the following credential properties:\nusername: the basic auth user name password: the basic auth password identityToken: the bearer token used for non-basic auth authorization certificateAuthority: the certificate authority certificate used to verify certificates presented by the server certificate: the certificate used to present to the server privateKey: the private key corresponding to the certificate The following standard identity matchers are supported:\nexact: exact match of given pattern set\nhostpath: Host and path based credential matcher\nThis matcher works on the following properties:\ntype (required if set in pattern): the identity type hostname (required if set in pattern): the hostname of a server scheme (optional): the URL scheme of a server port (optional): the port of a server pathprefix (optional): a path prefix to match. The element with the most matching path components is selected (separator is /). partial (default): complete match of given pattern ignoring additional attributes\nThe used matcher is derived from the consumer attribute type. For all other consumer types a matcher matching all attributes will be used. The usage of a dedicated matcher can be enforced by the option \u0026ndash;matcher.\nSee Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":84,"permalink":"/docs/cli-reference/get/credentials/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get credentials {\u0026lt;consumer property\u0026gt;=\u0026lt;value\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for credentials\n -m, --matcher string matcher type override\n -s, --sloppy sloppy matching of consumer type\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eTry to resolve a given consumer specification against the configured credential\nsettings and show the found credential attributes.\u003c/p\u003e","tags":[],"title":"credentials"},{"content":"Usage ocm describe [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for describe\rSee Also Sub Commands ocm describe artifacts\t— describe artifact version ocm describe cache\t— show OCI blob cache information ocm describe package\t— describe TOI package ocm describe plugins\t— get plugins ","date":"0001-01-01","id":85,"permalink":"/docs/cli-reference/describe/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm describe [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for describe\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/describe/artifacts/\"\u003eocm describe \u003cb\u003eartifacts\u003c/b\u003e\u003c/a\u003e\t — describe artifact version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/describe/cache/\"\u003eocm describe \u003cb\u003ecache\u003c/b\u003e\u003c/a\u003e\t — show OCI blob cache information\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/describe/package/\"\u003eocm describe \u003cb\u003epackage\u003c/b\u003e\u003c/a\u003e\t — describe TOI package\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/describe/plugins/\"\u003eocm describe \u003cb\u003eplugins\u003c/b\u003e\u003c/a\u003e\t — get plugins\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"describe"},{"content":"Usage ocm download [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for download\rSee Also Sub Commands ocm download artifacts\t— download oci artifacts ocm download cli\t— download OCM CLI from an OCM repository ocm download componentversions\t— download ocm component versions ocm download resources\t— download resources of a component version ","date":"0001-01-01","id":86,"permalink":"/docs/cli-reference/download/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm download [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for download\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/download/artifacts/\"\u003eocm download \u003cb\u003eartifacts\u003c/b\u003e\u003c/a\u003e\t — download oci artifacts\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/download/cli/\"\u003eocm download \u003cb\u003ecli\u003c/b\u003e\u003c/a\u003e\t — download OCM CLI from an OCM repository\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/download/componentversions/\"\u003eocm download \u003cb\u003ecomponentversions\u003c/b\u003e\u003c/a\u003e\t — download ocm component versions\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/download/resources/\"\u003eocm download \u003cb\u003eresources\u003c/b\u003e\u003c/a\u003e\t — download resources of a component version\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"download"},{"content":"Usage ocm get [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for get\rSee Also Sub Commands ocm get artifacts\t— get artifact version ocm get componentversions\t— get component version ocm get config\t— Get evaluated config for actual command call ocm get credentials\t— Get credentials for a dedicated consumer spec ocm get plugins\t— get plugins ocm get pubsub\t— Get the pubsub spec for an ocm repository ocm get references\t— get references of a component version ocm get resources\t— get resources of a component version ocm get routingslips\t— get routings slips for a component version ocm get sources\t— get sources of a component version ocm get verified\t— get verified component versions ","date":"0001-01-01","id":87,"permalink":"/docs/cli-reference/get/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for get\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/artifacts/\"\u003eocm get \u003cb\u003eartifacts\u003c/b\u003e\u003c/a\u003e\t — get artifact version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/componentversions/\"\u003eocm get \u003cb\u003ecomponentversions\u003c/b\u003e\u003c/a\u003e\t — get component version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/config/\"\u003eocm get \u003cb\u003econfig\u003c/b\u003e\u003c/a\u003e\t — Get evaluated config for actual command call\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/credentials/\"\u003eocm get \u003cb\u003ecredentials\u003c/b\u003e\u003c/a\u003e\t — Get credentials for a dedicated consumer spec\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/plugins/\"\u003eocm get \u003cb\u003eplugins\u003c/b\u003e\u003c/a\u003e\t — get plugins\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/pubsub/\"\u003eocm get \u003cb\u003epubsub\u003c/b\u003e\u003c/a\u003e\t — Get the pubsub spec for an ocm repository\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/references/\"\u003eocm get \u003cb\u003ereferences\u003c/b\u003e\u003c/a\u003e\t — get references of a component version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/resources/\"\u003eocm get \u003cb\u003eresources\u003c/b\u003e\u003c/a\u003e\t — get resources of a component version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/routingslips/\"\u003eocm get \u003cb\u003eroutingslips\u003c/b\u003e\u003c/a\u003e\t — get routings slips for a component version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/sources/\"\u003eocm get \u003cb\u003esources\u003c/b\u003e\u003c/a\u003e\t — get sources of a component version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"\"\u003eocm get \u003cb\u003everified\u003c/b\u003e\u003c/a\u003e\t — get verified component versions\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"get"},{"content":"Usage ocm sign hash \u0026lt;private key file\u0026gt; \u0026lt;hash\u0026gt; [\u0026lt;issuer\u0026gt;]\rOptions -S, --algorithm string signature algorithm (default \u0026#34;RSASSA-PKCS1-V1_5\u0026#34;) --ca-cert stringArray additional root certificate authorities (for signing certificates) -h, --help help for hash --publicKey string public key certificate file --rootCerts string root certificates file (deprecated)\rDescription Print the signature for a dedicated digest value.\nExamples $ ocm sign hash key.priv SHA-256:810ff2fb242a5dee4220f2cb0e6a519891fb67f2f828a6cab4ef8894633b1f50\rSee Also ocm sign\t— Sign components or hashes ","date":"0001-01-01","id":88,"permalink":"/docs/cli-reference/sign/hash/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm sign hash \u0026lt;private key file\u0026gt; \u0026lt;hash\u0026gt; [\u0026lt;issuer\u0026gt;]\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -S, --algorithm string signature algorithm (default \u0026#34;RSASSA-PKCS1-V1_5\u0026#34;)\n --ca-cert stringArray additional root certificate authorities (for signing certificates)\n -h, --help help for hash\n --publicKey string public key certificate file\n --rootCerts string root certificates file (deprecated)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003ePrint the signature for a dedicated digest value.\u003c/p\u003e","tags":[],"title":"hash"},{"content":"Additional Topics attributes — attributes configfile — configfile credential-handling — credential-handling logging — logging oci-references — oci-references ocm-accessmethods — ocm-accessmethods ocm-downloadhandlers — ocm-downloadhandlers ocm-labels — ocm-labels ocm-pubsub — ocm-pubsub ocm-references — ocm-references ocm-uploadhandlers — ocm-uploadhandlers toi-bootstrapping — toi-bootstrapping ","date":"0001-01-01","id":89,"permalink":"/docs/cli-reference/help/","summary":"\u003ch3 id=\"additional-topics\"\u003eAdditional Topics\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/attributes/\"\u003eattributes\u003c/a\u003e — attributes\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/configfile/\"\u003econfigfile\u003c/a\u003e — configfile\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/credential-handling/\"\u003ecredential-handling\u003c/a\u003e — credential-handling\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/logging/\"\u003elogging\u003c/a\u003e — logging\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/oci-references/\"\u003eoci-references\u003c/a\u003e — oci-references\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/ocm-accessmethods/\"\u003eocm-accessmethods\u003c/a\u003e — ocm-accessmethods\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/ocm-downloadhandlers/\"\u003eocm-downloadhandlers\u003c/a\u003e — ocm-downloadhandlers\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/ocm-labels/\"\u003eocm-labels\u003c/a\u003e — ocm-labels\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/ocm-pubsub/\"\u003eocm-pubsub\u003c/a\u003e — ocm-pubsub\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/ocm-references/\"\u003eocm-references\u003c/a\u003e — ocm-references\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/ocm-uploadhandlers/\"\u003eocm-uploadhandlers\u003c/a\u003e — ocm-uploadhandlers\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/toi-bootstrapping/\"\u003etoi-bootstrapping\u003c/a\u003e — toi-bootstrapping\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"help"},{"content":"Usage ocm list [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for list\rSee Also Sub Commands ocm list componentversions\t— list component version names ","date":"0001-01-01","id":90,"permalink":"/docs/cli-reference/list/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm list [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for list\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/list/componentversions/\"\u003eocm list \u003cb\u003ecomponentversions\u003c/b\u003e\u003c/a\u003e\t — list component version names\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"list"},{"content":"Description Logging can be configured as part of the ocm config file (ocm configfile) or by command line options of the ocm command. Details about the YAML structure of a logging settings can be found on https://github.com/mandelsoft/logging.\nThe command line also supports some quick-config options for enabling log levels for dedicated tags and realms or realm prefixes (logging keys).\nThe following tags are used by the command line tool:\nblobhandler: execution of blob handler used to upload resource blobs to an ocm repository. cd-diff: component descriptor modification The following realms are used by the command line tool:\nocm: general realm used for the ocm go library. ocm/accessmethod/ociartifact: access method ociArtifact ocm/accessmethod/wget: access method for wget ocm/blobaccess/wget: blob access for wget ocm/compdesc: component descriptor handling ocm/config: configuration management ocm/context: context lifecycle ocm/credentials: Credentials ocm/credentials/dockerconfig: docker config handling as credential repository ocm/credentials/vault: HashiCorp Vault Access ocm/downloader: Downloaders ocm/maven: Maven repository ocm/npm: NPM registry ocm/oci/docker: Docker repository handling ocm/oci/mapping: OCM to OCI Registry Mapping ocm/oci/ocireg: OCI repository handling ocm/plugins: OCM plugin handling ocm/processing: output processing chains ocm/refcnt: reference counting ocm/toi: TOI logging ocm/transfer: OCM transfer handling ocm/valuemerge: value marge handling Examples type: logging.config.ocm.software contextType: attributes.context.ocm.software settings: defaultLevel: Info rules: - ...\rSee Also ","date":"0001-01-01","id":91,"permalink":"/docs/cli-reference/help/logging/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eLogging can be configured as part of the ocm config file (\u003ca href=\"/docs/cli-reference/help/configfile/\"\u003eocm configfile\u003c/a\u003e)\nor by command line options of the \u003ca href=\"/docs/cli-reference/\"\u003eocm\u003c/a\u003e command. Details about\nthe YAML structure of a logging settings can be found on https://github.com/mandelsoft/logging.\u003c/p\u003e","tags":[],"title":"logging"},{"content":"Description The command line client supports a special notation scheme for specifying references to instances of oci like registries. This allows for specifying references to any registry supported by the OCM toolset that can host OCI artifacts. As a subset the regular OCI artifact notation used for docker images are possible:\n[+][\u0026lt;type\u003e::][./][\u0026lt;file path\u003e//\u0026lt;repository\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] or\n[+][\u0026lt;type\u003e::][\u0026lt;json repo spec\u003e//]\u0026lt;repository\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] Notice that if you specify the \u0026lt;type\u0026gt; in the beginning of this notation AND in the \u0026lt;json repo spec\u0026gt;, the types have to match (but there is no reason to specify the type in both places).\nor\n[+][\u0026lt;type\u003e::][\u0026lt;scheme\u003e://]\u0026lt;domain\u003e[:\u0026lt;port\u003e][/]/\u0026lt;repository\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] Notice that this notation optionally also allows a double slash to separate \u0026lt;domain\u0026gt;[:\u0026lt;port\u0026gt;] and \u0026lt;repository\u0026gt;. While it is not necessary for unambiguous parsing here, it is supported for consistency with the other notations.\nor\n[+][\u0026lt;type\u003e::][\u0026lt;scheme\u003e://]\u0026lt;host\u003e:\u0026lt;port\u003e/\u0026lt;repository\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] Notice that \u0026lt;port\u0026gt; is required in this notation. Without \u0026lt;port\u0026gt;, this notation would be ambiguous with the docker library notation mentioned below.\nor\n[+][\u0026lt;type\u003e::][\u0026lt;scheme\u003e://]\u0026lt;host\u003e[:\u0026lt;port\u003e]//\u0026lt;repository\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] Notice the double slash (//) before the \u0026lt;repository\u0026gt;. This serves as a clear separator between \u0026lt;host\u0026gt;[:\u0026lt;port\u0026gt;] and \u0026lt;repository\u0026gt;. Thus, with this notation, the port is optional and can therefore be omitted without creating ambiguity with the docker library notation mentioned below.\nor\n\u0026lt;docker library\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] or\n\u0026lt;docker repository\u003e/\u0026lt;docker image\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] Besides dedicated artifacts it is also possible to denote registries as a whole:\n[+][\u0026lt;type\u003e::][./]\u0026lt;file path\u003e or\n[+][\u0026lt;type\u003e::]\u0026lt;json repo spec\u003e Notice that if you specify the \u0026lt;type\u0026gt; in the beginning of this notation AND in the \u0026lt;json repo spec\u0026gt;, the types have to match (but there is no reason to specify the type in both places).\nor\n[+][\u0026lt;type\u003e::][\u0026lt;scheme\u003e://]\u0026lt;domain\u003e[:\u0026lt;port\u003e] or\n[+][\u0026lt;type\u003e::][\u0026lt;scheme\u003e://]\u0026lt;host\u003e[:\u0026lt;port\u003e] Notice that \u0026lt;port\u0026gt; is optional in this notation since this cannot be an image reference and therefore cannot be ambiguous with the docker library notation.\nThe optional + is used for file based implementations (Common Transport Format) to indicate the creation of a not yet existing file.\nThe type may contain a file format qualifier separated by a + character. The following formats are supported: directory, tar, tgz\nExamples +ctf+directory::./ocm/ctf//ocm.software/ocmcli/ocmcli-image:0.7.0@sha256:29c842be1ef1da67f6a1c07a3a3a8eb101bbcc4c80f174b87d147b341bca9625 oci::{\u0026#34;baseUrl\u0026#34;: \u0026#34;ghcr.io\u0026#34;}//open-component-model/ocm/ocm.software/ocmcli/ocmcli-image:0.7.0@sha256:29c842be1ef1da67f6a1c07a3a3a8eb101bbcc4c80f174b87d147b341bca9625 oci::https://ghcr.io/open-component-model/ocm/ocm.software/ocmcli/ocmcli-image:0.7.0@sha256:29c842be1ef1da67f6a1c07a3a3a8eb101bbcc4c80f174b87d147b341bca9625 oci::https://ghcr.io//open-component-model/ocm/ocm.software/ocmcli/ocmcli-image:0.7.0@sha256:29c842be1ef1da67f6a1c07a3a3a8eb101bbcc4c80f174b87d147b341bca9625 oci::http://localhost:8080/ocm.software/ocmcli/ocmcli-image:0.7.0@sha256:29c842be1ef1da67f6a1c07a3a3a8eb101bbcc4c80f174b87d147b341bca9625 oci::http://localhost:8080//ocm.software/ocmcli/ocmcli-image:0.7.0@sha256:29c842be1ef1da67f6a1c07a3a3a8eb101bbcc4c80f174b87d147b341bca9625 ubuntu:24.04 ubuntu tensorflow/tensorflow:2.15.0 tensorflow/tensorflow\rSee Also ","date":"0001-01-01","id":92,"permalink":"/docs/cli-reference/help/oci-references/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eThe command line client supports a special notation scheme for specifying\nreferences to instances of oci like registries. This allows for specifying\nreferences to any registry supported by the OCM toolset that can host OCI\nartifacts. As a subset the regular OCI artifact notation used for docker\nimages are possible:\u003c/p\u003e","tags":[],"title":"oci-references"},{"content":"Description Access methods are used to handle the access to the content of artifacts described in a component version. Therefore, an artifact entry contains an access specification describing the access attributes for the dedicated artifact.\nThe following list describes the supported access methods, their versions and specification formats. Typically there is special support for the CLI artifact add commands. The access method specification can be put below the access field. If always requires the field type describing the kind and version shown below.\nAccess type gitHub\nThis method implements the access of the content of a git commit stored in a GitHub repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nRepository URL with or without scheme.\nref (optional) string\nOriginal ref used to get the commit from\ncommit string\nThe sha/id of the git commit\nOptions used to configure fields: \u0026ndash;accessHostname, \u0026ndash;accessRepository, \u0026ndash;commit\nAccess type helm\nThis method implements the access of a Helm chart stored in a Helm repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nhelmRepository string\nHelm repository URL.\nhelmChart string\nThe name of the Helm chart and its version separated by a colon.\nversion string\nThe version of the Helm chart if not specified as part of the chart name.\ncaCert string\nAn optional TLS root certificate.\nkeyring string\nAn optional keyring used to verify the chart.\nIt uses the consumer identity type HelmChartRepository with the fields for a hostpath identity matcher (see ocm get credentials).\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type localBlob\nThis method is used to store a resource blob along with the component descriptor on behalf of the hosting OCM repository.\nIts implementation is specific to the implementation of OCM repository used to read the component descriptor. Every repository implementation may decide how and where local blobs are stored, but it MUST provide an implementation for this method.\nRegardless of the chosen implementation the attribute specification is defined globally the same.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nlocalReference string\nRepository type specific location information as string. The value may encode any deep structure, but typically just an access path is sufficient.\nmediaType string\nThe media type of the blob used to store the resource. It may add format information like +tar or +gzip.\nreferenceName (optional) string\nThis optional attribute may contain identity information used by other repositories to restore some global access with an identity related to the original source.\nFor example, if an OCI artifact originally referenced using the access method ociArtifact is stored during some transport step as local artifact, the reference name can be set to its original repository name. An import step into an OCI based OCM repository may then decide to make this artifact available again as regular OCI artifact.\nglobalAccess (optional) access method specification\nIf a resource blob is stored locally, the repository implementation may decide to provide an external access information (independent of the OCM model).\nFor example, an OCI artifact stored as local blob can be additionally stored as regular OCI artifact in an OCI registry.\nThis additional external access information can be added using a second external access method specification.\nOptions used to configure fields: \u0026ndash;globalAccess, \u0026ndash;hint, \u0026ndash;mediaType, \u0026ndash;reference\nAccess type maven\nThis method implements the access of a Maven artifact in a Maven repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nURL of the Maven repository\ngroupId string\nThe groupId of the Maven artifact\nartifactId string\nThe artifactId of the Maven artifact\nversion string\nThe version name of the Maven artifact\nclassifier string\nThe optional classifier of the Maven artifact\nextension string\nThe optional extension of the Maven artifact\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;artifactId, \u0026ndash;classifier, \u0026ndash;extension, \u0026ndash;groupId\nAccess type none\ndummy resource with no access\nAccess type npm\nThis method implements the access of an NPM package in an NPM registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregistry string\nBase URL of the NPM registry.\npackage string\nThe name of the NPM package\nversion string\nThe version name of the NPM package\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type ociArtifact\nThis method implements the access of an OCI artifact stored in an OCI registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI image/artifact reference following the possible docker schemes:\n\u0026lt;repo\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;digest\u0026gt;@\u0026lt;tag\u0026gt; [\u0026lt;port\u0026gt;]/\u0026lt;repo path\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;version\u0026gt;@\u0026lt;tag\u0026gt; Options used to configure fields: \u0026ndash;reference\nAccess type ociBlob\nThis method implements the access of an OCI blob stored in an OCI repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI repository reference (this artifact name used to store the blob).\nmediaType string\nThe media type of the blob\ndigest string\nThe digest of the blob used to access the blob in the OCI repository.\nsize integer\nThe size of the blob\nOptions used to configure fields: \u0026ndash;digest, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;size\nAccess type ocm\nThis method implements the access of any resource artifact stored in an OCM repository. Only repository types supporting remote access should be used.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nocmRepository json\nThe repository spec for the OCM repository\ncomponent string\n(Optional) The name of the component. The default is the own component.\nversion string\n(Optional) The version of the component. The default is the own component version.\nresourceRef relative resource ref\nThe resource reference of the denoted resource relative to the given component version.\nIt uses the consumer identity and credentials for the intermediate repositories and the final resource access.\nOptions used to configure fields: \u0026ndash;accessComponent, \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;identityPath\nAccess type s3\nThis method implements the access of a blob stored in an S3 bucket.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucket string\nThe name of the S3 bucket containing the blob\nkey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nVersion v2\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucketName string\nThe name of the S3 bucket containing the blob\nobjectKey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nOptions used to configure fields: \u0026ndash;accessVersion, \u0026ndash;bucket, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;region\nAccess type wget\nThis method implements access to resources stored on an http server.\nThe following versions are supported:\nVersion v1\nThe url is the url pointing to the http endpoint from which a resource is downloaded. The mimeType can be used to specify the MIME type of the resource.\nThis blob type specification supports the following fields:\nurl string This REQUIRED property describes the url from which the resource is to be downloaded.\nmediaType string This OPTIONAL property describes the media type of the resource to be downloaded. If omitted, ocm tries to read the mediaType from the Content-Type header of the http response. If the mediaType cannot be set from the Content-Type header as well, ocm tries to deduct the mediaType from the URL. If that is not possible either, the default media type is defaulted to application/octet-stream.\nheader map[string][]string This OPTIONAL property describes the http headers to be set in the http request to the server.\nverb string This OPTIONAL property describes the http verb (also known as http request method) for the http request. If omitted, the http verb is defaulted to GET.\nbody []byte This OPTIONAL property describes the http body to be included in the request.\nnoredirect bool This OPTIONAL property describes whether http redirects should be disabled. If omitted, it is defaulted to false (so, per default, redirects are enabled).\nOptions used to configure fields: \u0026ndash;body, \u0026ndash;header, \u0026ndash;mediaType, \u0026ndash;noredirect, \u0026ndash;url, \u0026ndash;verb\nSee Also ","date":"0001-01-01","id":93,"permalink":"/docs/cli-reference/help/ocm-accessmethods/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAccess methods are used to handle the access to the content of artifacts\ndescribed in a component version. Therefore, an artifact entry contains\nan access specification describing the access attributes for the dedicated\nartifact.\u003c/p\u003e","tags":[],"title":"ocm-accessmethods"},{"content":"Description A download handler can be used to process resources to be downloaded from on OCM repository. By default, the blobs provided from the access method (see ocm ocm-accessmethods) are used to store the resource content in the local filesystem. Download handlers can be used to tweak this process. They get access to the blob content and decide on their own what to do with it, or how to transform it into files stored in the file system.\nFor example, a pre-registered helm download handler will store OCI-based helm artifacts as regular helm archives in the local file system.\nHandler Registration Programmatically any kind of handlers can be registered for various download conditions. But this feature is available as command-line option, also. New handlers can be provided by plugins. In general available handlers, plugin-based or as part of the CLI coding are nameable using an hierarchical namespace. Those names can be used by a \u0026ndash;downloader option to register handlers for various conditions for CLI commands like ocm download resources (implicitly registered download handlers can be enabled using the option -d).\nBesides the activation constraints (resource type and media type of the resource blob), it is possible to pass handler configuration controlling the exact behaviour of the handler for selected artifacts.\nThe following handler names are possible:\nhelm/artifact: download helm chart resources\nThe helm downloader is able to download helm chart resources as helm chart packages. Thus, the downloader may perform transformations. For example, if the helm chart is currently stored as an oci artifact, the downloader performs the necessary extraction to provide the helm chart package from within that oci artifact.\nThe following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar+gzip application/vnd.cncf.helm.chart.content.v1.tar+gzip It accepts no config.\nlandscaper/blueprint: uploading an OCI artifact to an OCI registry\nThe artifact downloader is able to transfer OCI artifact-like resources into an OCI registry given by the combination of the download target and the registration config.\nIf no config is given, the target must be an OCI reference with a potentially omitted repository. The repo part is derived from the reference hint provided by the resource\u0026rsquo;s access specification.\nIf the config is given, the target is used as repository name prefixed with an optional repository prefix given by the configuration.\nThe following artifact media types are supported:\napplication/vnd.docker.distribution.manifest.v2+tar application/vnd.docker.distribution.manifest.v2+tar+gzip application/vnd.gardener.landscaper.blueprint.layer.v1.tar application/vnd.gardener.landscaper.blueprint.layer.v1.tar+gzip application/vnd.gardener.landscaper.blueprint.v1+tar application/vnd.gardener.landscaper.blueprint.v1+tar+gzip application/vnd.oci.image.manifest.v1+tar application/vnd.oci.image.manifest.v1+tar+gzip application/x-tar application/x-tar+gzip application/x-tgz It accepts a config with the following fields:\nociConfigTypes: a list of accepted OCI config archive mime types defaulted by application/vnd.gardener.landscaper.blueprint.config.v1. This handler is by default registered for the following artifact types: landscaper.gardener.cloud/blueprint,blueprint\noci/artifact: downloading an OCI artifact and optionally re-uploading to an OCI registry\nThe artifact download resources stored as oci artifact. Furthermore, it allows to specify another OCI registry as download destination, thereby, providing a kind of transfer functionality.\nIf no config is given, the target must be an OCI reference with a potentially omitted repository. The repo part is derived from the reference hint provided by the resource\u0026rsquo;s access specification.\nIf the config is given, the target is used as repository name prefixed with an optional repository prefix given by the configuration.\nThe following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar+gzip application/vnd.oci.image.index.v1+tar+gzip It accepts a config with the following fields:\nnamespacePrefix: a namespace prefix used for the uploaded artifacts ociRef: an OCI repository reference repository: an OCI repository specification for the target OCI registry ocm/dirtree: downloading directory tree-like resources\nThe dirtree downloader is able to download directory-tree like resources as directory structure (default) or archive. The following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar+gzip application/x-tgz application/x-tar+gzip application/x-tar By default, it is registered for the following resource types:\ndirectoryTree filesystem It accepts a config with the following fields:\nasArchive: flag to request an archive download ociConfigTypes: a list of accepted OCI config archive mime types defaulted by application/vnd.oci.image.config.v1+json. plugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\nSee ocm ocm-downloadhandlers for further details on using download handlers.\nSee Also ","date":"0001-01-01","id":94,"permalink":"/docs/cli-reference/help/ocm-downloadhandlers/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eA download handler can be used to process resources to be downloaded from\non OCM repository. By default, the blobs provided from the access method\n(see \u003ca href=\"/docs/cli-reference/help/ocm-accessmethods/\"\u003eocm ocm-accessmethods\u003c/a\u003e) are used to store the resource content\nin the local filesystem. Download handlers can be used to tweak this process.\nThey get access to the blob content and decide on their own what to do\nwith it, or how to transform it into files stored in the file system.\u003c/p\u003e","tags":[],"title":"ocm-downloadhandlers"},{"content":"Description Labels are a set of arbitrary properties, which can be attached to elements of a component version:\na component version itself the provider of a component version resources sources component references The dedicated elements support this by providing a field labels, which is a list of label definitions. Every label definition has several fields:\nname string\nThe name of the label also determines the interpretation of its value. All labels with a dedicated name must have the same globally unique meaning, enabling a common understanding of label content for tools working of such properties of an element.\nThere are several predefined labels, they just use flat names. To guarantee globally unique meanings of labels a label name may have a hierarchical structure. Names defined in dedicated definition realms must be prefixed by a DNS domain-like string identifying the organization of realm defining the label\u0026rsquo;s value structure. For example: acme.org/maturity/level.\nHereby, the name defines the meaning of the value and its value structure. To support the evolution of the value structure a label field optionally contains a version field, which finally defines the concrete value structure in the context of the meaning of the label name. A version is just a number prefixed with a v. If not specified, the version v1 is assumed.\nversion string (optional) (default: v1)\nThe format version of the label value in the context of the label name.\nvalue any\nThe value of the label according to the specified format version of the label in the context of its name.\nsigning bool (optional)\nBy default, labels are not signature-relevant and they will nor influence the digest of the component version. This allows adding, deleting or modifying labels as part of a process chain during the lifecycle of a component version.\nLabels which should describe relevant and unmodifiable content can be marked to be signing relevant by setting this label field to true.\nmerge merge spec (optional)\nModifiable labels can be changed independently in any transport target location of a component version. This might require to update label values when importing a new setting for a component version. This means a merging of content to reflect the combination of changes in the transport source and target.\nThis is supported by the possibility to specify merge algorithms. The can be bound to a dedicated label incarnation or to the label name.\nMerge Specification A merge specification consists of two fields:\nalgorithm string (optional) (default: default)\nThe name of the algorithm to be used for the merge process.\nconfig any (optional)\nAn algorithm specific configuration to control the merge process.\nThere is an often used configuration field overwrite with a common meaning for all algorithms supporting it. It controls the conflict resolution and has the following values:\nnone: conflicting values prevent the merging. An update transfer process will be aborted.\nlocal: a conflict will be resolved to the local change (in the target environment)\ninbound: a conflict will be resolved to the value provided by the source environment\n\u0026lt;empty\u0026gt;: use a default provided by the dedicated algorithm.\nThe default behaviour might mean to apply a cascaded merge specification, if the merge specification supports to specify appropriate fields to specify this specification (for example a field entries).\nDetermining a Merge Specification A merge specification directly attached to a label is always preferred. If no algorithm is specified a merge assignment for the label name and its version is evaluated. The assignment hint is composed with\nlabel:\u0026lt;*label name*\u003e@%lt;version\u003e The label version is defaulted to v1.\nSupported Merge Algorithms There are some built-in algorithms featuring a flat name. But it will be possible to add arbitrary algorithms using the plugin concept.\nThe following algorithms are possible:\ndefault (default): This handler merges arbitrary label values by deciding for one or none side.\nIt supports the following config structure:\noverwrite string (optional) determines how to handle conflicts.\nnone no change possible, if entry differs the merge is rejected. local the local value is preserved. inbound (default) the inbound value overwrites the local one. mapListMerge: This handler merges values with a list of map values by observing a key field to identify similar map entries. The default entry key is taken from map field name.\nIt supports the following config structure:\nkeyField string (optional)\nthe key field to identify entries in the maps.\noverwrite string (optional) determines how to handle conflicts.\nnone (default) no change possible, if entry differs the merge is rejected. local the local value is preserved. inbound the inbound value overwrites the local one. *entries merge spec (optional)\nThe merge specification (algorithm and config) used to merge conflicting changes in list entries.\nsimpleListMerge: This handler merges simple list labels values.\nIt supports the following config structure:\noverwrite string (optional) determines how to handle conflicts. simpleMapMerge: This handler merges simple map labels values.\nIt supports the following config structure:\noverwrite string (optional) determines how to handle conflicts.\nnone (default) no change possible, if entry differs the merge is rejected. local the local value is preserved. inbound the inbound value overwrites the local one. *entries merge spec (optional)\nThe merge specification (algorithm and config) used to merge conflicting changes in map entries.\nThe following label assignments are configured:\nlabel:routing-slips: simpleMapMerge See Also ","date":"0001-01-01","id":95,"permalink":"/docs/cli-reference/help/ocm-labels/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eLabels are a set of arbitrary properties, which can be attached to elements\nof a component version:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ea component version itself\u003c/li\u003e\n\u003cli\u003ethe provider of a component version\u003c/li\u003e\n\u003cli\u003eresources\u003c/li\u003e\n\u003cli\u003esources\u003c/li\u003e\n\u003cli\u003ecomponent references\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe dedicated elements support this by providing a field \u003ccode\u003elabels\u003c/code\u003e,\nwhich is a list of label definitions. Every label definition has several fields:\u003c/p\u003e","tags":[],"title":"ocm-labels"},{"content":"Description An OCM repository can be configured to propagate change events via a publish/subscribe system, if there is a persistence provider for the dedicated repository type. If available any known publish/subscribe system can be configured with ocm set pubsub and shown with ocm get pubsub. Hereby, the pub/sub system is described by a typed specification.\nThe following list describes the supported publish/subscribe system types, their specification versions, and formats:\nPubSub type compound\nA pub/sub system forwarding events to described sub-level systems.\nThe following versions are supported:\nVersion v1\nIt is described by the following field:\nspecifications list of pubsub specs\nA list of nested sub-level specifications the events should be forwarded to.\nPubSub type redis\na redis pubsub system.\nThe following versions are supported:\nVersion v1\nIt is describe by the following field:\nserverAddr Address of redis server\nchannel pubsub channel\ndatabase database number\nPublishing using the redis pubsub API. For every change a string message with the format : is published. If multiple repositories should be used, each repository should be configured with a different channel.\nThere are persistence providers for the following repository types:\nOCIRegistry See Also ","date":"0001-01-01","id":96,"permalink":"/docs/cli-reference/help/ocm-pubsub/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAn OCM repository can be configured to propagate change events via a\npublish/subscribe system, if there is a persistence provider for the dedicated\nrepository type. If available any known publish/subscribe system can\nbe configured with \u003ca href=\"/docs/cli-reference/set/pubsub/\"\u003eocm set pubsub\u003c/a\u003e and shown with\n\u003ca href=\"/docs/cli-reference/get/pubsub/\"\u003eocm get pubsub\u003c/a\u003e. Hereby, the pub/sub system\nis described by a typed specification.\u003c/p\u003e","tags":[],"title":"ocm-pubsub"},{"content":"Description The command line client supports a special notation scheme for specifying references to OCM components and repositories. This allows for specifying references to any registry supported by the OCM toolset that can host OCM components:\n[+][\u0026lt;type\u003e::][./]\u0026lt;file path\u003e//\u0026lt;component id\u003e[:\u0026lt;version\u003e] or\n[+][\u0026lt;type\u003e::][\u0026lt;json repo spec\u003e//]\u0026lt;component id\u003e[:\u0026lt;version\u003e] or\n[+][\u0026lt;type\u003e::][\u0026lt;scheme\u003e://]\u0026lt;domain\u003e[:\u0026lt;port\u003e][/\u0026lt;repository prefix\u003e]//\u0026lt;component id\u003e[:\u0026lt;version] or\n[+][\u0026lt;type\u003e::][\u0026lt;scheme\u003e://]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;repository prefix\u003e]//\u0026lt;component id\u003e[:\u0026lt;version] Besides dedicated components it is also possible to denote repositories as a whole:\n[+][\u0026lt;type\u003e::][./]\u0026lt;file path\u003e or\n[+][\u0026lt;type\u003e::]\u0026lt;json repo spec\u003e or\n[+][\u0026lt;type\u003e::][\u0026lt;scheme\u003e://]\u0026lt;domain\u003e[:\u0026lt;port\u003e][/\u0026lt;repository prefix\u003e] or\n[+][\u0026lt;type\u003e::][\u0026lt;scheme\u003e://]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;repository prefix\u003e] The optional + is used for file based implementations (Common Transport Format) to indicate the creation of a not yet existing file.\nThe type may contain a file format qualifier separated by a + character. The following formats are supported: directory, tar, tgz\nExamples Complete Component Reference Specifications (including all optional arguments): +ctf+directory::./ocm/ctf//ocm.software/ocmcli:0.7.0 oci::{\u0026#34;baseUrl\u0026#34;:\u0026#34;ghcr.io\u0026#34;,\u0026#34;componentNameMapping\u0026#34;:\u0026#34;urlPath\u0026#34;,\u0026#34;subPath\u0026#34;:\u0026#34;open-component-model\u0026#34;}//ocm.software/ocmcli.0.7.0 oci::https://ghcr.io:443/open-component-model//ocm.software/ocmcli:0.7.0 oci::http://localhost:8080/local-component-repository//ocm.software/ocmcli:0.7.0 --- Short-Hand Component Reference Specifications (omitting optional arguments): ./ocm/ctf//ocm.software/ocmcli:0.7.0 ghcr.io/open-component-model//ocm.software/ocmcli:0.7.0 localhost:8080/local-component-repository//ocm.software/ocmcli:0.7.0 (defaulting to https) http://localhost:8080/local-component-repository//ocm.software/ocmcli:0.7.0\rSee Also ","date":"0001-01-01","id":97,"permalink":"/docs/cli-reference/help/ocm-references/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eThe command line client supports a special notation scheme for specifying\nreferences to OCM components and repositories. This allows for specifying\nreferences to any registry supported by the OCM toolset that can host OCM\ncomponents:\u003c/p\u003e","tags":[],"title":"ocm-references"},{"content":"Description An upload handler is used to process resources using the access method localBlob transferred into an OCM repository. They may decide to store the content in some other storage repository. This may be an additional storage location or it may replace the storage of the resource as local blob. If an additional storage location is chosen, the local access method is kept and the additional location can be registered in the component descriptor as globalAccess attribute of the local access specification.\nFor example, there is a default upload handler responsible for OCI artifact blobs, which provides regular OCI artifacts for a local blob, if the target OCM repository is based on an OCI registry. Hereby, the referenceName attribute will be used to calculate a meaningful OCI repository name based on the repository prefix of the OCM repository (parallel to component-descriptors prefix used to store the component descriptor artifacts).\nHandler Registration Programmatically any kind of handlers can be registered for various upload conditions. But this feature is available as command-line option, also. New handlers can be provided by plugins. In general available handlers, plugin-based or as part of the CLI coding are nameable using an hierarchical namespace. Those names can be used by a \u0026ndash;uploader option to register handlers for various conditions for CLI commands like ocm transfer componentversions or ocm transfer commontransportarchive.\nBesides the activation constraints (resource type and media type of the resource blob), it is possible to pass a target configuration controlling the exact behaviour of the handler for selected artifacts.\nThe following handler names are possible:\nocm/mavenPackage: uploading maven artifacts\nThe ocm/mavenPackage uploader is able to upload maven artifacts (whole GAV only!) as artifact archive according to the maven artifact spec. If registered the default mime type is: application/x-tgz\nIt accepts a plain string for the URL or a config with the following field: \u0026lsquo;url\u0026rsquo;: the URL of the maven repository.\nocm/npmPackage: uploading npm artifacts\nThe ocm/npmPackage uploader is able to upload npm artifacts as artifact archive according to the npm package spec. If registered the default mime type is: application/x-tgz\nIt accepts a plain string for the URL or a config with the following field: \u0026lsquo;url\u0026rsquo;: the URL of the npm repository.\nocm/ociArtifacts: downloading OCI artifacts\nThe ociArtifacts downloader is able to download OCI artifacts as artifact archive according to the OCI distribution spec. The following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar application/vnd.oci.image.manifest.v1+tar+gzip application/vnd.oci.image.index.v1+tar application/vnd.oci.image.index.v1+tar+gzip application/vnd.docker.distribution.manifest.v2+tar application/vnd.docker.distribution.manifest.v2+tar+gzip application/vnd.docker.distribution.manifest.list.v2+tar application/vnd.docker.distribution.manifest.list.v2+tar+gzip By default, it is registered for these mimetypes.\nIt accepts a config with the following fields:\nnamespacePrefix: a namespace prefix used for the uploaded artifacts ociRef: an OCI repository reference repository: an OCI repository specification for the target OCI registry Alternatively, a single string value can be given representing an OCI repository reference.\nplugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\nSee ocm ocm-uploadhandlers for further details on using upload handlers.\nSee Also ","date":"0001-01-01","id":98,"permalink":"/docs/cli-reference/help/ocm-uploadhandlers/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAn upload handler is used to process resources using the access method\n\u003ccode\u003elocalBlob\u003c/code\u003e transferred into an OCM\nrepository. They may decide to store the content in some other\nstorage repository. This may be an additional storage location or it\nmay replace the storage of the resource as local blob.\nIf an additional storage location is chosen, the local access method\nis kept and the additional location can be registered in the component\ndescriptor as \u003ccode\u003eglobalAccess\u003c/code\u003e attribute of the local access\nspecification.\u003c/p\u003e","tags":[],"title":"ocm-uploadhandlers"},{"content":"Usage ocm describe package [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;} {\u0026lt;resource id field\u0026gt;}\rOptions -h, --help help for package --lookup stringArray repository name or spec for closure lookup fallback --repo string repository name or spec\rDescription Describe a TOI package provided by a resource of an OCM component version.\nThe package resource must have the type toiPackage. This is a simple YAML file resource describing the bootstrapping of a dedicated kind of software. See also the topic ocm toi-bootstrapping.\nThe first matching resource of this type is selected. Optionally a set of identity attribute can be specified used to refine the match. This can be the resource name and/or other key/value pairs (\u0026lt;attr\u0026gt;=\u0026lt;value\u0026gt;).\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry If a component lookup for building a reference closure is required the \u0026ndash;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.\nExamples $ ocm toi describe package ghcr.io/mandelsoft/ocm//ocmdemoinstaller:0.0.1-dev\rSee Also ocm describe\t— Describe various elements by using appropriate sub commands. ","date":"0001-01-01","id":99,"permalink":"/docs/cli-reference/describe/package/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm describe package [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;} {\u0026lt;resource id field\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for package\n --lookup stringArray repository name or spec for closure lookup fallback\n --repo string repository name or spec\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eDescribe a TOI package provided by a resource of an OCM component version.\u003c/p\u003e","tags":[],"title":"package"},{"content":"Usage ocm describe plugins [\u0026lt;options\u0026gt;] {\u0026lt;plugin name\u0026gt;}\rOptions -h, --help help for plugins\rDescription Describes provides comprehensive information about the capabilities of a plugin.\nExamples $ ocm describe plugins $ ocm describe plugins demo\rSee Also ocm describe\t— Describe various elements by using appropriate sub commands. ","date":"0001-01-01","id":100,"permalink":"/docs/cli-reference/describe/plugins/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm describe plugins [\u0026lt;options\u0026gt;] {\u0026lt;plugin name\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for plugins\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eDescribes provides comprehensive information about the capabilities of\na plugin.\u003c/p\u003e","tags":[],"title":"plugins"},{"content":"Usage ocm get plugins [\u0026lt;options\u0026gt;] {\u0026lt;plugin name\u0026gt;}\rOptions -h, --help help for plugins -o, --output string output mode (JSON, json, wide, yaml) -s, --sort stringArray sort fields\rDescription Get lists information for all plugins specified, if no plugin is specified all registered ones are listed.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json wide yaml Examples $ ocm get plugins $ ocm get plugins demo -o yaml\rSee Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":101,"permalink":"/docs/cli-reference/get/plugins/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get plugins [\u0026lt;options\u0026gt;] {\u0026lt;plugin name\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for plugins\n -o, --output string output mode (JSON, json, wide, yaml)\n -s, --sort stringArray sort fields\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eGet lists information for all plugins specified, if no plugin is specified\nall registered ones are listed.\u003c/p\u003e","tags":[],"title":"plugins"},{"content":"Usage ocm get pubsub {\u0026lt;ocm repository\u0026gt;}\rOptions -h, --help help for pubsub -o, --output string output mode (JSON, json, yaml) -s, --sort stringArray sort fields\rDescription A repository may be able to store a publish/subscribe specification to propagate the creation or update of component versions. If such an implementation is available and a specification is assigned to the repository, it is shown. The specification can be set with the ocm set pubsub.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json yaml See Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":102,"permalink":"/docs/cli-reference/get/pubsub/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get pubsub {\u0026lt;ocm repository\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for pubsub\n -o, --output string output mode (JSON, json, yaml)\n -s, --sort stringArray sort fields\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eA repository may be able to store a publish/subscribe specification\nto propagate the creation or update of component versions.\nIf such an implementation is available and a specification is\nassigned to the repository, it is shown. The specification\ncan be set with the \u003ca href=\"/docs/cli-reference/set/pubsub/\"\u003eocm set pubsub\u003c/a\u003e.\u003c/p\u003e","tags":[],"title":"pubsub"},{"content":"Usage ocm set pubsub {\u0026lt;ocm repository\u0026gt;} [\u0026lt;pub/sub specification\u0026gt;]\rOptions -d, --delete delete pub/sub configuration -h, --help help for pubsub\rDescription A repository may be able to store a publish/subscribe specification to propagate the creation or update of component versions. If such an implementation is available this command can be used to set the pub/sub specification for a repository. If no specification is given an existing specification will be removed for the given repository. The specification can be queried with the ocm get pubsub. Types and specification formats are shown for the topic ocm ocm-pubsub.\nSee Also ocm set\t— Set information about OCM repositories ","date":"0001-01-01","id":103,"permalink":"/docs/cli-reference/set/pubsub/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm set pubsub {\u0026lt;ocm repository\u0026gt;} [\u0026lt;pub/sub specification\u0026gt;]\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -d, --delete delete pub/sub configuration\n -h, --help help for pubsub\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eA repository may be able to store a publish/subscribe specification\nto propagate the creation or update of component versions.\nIf such an implementation is available this command can be used\nto set the pub/sub specification for a repository.\nIf no specification is given an existing specification\nwill be removed for the given repository.\nThe specification\ncan be queried with the \u003ca href=\"/docs/cli-reference/get/pubsub/\"\u003eocm get pubsub\u003c/a\u003e.\nTypes and specification formats are shown for the topic\n\u003ca href=\"/docs/cli-reference/help/ocm-pubsub/\"\u003eocm ocm-pubsub\u003c/a\u003e.\u003c/p\u003e","tags":[],"title":"pubsub"},{"content":"Usage ocm add references [\u0026lt;options\u0026gt;] [\u0026lt;target\u0026gt;] {\u0026lt;referencefile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\rOptions --addenv access environment for templating --component string component name --dry-run evaluate and print reference specifications --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; reference extra identity (default []) -F, --file string target file/directory (default \u0026#34;component-archive\u0026#34;) -h, --help help for references --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; reference label (leading * indicates signature relevant, optional version separated by @) --name string reference name -O, --output string output file for dry-run -P, --preserve-signature preserve existing signatures --reference YAML reference meta data (yaml) -R, --replace replace existing elements -s, --settings stringArray settings file with variable settings (yaml) --templater string templater to use (go, none, spiff, subst) (default \u0026#34;subst\u0026#34;) --version string reference version\rDescription Add aggregation information specified in a reference file to a component version. So far only component archives are supported as target.\nThis command accepts reference specification files describing the references to add to a component version. Elements must follow the reference meta data description scheme of the component descriptor.\nThe description file might contain:\na single reference a list of references under the key references a list of yaml documents with a single reference or reference list It is possible to describe a single reference via command line options. The meta data of this element is described by the argument of option \u0026ndash;reference, which must be a YAML or JSON string. Alternatively, the name and version can be specified with the options \u0026ndash;name and \u0026ndash;version. With the option \u0026ndash;extra it is possible to add extra identity attributes. Explicitly specified options override values specified by the \u0026ndash;reference option. (Note: Go templates are not supported for YAML-based option values. Besides this restriction, the finally composed element description is still processed by the selected template engine.)\nThe component name can be specified with the option \u0026ndash;component. Therefore, basic references not requiring any additional labels or extra identities can just be specified by those simple value options without the need for the YAML option.\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" The \u0026ndash;replace option allows users to specify whether adding an element with the same name and extra identity but different version as an existing element, append (false) or replace (true) the existing element.\nThe \u0026ndash;preserve-signature option prohibits changes of signature relevant elements.\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" Examples Add a reference directly by options $ ocm add references --file path/to/ca --name myref --component github.com/my/component --version ${VERSION} Add a reference by a description file: *references.yaml*: --- name: myref component: github.com/my/component version: ${VERSION] $ ocm add references path/to/ca references.yaml VERSION=1.0.0\rSee Also ocm add\t— Add elements to a component repository or component version ","date":"0001-01-01","id":104,"permalink":"/docs/cli-reference/add/references/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm add references [\u0026lt;options\u0026gt;] [\u0026lt;target\u0026gt;] {\u0026lt;referencefile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --addenv access environment for templating\n --component string component name\n --dry-run evaluate and print reference specifications\n --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; reference extra identity (default [])\n -F, --file string target file/directory (default \u0026#34;component-archive\u0026#34;)\n -h, --help help for references\n --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; reference label (leading * indicates signature relevant, optional version separated by @)\n --name string reference name\n -O, --output string output file for dry-run\n -P, --preserve-signature preserve existing signatures\n --reference YAML reference meta data (yaml)\n -R, --replace replace existing elements\n -s, --settings stringArray settings file with variable settings (yaml)\n --templater string templater to use (go, none, spiff, subst) (default \u0026#34;subst\u0026#34;)\n --version string reference version\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAdd aggregation information specified in a reference file to a component version.\nSo far only component archives are supported as target.\u003c/p\u003e","tags":[],"title":"references"},{"content":"Usage ocm get references [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}\rOptions -c, --constraints constraints version constraint -h, --help help for references --latest restrict component versions to latest --lookup stringArray repository name or spec for closure lookup fallback -o, --output string output mode (JSON, json, tree, wide, yaml) -r, --recursive follow component reference nesting --repo string repository name or spec -s, --sort stringArray sort fields\rDescription Get references of a component version. References are specified by identities. An identity consists of a name argument followed by optional \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; arguments.\nIf the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry With the option \u0026ndash;recursive the complete reference tree of a component reference is traversed.\nIf a component lookup for building a reference closure is required the \u0026ndash;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.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json tree wide yaml See Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":105,"permalink":"/docs/cli-reference/get/references/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get references [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -c, --constraints constraints version constraint\n -h, --help help for references\n --latest restrict component versions to latest\n --lookup stringArray repository name or spec for closure lookup fallback\n -o, --output string output mode (JSON, json, tree, wide, yaml)\n -r, --recursive follow component reference nesting\n --repo string repository name or spec\n -s, --sort stringArray sort fields\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eGet references of a component version. References are specified\nby identities. An identity consists of\na name argument followed by optional \u003ccode\u003e\u0026lt;key\u0026gt;=\u0026lt;value\u0026gt;\u003c/code\u003e\narguments.\u003c/p\u003e","tags":[],"title":"references"},{"content":"Usage ocm add resource-configuration [\u0026lt;options\u0026gt;] \u0026lt;target\u0026gt; {\u0026lt;configfile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\rOptions --access YAML blob access specification (YAML) --accessComponent string component for access specification --accessHostname string hostname used for access --accessRepository string repository or registry URL --accessType string type of blob access specification --accessVersion string version for access specification --artifactId string maven artifact id --body string body of a http request --bucket string bucket name --classifier string maven classifier --commit string git commit id --digest string blob digest --extension string maven extension name --external flag non-local resource --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; resource extra identity (default []) --globalAccess YAML access specification for global access --groupId string maven group id --header \u0026lt;name\u0026gt;:\u0026lt;value\u0026gt;,\u0026lt;value\u0026gt;,... http headers (default {}) -h, --help help for resource-configuration --hint string (repository) hint for local artifacts --identityPath {\u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;} identity path for specification --input YAML blob input specification (YAML) --inputComponent string component name --inputCompress compress option for input --inputData !bytesBase64 data (string, !!string or !\u0026lt;base64\u0026gt; --inputExcludes stringArray excludes (path) for inputs --inputFollowSymlinks follow symbolic links during archive creation for inputs --inputFormattedJson YAML JSON formatted text --inputHelmRepository string helm repository base URL --inputIncludes stringArray includes (path) for inputs --inputJson YAML JSON formatted text --inputLibraries stringArray library path for inputs --inputPath filepath path field for input --inputPlatforms stringArray input filter for image platforms ([os]/[architecture]) --inputPreserveDir preserve directory in archive for inputs --inputRepository string repository or registry for inputs --inputText string utf8 text --inputType string type of blob input specification --inputValues YAML YAML based generic values for inputs --inputVariants stringArray (platform) variants for inputs --inputVersion string version info for inputs --inputYaml YAML YAML formatted text --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; resource label (leading * indicates signature relevant, optional version separated by @) --mediaType string media type for artifact blob representation --name string resource name --noredirect http redirect behavior --package string package or object name --reference string reference name --region string region name --resource YAML resource meta data (yaml) -s, --settings stringArray settings file with variable settings (yaml) --size int blob size --type string resource type --url string artifact or server url --verb string http request method --version string resource version\rDescription Add a resource specification to a resource config file used by ocm add resources.\nIt is possible to describe a single resource via command line options. The meta data of this element is described by the argument of option \u0026ndash;resource, which must be a YAML or JSON string. Alternatively, the name and version can be specified with the options \u0026ndash;name and \u0026ndash;version. With the option \u0026ndash;extra it is possible to add extra identity attributes. Explicitly specified options override values specified by the \u0026ndash;resource option. (Note: Go templates are not supported for YAML-based option values. Besides this restriction, the finally composed element description is still processed by the selected template engine.)\nThe resource type can be specified with the option \u0026ndash;type. Therefore, the minimal required meta data for elements can be completely specified by dedicated options and don\u0026rsquo;t need the YAML option.\nTo describe the content of this element one of the options \u0026ndash;access or \u0026ndash;input must be given. They take a YAML or JSON value describing an attribute set, also. The structure of those values is similar to the access or input fields of the description file format. Non-local resources can be indicated using the option \u0026ndash;external. Elements must follow the resource meta data description scheme of the component descriptor.\nIf expressions/templates are used in the specification file an appropriate templater and the required settings might be required to provide a correct input validation.\nThis command accepts additional resource specification files describing the sources to add to a component version.\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" The resource specification supports the following blob input types, specified with the field type in the input field:\nInput type binary\nThis blob type is used to provide base64 encoded binary content. The specification supports the following fields:\ndata []byte\nThe binary data to provide.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputData, \u0026ndash;mediaType\nInput type dir\nThe path must denote a directory relative to the resources file, which is packed with tar and optionally compressed if the compress field is set to true. If the field preserveDir is set to true the directory itself is added to the tar. If the field followSymLinks is set to true, symbolic links are not packed but their targets files or folders. With the list fields includeFiles and excludeFiles it is possible to specify which files should be included or excluded. The values are regular expression used to match relative file paths. If no includes are specified all file not explicitly excluded are used.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the file path to directory relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/x-tar and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the file content should be stored compressed or not.\npreserveDir bool\nThis OPTIONAL property describes whether the specified directory with its basename should be included as top level folder.\nfollowSymlinks bool\nThis OPTIONAL property describes whether symbolic links should be followed or included as links.\nexcludeFiles list of regex\nThis OPTIONAL property describes regular expressions used to match files that should NOT be included in the tar file. It takes precedence over the include match.\nincludeFiles list of regex\nThis OPTIONAL property describes regular expressions used to match files that should be included in the tar file. If this option is not given all files not explicitly excluded are used.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputExcludes, \u0026ndash;inputFollowSymlinks, \u0026ndash;inputIncludes, \u0026ndash;inputPath, \u0026ndash;inputPreserveDir, \u0026ndash;mediaType\nInput type docker\nThe path must denote an image tag that can be found in the local docker daemon. The denoted image is packed as OCI artifact set. The OCI image will contain an informational back link to the component version using the manifest annotation software.ocm/component-version.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the image name to import from the local docker daemon.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputPath\nInput type dockermulti\nThis input type describes the composition of a multi-platform OCI image. The various variants are taken from the local docker daemon. They should be built with the \u0026ldquo;buildx\u0026rdquo; command for cross platform docker builds (see https://ocm.software/docs/tutorials/best-practices/#building-multi-architecture-images). The denoted images, as well as the wrapping image index, are packed as OCI artifact set. They will contain an informational back link to the component version using the manifest annotation software.ocm/component-version.\nThis blob type specification supports the following fields:\nvariants []string\nThis REQUIRED property describes a set of image names to import from the local docker daemon used to compose a resulting image index.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputVariants\nInput type file\nThe path must denote a file relative the resources file. The content is compressed if the compress field is set to true.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the path to the file relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;mediaType\nInput type helm\nThe path must denote an helm chart archive or directory relative to the resources file or a chart name in a helm chart repository. The denoted chart is packed as an OCI artifact set. For the filesystem version additional provider info is taken from a file with the same name and the suffix .prov.\nIf the chart should just be stored as plain archive, please use the type file or dir, instead.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the file path to the helm chart relative to the resource file location.\nversion string\nThis OPTIONAL property can be set to configure an explicit version hint. If not specified the version from the chart will be used. Basically, it is a good practice to use the component version for local resources This can be achieved by using templating for this attribute in the resource file.\nhelmRepository string\nThis OPTIONAL property can be set, if the helm chart should be loaded from a helm repository instead of the local filesystem. It describes the base URL of the chart repository. If specified, the path field must describe the name of the chart in the chart repository, and version must describe the version of the chart imported from the chart repository\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\ncaCertFile string\nThis OPTIONAL property can be used to specify a relative filename for the TLS root certificate used to access a helm repository.\ncaCert string\nThis OPTIONAL property can be used to specify a TLS root certificate used to access a helm repository.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputHelmRepository, \u0026ndash;inputPath, \u0026ndash;inputVersion, \u0026ndash;mediaType\nInput type maven\nThe repoUrl is the url pointing either to the http endpoint of a maven repository (e.g. https://repo.maven.apache.org/maven2/) or to a file system based maven repository (e.g. file://local/directory).\nThis blob type specification supports the following fields:\nrepoUrl string\nThis REQUIRED property describes the url from which the resource is to be accessed.\ngroupId string\nThis REQUIRED property describes the groupId of a maven artifact.\nartifactId string\nThis REQUIRED property describes artifactId of a maven artifact.\nversion string\nThis REQUIRED property describes the version of a maven artifact.\nclassifier string\nThis OPTIONAL property describes the classifier of a maven artifact.\nextension string\nThis OPTIONAL property describes the extension of a maven artifact.\nOptions used to configure fields: \u0026ndash;artifactId, \u0026ndash;classifier, \u0026ndash;extension, \u0026ndash;groupId, \u0026ndash;inputPath, \u0026ndash;inputVersion, \u0026ndash;url\nInput type npm\nThe registry is the url pointing to the npm registry from which a resource is downloaded.\nThis blob type specification supports the following fields:\nregistry string\nThis REQUIRED property describes the url from which the resource is to be downloaded.\npackage string\nThis REQUIRED property describes the name of the package to download.\nversion string\nThis is an OPTIONAL property describing the version of the package to download. If not defined, latest will be used automatically.\nOptions used to configure fields: \u0026ndash;inputRepository, \u0026ndash;inputVersion, \u0026ndash;package\nInput type ociArtifact\nThis input type is used to import an OCI image from an OCI registry. If it is a multi-arch image the set of platforms to be imported can be filtered using the \u0026ldquo;platforms\u0026rdquo; attribute. The path must denote an OCI image reference.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the OCI image reference of the image to import.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nplatforms []string\nThis OPTIONAL property can be used to filter index artifacts to include only images for dedicated operating systems/architectures. Elements must meet the syntax [\u0026lt;os\u0026gt;]/[\u0026lt;architecture\u0026gt;].\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;inputPlatforms, \u0026ndash;mediaType\nInput type ociImage\nDEPRECATED: This type is deprecated, please use ociArtifact instead.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;inputPlatforms, \u0026ndash;mediaType\nInput type ocm\nThis input type allows to get a resource artifact from an OCM repository.\nThis blob type specification supports the following fields:\nocmRepository repository specification\nThis REQUIRED property describes the OCM repository specification\ncomponent string\nThis REQUIRED property describes the component na,e\nversion string\nThis REQUIRED property describes the version of a maven artifact.\nresourceRef relative resource reference\nThis REQUIRED property describes the resource reference for the desired resource relative to the given component version .\nOptions used to configure fields: \u0026ndash;identityPath, \u0026ndash;inputComponent, \u0026ndash;inputRepository, \u0026ndash;inputVersion\nInput type spiff\nThe path must denote a spiff template relative the resources file. The content is compressed if the compress field is set to true.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the path to the file relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nvalues map[string]any\nThis OPTIONAL property describes an additional value binding for the template processing. It will be available under the node inputvalues.\nlibraries []string\nThis OPTIONAL property describes a list of spiff libraries to include in template processing.\nThe variable settings from the command line are available as binding, also. They are provided under the node values.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputLibraries, \u0026ndash;inputPath, \u0026ndash;inputValues, \u0026ndash;mediaType\nInput type utf8\nThis blob type is used to provide inline text based content (UTF8). The specification supports the following fields:\ntext string\nThe utf8 string content to provide.\njson JSON or JSON string interpreted as JSON\nThe content emitted as JSON.\nformattedJson YAML/JSON or JSON/YAML string interpreted as JSON\nThe content emitted as formatted JSON.\nyaml AML/JSON or JSON/YAML string interpreted as YAML\nThe content emitted as YAML.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputFormattedJson, \u0026ndash;inputJson, \u0026ndash;inputText, \u0026ndash;inputYaml, \u0026ndash;mediaType\nInput type wget\nThe url is the url pointing to the http endpoint from which a resource is downloaded. The mimeType can be used to specify the MIME type of the resource.\nThis blob type specification supports the following fields:\nurl string\nThis REQUIRED property describes the url from which the resource is to be downloaded.\nmediaType string\nThis OPTIONAL property describes the media type of the resource to be downloaded. If omitted, ocm tries to read the mediaType from the Content-Type header of the http response. If the mediaType cannot be set from the Content-Type header as well, ocm tries to deduct the mediaType from the URL. If that is not possible either, the default media type is defaulted to application/octet-stream.\nheader map[string][]string\nThis OPTIONAL property describes the http headers to be set in the http request to the server.\nverb string\nThis OPTIONAL property describes the http verb (also known as http request method) for the http request. If omitted, the http verb is defaulted to GET.\nbody []byte\nThis OPTIONAL property describes the http body to be included in the request.\nnoredirect bool\nThis OPTIONAL property describes whether http redirects should be disabled. If omitted, it is defaulted to false (so, per default, redirects are enabled).\nOptions used to configure fields: \u0026ndash;body, \u0026ndash;header, \u0026ndash;mediaType, \u0026ndash;noredirect, \u0026ndash;url, \u0026ndash;verb\nThe following list describes the supported access methods, their versions and specification formats. Typically there is special support for the CLI artifact add commands. The access method specification can be put below the access field. If always requires the field type describing the kind and version shown below.\nAccess type gitHub\nThis method implements the access of the content of a git commit stored in a GitHub repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nRepository URL with or without scheme.\nref (optional) string\nOriginal ref used to get the commit from\ncommit string\nThe sha/id of the git commit\nOptions used to configure fields: \u0026ndash;accessHostname, \u0026ndash;accessRepository, \u0026ndash;commit\nAccess type helm\nThis method implements the access of a Helm chart stored in a Helm repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nhelmRepository string\nHelm repository URL.\nhelmChart string\nThe name of the Helm chart and its version separated by a colon.\nversion string\nThe version of the Helm chart if not specified as part of the chart name.\ncaCert string\nAn optional TLS root certificate.\nkeyring string\nAn optional keyring used to verify the chart.\nIt uses the consumer identity type HelmChartRepository with the fields for a hostpath identity matcher (see ocm get credentials).\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type localBlob\nThis method is used to store a resource blob along with the component descriptor on behalf of the hosting OCM repository.\nIts implementation is specific to the implementation of OCM repository used to read the component descriptor. Every repository implementation may decide how and where local blobs are stored, but it MUST provide an implementation for this method.\nRegardless of the chosen implementation the attribute specification is defined globally the same.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nlocalReference string\nRepository type specific location information as string. The value may encode any deep structure, but typically just an access path is sufficient.\nmediaType string\nThe media type of the blob used to store the resource. It may add format information like +tar or +gzip.\nreferenceName (optional) string\nThis optional attribute may contain identity information used by other repositories to restore some global access with an identity related to the original source.\nFor example, if an OCI artifact originally referenced using the access method ociArtifact is stored during some transport step as local artifact, the reference name can be set to its original repository name. An import step into an OCI based OCM repository may then decide to make this artifact available again as regular OCI artifact.\nglobalAccess (optional) access method specification\nIf a resource blob is stored locally, the repository implementation may decide to provide an external access information (independent of the OCM model).\nFor example, an OCI artifact stored as local blob can be additionally stored as regular OCI artifact in an OCI registry.\nThis additional external access information can be added using a second external access method specification.\nOptions used to configure fields: \u0026ndash;globalAccess, \u0026ndash;hint, \u0026ndash;mediaType, \u0026ndash;reference\nAccess type maven\nThis method implements the access of a Maven artifact in a Maven repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nURL of the Maven repository\ngroupId string\nThe groupId of the Maven artifact\nartifactId string\nThe artifactId of the Maven artifact\nversion string\nThe version name of the Maven artifact\nclassifier string\nThe optional classifier of the Maven artifact\nextension string\nThe optional extension of the Maven artifact\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;artifactId, \u0026ndash;classifier, \u0026ndash;extension, \u0026ndash;groupId\nAccess type none\ndummy resource with no access\nAccess type npm\nThis method implements the access of an NPM package in an NPM registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregistry string\nBase URL of the NPM registry.\npackage string\nThe name of the NPM package\nversion string\nThe version name of the NPM package\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type ociArtifact\nThis method implements the access of an OCI artifact stored in an OCI registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI image/artifact reference following the possible docker schemes:\n\u0026lt;repo\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;digest\u0026gt;@\u0026lt;tag\u0026gt; [\u0026lt;port\u0026gt;]/\u0026lt;repo path\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;version\u0026gt;@\u0026lt;tag\u0026gt; Options used to configure fields: \u0026ndash;reference\nAccess type ociBlob\nThis method implements the access of an OCI blob stored in an OCI repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI repository reference (this artifact name used to store the blob).\nmediaType string\nThe media type of the blob\ndigest string\nThe digest of the blob used to access the blob in the OCI repository.\nsize integer\nThe size of the blob\nOptions used to configure fields: \u0026ndash;digest, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;size\nAccess type ocm\nThis method implements the access of any resource artifact stored in an OCM repository. Only repository types supporting remote access should be used.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nocmRepository json\nThe repository spec for the OCM repository\ncomponent string\n(Optional) The name of the component. The default is the own component.\nversion string\n(Optional) The version of the component. The default is the own component version.\nresourceRef relative resource ref\nThe resource reference of the denoted resource relative to the given component version.\nIt uses the consumer identity and credentials for the intermediate repositories and the final resource access.\nOptions used to configure fields: \u0026ndash;accessComponent, \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;identityPath\nAccess type s3\nThis method implements the access of a blob stored in an S3 bucket.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucket string\nThe name of the S3 bucket containing the blob\nkey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nVersion v2\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucketName string\nThe name of the S3 bucket containing the blob\nobjectKey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nOptions used to configure fields: \u0026ndash;accessVersion, \u0026ndash;bucket, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;region\nAccess type wget\nThis method implements access to resources stored on an http server.\nThe following versions are supported:\nVersion v1\nThe url is the url pointing to the http endpoint from which a resource is downloaded. The mimeType can be used to specify the MIME type of the resource.\nThis blob type specification supports the following fields:\nurl string This REQUIRED property describes the url from which the resource is to be downloaded.\nmediaType string This OPTIONAL property describes the media type of the resource to be downloaded. If omitted, ocm tries to read the mediaType from the Content-Type header of the http response. If the mediaType cannot be set from the Content-Type header as well, ocm tries to deduct the mediaType from the URL. If that is not possible either, the default media type is defaulted to application/octet-stream.\nheader map[string][]string This OPTIONAL property describes the http headers to be set in the http request to the server.\nverb string This OPTIONAL property describes the http verb (also known as http request method) for the http request. If omitted, the http verb is defaulted to GET.\nbody []byte This OPTIONAL property describes the http body to be included in the request.\nnoredirect bool This OPTIONAL property describes whether http redirects should be disabled. If omitted, it is defaulted to false (so, per default, redirects are enabled).\nOptions used to configure fields: \u0026ndash;body, \u0026ndash;header, \u0026ndash;mediaType, \u0026ndash;noredirect, \u0026ndash;url, \u0026ndash;verb\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" Examples $ ocm add resource-configuration resources.yaml --name myresource --type PlainText --input \u0026#39;{ \u0026#34;type\u0026#34;: \u0026#34;file\u0026#34;, \u0026#34;path\u0026#34;: \u0026#34;testdata/testcontent\u0026#34;, \u0026#34;mediaType\u0026#34;: \u0026#34;text/plain\u0026#34; }\u0026#39;\rSee Also ocm add\t— Add elements to a component repository or component version ","date":"0001-01-01","id":106,"permalink":"/docs/cli-reference/add/resource-configuration/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm add resource-configuration [\u0026lt;options\u0026gt;] \u0026lt;target\u0026gt; {\u0026lt;configfile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --access YAML blob access specification (YAML)\n --accessComponent string component for access specification\n --accessHostname string hostname used for access\n --accessRepository string repository or registry URL\n --accessType string type of blob access specification\n --accessVersion string version for access specification\n --artifactId string maven artifact id\n --body string body of a http request\n --bucket string bucket name\n --classifier string maven classifier\n --commit string git commit id\n --digest string blob digest\n --extension string maven extension name\n --external flag non-local resource\n --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; resource extra identity (default [])\n --globalAccess YAML access specification for global access\n --groupId string maven group id\n --header \u0026lt;name\u0026gt;:\u0026lt;value\u0026gt;,\u0026lt;value\u0026gt;,... http headers (default {})\n -h, --help help for resource-configuration\n --hint string (repository) hint for local artifacts\n --identityPath {\u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;} identity path for specification\n --input YAML blob input specification (YAML)\n --inputComponent string component name\n --inputCompress compress option for input\n --inputData !bytesBase64 data (string, !!string or !\u0026lt;base64\u0026gt;\n --inputExcludes stringArray excludes (path) for inputs\n --inputFollowSymlinks follow symbolic links during archive creation for inputs\n --inputFormattedJson YAML JSON formatted text\n --inputHelmRepository string helm repository base URL\n --inputIncludes stringArray includes (path) for inputs\n --inputJson YAML JSON formatted text\n --inputLibraries stringArray library path for inputs\n --inputPath filepath path field for input\n --inputPlatforms stringArray input filter for image platforms ([os]/[architecture])\n --inputPreserveDir preserve directory in archive for inputs\n --inputRepository string repository or registry for inputs\n --inputText string utf8 text\n --inputType string type of blob input specification\n --inputValues YAML YAML based generic values for inputs\n --inputVariants stringArray (platform) variants for inputs\n --inputVersion string version info for inputs\n --inputYaml YAML YAML formatted text\n --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; resource label (leading * indicates signature relevant, optional version separated by @)\n --mediaType string media type for artifact blob representation\n --name string resource name\n --noredirect http redirect behavior\n --package string package or object name\n --reference string reference name\n --region string region name\n --resource YAML resource meta data (yaml)\n -s, --settings stringArray settings file with variable settings (yaml)\n --size int blob size\n --type string resource type\n --url string artifact or server url\n --verb string http request method\n --version string resource version\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAdd a resource specification to a resource config file used by \u003ca href=\"/docs/cli-reference/add/resources/\"\u003eocm add resources\u003c/a\u003e.\u003c/p\u003e","tags":[],"title":"resource-configuration"},{"content":"Usage ocm add resources [\u0026lt;options\u0026gt;] [\u0026lt;target\u0026gt;] {\u0026lt;resourcefile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\rOptions --access YAML blob access specification (YAML) --accessComponent string component for access specification --accessHostname string hostname used for access --accessRepository string repository or registry URL --accessType string type of blob access specification --accessVersion string version for access specification --addenv access environment for templating --artifactId string maven artifact id --body string body of a http request --bucket string bucket name --classifier string maven classifier --commit string git commit id --digest string blob digest --dry-run evaluate and print resource specifications --extension string maven extension name --external flag non-local resource --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; resource extra identity (default []) -F, --file string target file/directory (default \u0026#34;component-archive\u0026#34;) --globalAccess YAML access specification for global access --groupId string maven group id --header \u0026lt;name\u0026gt;:\u0026lt;value\u0026gt;,\u0026lt;value\u0026gt;,... http headers (default {}) -h, --help help for resources --hint string (repository) hint for local artifacts --identityPath {\u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;} identity path for specification --input YAML blob input specification (YAML) --inputComponent string component name --inputCompress compress option for input --inputData !bytesBase64 data (string, !!string or !\u0026lt;base64\u0026gt; --inputExcludes stringArray excludes (path) for inputs --inputFollowSymlinks follow symbolic links during archive creation for inputs --inputFormattedJson YAML JSON formatted text --inputHelmRepository string helm repository base URL --inputIncludes stringArray includes (path) for inputs --inputJson YAML JSON formatted text --inputLibraries stringArray library path for inputs --inputPath filepath path field for input --inputPlatforms stringArray input filter for image platforms ([os]/[architecture]) --inputPreserveDir preserve directory in archive for inputs --inputRepository string repository or registry for inputs --inputText string utf8 text --inputType string type of blob input specification --inputValues YAML YAML based generic values for inputs --inputVariants stringArray (platform) variants for inputs --inputVersion string version info for inputs --inputYaml YAML YAML formatted text --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; resource label (leading * indicates signature relevant, optional version separated by @) --mediaType string media type for artifact blob representation --name string resource name --noredirect http redirect behavior -O, --output string output file for dry-run --package string package or object name -P, --preserve-signature preserve existing signatures --reference string reference name --region string region name -R, --replace replace existing elements --resource YAML resource meta data (yaml) -s, --settings stringArray settings file with variable settings (yaml) --size int blob size --skip-digest-generation skip digest creation --templater string templater to use (go, none, spiff, subst) (default \u0026#34;subst\u0026#34;) --type string resource type --url string artifact or server url --verb string http request method --version string resource version\rDescription Adds resources specified in a resource file to a component version. So far, only component archives are supported as target.\nThis command accepts resource specification files describing the resources to add to a component version. Elements must follow the resource meta data description scheme of the component descriptor. Besides referential resources using the access attribute to describe the access method, it is possible to describe local resources fed by local data using the input field (see below).\nThe description file might contain:\na single resource a list of resources under the key resources a list of yaml documents with a single resource or resource list It is possible to describe a single resource via command line options. The meta data of this element is described by the argument of option \u0026ndash;resource, which must be a YAML or JSON string. Alternatively, the name and version can be specified with the options \u0026ndash;name and \u0026ndash;version. With the option \u0026ndash;extra it is possible to add extra identity attributes. Explicitly specified options override values specified by the \u0026ndash;resource option. (Note: Go templates are not supported for YAML-based option values. Besides this restriction, the finally composed element description is still processed by the selected template engine.)\nThe resource type can be specified with the option \u0026ndash;type. Therefore, the minimal required meta data for elements can be completely specified by dedicated options and don\u0026rsquo;t need the YAML option.\nTo describe the content of this element one of the options \u0026ndash;access or \u0026ndash;input must be given. They take a YAML or JSON value describing an attribute set, also. The structure of those values is similar to the access or input fields of the description file format. Non-local resources can be indicated using the option \u0026ndash;external.\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" The resource specification supports the following blob input types, specified with the field type in the input field:\nInput type binary\nThis blob type is used to provide base64 encoded binary content. The specification supports the following fields:\ndata []byte\nThe binary data to provide.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputData, \u0026ndash;mediaType\nInput type dir\nThe path must denote a directory relative to the resources file, which is packed with tar and optionally compressed if the compress field is set to true. If the field preserveDir is set to true the directory itself is added to the tar. If the field followSymLinks is set to true, symbolic links are not packed but their targets files or folders. With the list fields includeFiles and excludeFiles it is possible to specify which files should be included or excluded. The values are regular expression used to match relative file paths. If no includes are specified all file not explicitly excluded are used.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the file path to directory relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/x-tar and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the file content should be stored compressed or not.\npreserveDir bool\nThis OPTIONAL property describes whether the specified directory with its basename should be included as top level folder.\nfollowSymlinks bool\nThis OPTIONAL property describes whether symbolic links should be followed or included as links.\nexcludeFiles list of regex\nThis OPTIONAL property describes regular expressions used to match files that should NOT be included in the tar file. It takes precedence over the include match.\nincludeFiles list of regex\nThis OPTIONAL property describes regular expressions used to match files that should be included in the tar file. If this option is not given all files not explicitly excluded are used.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputExcludes, \u0026ndash;inputFollowSymlinks, \u0026ndash;inputIncludes, \u0026ndash;inputPath, \u0026ndash;inputPreserveDir, \u0026ndash;mediaType\nInput type docker\nThe path must denote an image tag that can be found in the local docker daemon. The denoted image is packed as OCI artifact set. The OCI image will contain an informational back link to the component version using the manifest annotation software.ocm/component-version.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the image name to import from the local docker daemon.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputPath\nInput type dockermulti\nThis input type describes the composition of a multi-platform OCI image. The various variants are taken from the local docker daemon. They should be built with the \u0026ldquo;buildx\u0026rdquo; command for cross platform docker builds (see https://ocm.software/docs/tutorials/best-practices/#building-multi-architecture-images). The denoted images, as well as the wrapping image index, are packed as OCI artifact set. They will contain an informational back link to the component version using the manifest annotation software.ocm/component-version.\nThis blob type specification supports the following fields:\nvariants []string\nThis REQUIRED property describes a set of image names to import from the local docker daemon used to compose a resulting image index.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputVariants\nInput type file\nThe path must denote a file relative the resources file. The content is compressed if the compress field is set to true.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the path to the file relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;mediaType\nInput type helm\nThe path must denote an helm chart archive or directory relative to the resources file or a chart name in a helm chart repository. The denoted chart is packed as an OCI artifact set. For the filesystem version additional provider info is taken from a file with the same name and the suffix .prov.\nIf the chart should just be stored as plain archive, please use the type file or dir, instead.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the file path to the helm chart relative to the resource file location.\nversion string\nThis OPTIONAL property can be set to configure an explicit version hint. If not specified the version from the chart will be used. Basically, it is a good practice to use the component version for local resources This can be achieved by using templating for this attribute in the resource file.\nhelmRepository string\nThis OPTIONAL property can be set, if the helm chart should be loaded from a helm repository instead of the local filesystem. It describes the base URL of the chart repository. If specified, the path field must describe the name of the chart in the chart repository, and version must describe the version of the chart imported from the chart repository\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\ncaCertFile string\nThis OPTIONAL property can be used to specify a relative filename for the TLS root certificate used to access a helm repository.\ncaCert string\nThis OPTIONAL property can be used to specify a TLS root certificate used to access a helm repository.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputHelmRepository, \u0026ndash;inputPath, \u0026ndash;inputVersion, \u0026ndash;mediaType\nInput type maven\nThe repoUrl is the url pointing either to the http endpoint of a maven repository (e.g. https://repo.maven.apache.org/maven2/) or to a file system based maven repository (e.g. file://local/directory).\nThis blob type specification supports the following fields:\nrepoUrl string\nThis REQUIRED property describes the url from which the resource is to be accessed.\ngroupId string\nThis REQUIRED property describes the groupId of a maven artifact.\nartifactId string\nThis REQUIRED property describes artifactId of a maven artifact.\nversion string\nThis REQUIRED property describes the version of a maven artifact.\nclassifier string\nThis OPTIONAL property describes the classifier of a maven artifact.\nextension string\nThis OPTIONAL property describes the extension of a maven artifact.\nOptions used to configure fields: \u0026ndash;artifactId, \u0026ndash;classifier, \u0026ndash;extension, \u0026ndash;groupId, \u0026ndash;inputPath, \u0026ndash;inputVersion, \u0026ndash;url\nInput type npm\nThe registry is the url pointing to the npm registry from which a resource is downloaded.\nThis blob type specification supports the following fields:\nregistry string\nThis REQUIRED property describes the url from which the resource is to be downloaded.\npackage string\nThis REQUIRED property describes the name of the package to download.\nversion string\nThis is an OPTIONAL property describing the version of the package to download. If not defined, latest will be used automatically.\nOptions used to configure fields: \u0026ndash;inputRepository, \u0026ndash;inputVersion, \u0026ndash;package\nInput type ociArtifact\nThis input type is used to import an OCI image from an OCI registry. If it is a multi-arch image the set of platforms to be imported can be filtered using the \u0026ldquo;platforms\u0026rdquo; attribute. The path must denote an OCI image reference.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the OCI image reference of the image to import.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nplatforms []string\nThis OPTIONAL property can be used to filter index artifacts to include only images for dedicated operating systems/architectures. Elements must meet the syntax [\u0026lt;os\u0026gt;]/[\u0026lt;architecture\u0026gt;].\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;inputPlatforms, \u0026ndash;mediaType\nInput type ociImage\nDEPRECATED: This type is deprecated, please use ociArtifact instead.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;inputPlatforms, \u0026ndash;mediaType\nInput type ocm\nThis input type allows to get a resource artifact from an OCM repository.\nThis blob type specification supports the following fields:\nocmRepository repository specification\nThis REQUIRED property describes the OCM repository specification\ncomponent string\nThis REQUIRED property describes the component na,e\nversion string\nThis REQUIRED property describes the version of a maven artifact.\nresourceRef relative resource reference\nThis REQUIRED property describes the resource reference for the desired resource relative to the given component version .\nOptions used to configure fields: \u0026ndash;identityPath, \u0026ndash;inputComponent, \u0026ndash;inputRepository, \u0026ndash;inputVersion\nInput type spiff\nThe path must denote a spiff template relative the resources file. The content is compressed if the compress field is set to true.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the path to the file relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nvalues map[string]any\nThis OPTIONAL property describes an additional value binding for the template processing. It will be available under the node inputvalues.\nlibraries []string\nThis OPTIONAL property describes a list of spiff libraries to include in template processing.\nThe variable settings from the command line are available as binding, also. They are provided under the node values.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputLibraries, \u0026ndash;inputPath, \u0026ndash;inputValues, \u0026ndash;mediaType\nInput type utf8\nThis blob type is used to provide inline text based content (UTF8). The specification supports the following fields:\ntext string\nThe utf8 string content to provide.\njson JSON or JSON string interpreted as JSON\nThe content emitted as JSON.\nformattedJson YAML/JSON or JSON/YAML string interpreted as JSON\nThe content emitted as formatted JSON.\nyaml AML/JSON or JSON/YAML string interpreted as YAML\nThe content emitted as YAML.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputFormattedJson, \u0026ndash;inputJson, \u0026ndash;inputText, \u0026ndash;inputYaml, \u0026ndash;mediaType\nInput type wget\nThe url is the url pointing to the http endpoint from which a resource is downloaded. The mimeType can be used to specify the MIME type of the resource.\nThis blob type specification supports the following fields:\nurl string\nThis REQUIRED property describes the url from which the resource is to be downloaded.\nmediaType string\nThis OPTIONAL property describes the media type of the resource to be downloaded. If omitted, ocm tries to read the mediaType from the Content-Type header of the http response. If the mediaType cannot be set from the Content-Type header as well, ocm tries to deduct the mediaType from the URL. If that is not possible either, the default media type is defaulted to application/octet-stream.\nheader map[string][]string\nThis OPTIONAL property describes the http headers to be set in the http request to the server.\nverb string\nThis OPTIONAL property describes the http verb (also known as http request method) for the http request. If omitted, the http verb is defaulted to GET.\nbody []byte\nThis OPTIONAL property describes the http body to be included in the request.\nnoredirect bool\nThis OPTIONAL property describes whether http redirects should be disabled. If omitted, it is defaulted to false (so, per default, redirects are enabled).\nOptions used to configure fields: \u0026ndash;body, \u0026ndash;header, \u0026ndash;mediaType, \u0026ndash;noredirect, \u0026ndash;url, \u0026ndash;verb\nThe following list describes the supported access methods, their versions and specification formats. Typically there is special support for the CLI artifact add commands. The access method specification can be put below the access field. If always requires the field type describing the kind and version shown below.\nAccess type gitHub\nThis method implements the access of the content of a git commit stored in a GitHub repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nRepository URL with or without scheme.\nref (optional) string\nOriginal ref used to get the commit from\ncommit string\nThe sha/id of the git commit\nOptions used to configure fields: \u0026ndash;accessHostname, \u0026ndash;accessRepository, \u0026ndash;commit\nAccess type helm\nThis method implements the access of a Helm chart stored in a Helm repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nhelmRepository string\nHelm repository URL.\nhelmChart string\nThe name of the Helm chart and its version separated by a colon.\nversion string\nThe version of the Helm chart if not specified as part of the chart name.\ncaCert string\nAn optional TLS root certificate.\nkeyring string\nAn optional keyring used to verify the chart.\nIt uses the consumer identity type HelmChartRepository with the fields for a hostpath identity matcher (see ocm get credentials).\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type localBlob\nThis method is used to store a resource blob along with the component descriptor on behalf of the hosting OCM repository.\nIts implementation is specific to the implementation of OCM repository used to read the component descriptor. Every repository implementation may decide how and where local blobs are stored, but it MUST provide an implementation for this method.\nRegardless of the chosen implementation the attribute specification is defined globally the same.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nlocalReference string\nRepository type specific location information as string. The value may encode any deep structure, but typically just an access path is sufficient.\nmediaType string\nThe media type of the blob used to store the resource. It may add format information like +tar or +gzip.\nreferenceName (optional) string\nThis optional attribute may contain identity information used by other repositories to restore some global access with an identity related to the original source.\nFor example, if an OCI artifact originally referenced using the access method ociArtifact is stored during some transport step as local artifact, the reference name can be set to its original repository name. An import step into an OCI based OCM repository may then decide to make this artifact available again as regular OCI artifact.\nglobalAccess (optional) access method specification\nIf a resource blob is stored locally, the repository implementation may decide to provide an external access information (independent of the OCM model).\nFor example, an OCI artifact stored as local blob can be additionally stored as regular OCI artifact in an OCI registry.\nThis additional external access information can be added using a second external access method specification.\nOptions used to configure fields: \u0026ndash;globalAccess, \u0026ndash;hint, \u0026ndash;mediaType, \u0026ndash;reference\nAccess type maven\nThis method implements the access of a Maven artifact in a Maven repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nURL of the Maven repository\ngroupId string\nThe groupId of the Maven artifact\nartifactId string\nThe artifactId of the Maven artifact\nversion string\nThe version name of the Maven artifact\nclassifier string\nThe optional classifier of the Maven artifact\nextension string\nThe optional extension of the Maven artifact\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;artifactId, \u0026ndash;classifier, \u0026ndash;extension, \u0026ndash;groupId\nAccess type none\ndummy resource with no access\nAccess type npm\nThis method implements the access of an NPM package in an NPM registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregistry string\nBase URL of the NPM registry.\npackage string\nThe name of the NPM package\nversion string\nThe version name of the NPM package\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type ociArtifact\nThis method implements the access of an OCI artifact stored in an OCI registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI image/artifact reference following the possible docker schemes:\n\u0026lt;repo\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;digest\u0026gt;@\u0026lt;tag\u0026gt; [\u0026lt;port\u0026gt;]/\u0026lt;repo path\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;version\u0026gt;@\u0026lt;tag\u0026gt; Options used to configure fields: \u0026ndash;reference\nAccess type ociBlob\nThis method implements the access of an OCI blob stored in an OCI repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI repository reference (this artifact name used to store the blob).\nmediaType string\nThe media type of the blob\ndigest string\nThe digest of the blob used to access the blob in the OCI repository.\nsize integer\nThe size of the blob\nOptions used to configure fields: \u0026ndash;digest, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;size\nAccess type ocm\nThis method implements the access of any resource artifact stored in an OCM repository. Only repository types supporting remote access should be used.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nocmRepository json\nThe repository spec for the OCM repository\ncomponent string\n(Optional) The name of the component. The default is the own component.\nversion string\n(Optional) The version of the component. The default is the own component version.\nresourceRef relative resource ref\nThe resource reference of the denoted resource relative to the given component version.\nIt uses the consumer identity and credentials for the intermediate repositories and the final resource access.\nOptions used to configure fields: \u0026ndash;accessComponent, \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;identityPath\nAccess type s3\nThis method implements the access of a blob stored in an S3 bucket.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucket string\nThe name of the S3 bucket containing the blob\nkey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nVersion v2\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucketName string\nThe name of the S3 bucket containing the blob\nobjectKey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nOptions used to configure fields: \u0026ndash;accessVersion, \u0026ndash;bucket, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;region\nAccess type wget\nThis method implements access to resources stored on an http server.\nThe following versions are supported:\nVersion v1\nThe url is the url pointing to the http endpoint from which a resource is downloaded. The mimeType can be used to specify the MIME type of the resource.\nThis blob type specification supports the following fields:\nurl string This REQUIRED property describes the url from which the resource is to be downloaded.\nmediaType string This OPTIONAL property describes the media type of the resource to be downloaded. If omitted, ocm tries to read the mediaType from the Content-Type header of the http response. If the mediaType cannot be set from the Content-Type header as well, ocm tries to deduct the mediaType from the URL. If that is not possible either, the default media type is defaulted to application/octet-stream.\nheader map[string][]string This OPTIONAL property describes the http headers to be set in the http request to the server.\nverb string This OPTIONAL property describes the http verb (also known as http request method) for the http request. If omitted, the http verb is defaulted to GET.\nbody []byte This OPTIONAL property describes the http body to be included in the request.\nnoredirect bool This OPTIONAL property describes whether http redirects should be disabled. If omitted, it is defaulted to false (so, per default, redirects are enabled).\nOptions used to configure fields: \u0026ndash;body, \u0026ndash;header, \u0026ndash;mediaType, \u0026ndash;noredirect, \u0026ndash;url, \u0026ndash;verb\nThe \u0026ndash;replace option allows users to specify whether adding an element with the same name and extra identity but different version as an existing element, append (false) or replace (true) the existing element.\nThe \u0026ndash;preserve-signature option prohibits changes of signature relevant elements.\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" Examples Add a resource directly by options $ ocm add resources --file path/to/ca --name myresource --type PlainText --input \u0026#39;{ \u0026#34;type\u0026#34;: \u0026#34;file\u0026#34;, \u0026#34;path\u0026#34;: \u0026#34;testdata/testcontent\u0026#34;, \u0026#34;mediaType\u0026#34;: \u0026#34;text/plain\u0026#34; }\u0026#39; Add a resource by a description file: *resources.yaml*: --- name: myrresource type: plainText version: ${version] input: type: file path: testdata/testcontent mediaType: text/plain $ ocm add resources --file path/to/ca resources.yaml VERSION=1.0.0\rSee Also ocm add\t— Add elements to a component repository or component version ","date":"0001-01-01","id":107,"permalink":"/docs/cli-reference/add/resources/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm add resources [\u0026lt;options\u0026gt;] [\u0026lt;target\u0026gt;] {\u0026lt;resourcefile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --access YAML blob access specification (YAML)\n --accessComponent string component for access specification\n --accessHostname string hostname used for access\n --accessRepository string repository or registry URL\n --accessType string type of blob access specification\n --accessVersion string version for access specification\n --addenv access environment for templating\n --artifactId string maven artifact id\n --body string body of a http request\n --bucket string bucket name\n --classifier string maven classifier\n --commit string git commit id\n --digest string blob digest\n --dry-run evaluate and print resource specifications\n --extension string maven extension name\n --external flag non-local resource\n --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; resource extra identity (default [])\n -F, --file string target file/directory (default \u0026#34;component-archive\u0026#34;)\n --globalAccess YAML access specification for global access\n --groupId string maven group id\n --header \u0026lt;name\u0026gt;:\u0026lt;value\u0026gt;,\u0026lt;value\u0026gt;,... http headers (default {})\n -h, --help help for resources\n --hint string (repository) hint for local artifacts\n --identityPath {\u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;} identity path for specification\n --input YAML blob input specification (YAML)\n --inputComponent string component name\n --inputCompress compress option for input\n --inputData !bytesBase64 data (string, !!string or !\u0026lt;base64\u0026gt;\n --inputExcludes stringArray excludes (path) for inputs\n --inputFollowSymlinks follow symbolic links during archive creation for inputs\n --inputFormattedJson YAML JSON formatted text\n --inputHelmRepository string helm repository base URL\n --inputIncludes stringArray includes (path) for inputs\n --inputJson YAML JSON formatted text\n --inputLibraries stringArray library path for inputs\n --inputPath filepath path field for input\n --inputPlatforms stringArray input filter for image platforms ([os]/[architecture])\n --inputPreserveDir preserve directory in archive for inputs\n --inputRepository string repository or registry for inputs\n --inputText string utf8 text\n --inputType string type of blob input specification\n --inputValues YAML YAML based generic values for inputs\n --inputVariants stringArray (platform) variants for inputs\n --inputVersion string version info for inputs\n --inputYaml YAML YAML formatted text\n --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; resource label (leading * indicates signature relevant, optional version separated by @)\n --mediaType string media type for artifact blob representation\n --name string resource name\n --noredirect http redirect behavior\n -O, --output string output file for dry-run\n --package string package or object name\n -P, --preserve-signature preserve existing signatures\n --reference string reference name\n --region string region name\n -R, --replace replace existing elements\n --resource YAML resource meta data (yaml)\n -s, --settings stringArray settings file with variable settings (yaml)\n --size int blob size\n --skip-digest-generation skip digest creation\n --templater string templater to use (go, none, spiff, subst) (default \u0026#34;subst\u0026#34;)\n --type string resource type\n --url string artifact or server url\n --verb string http request method\n --version string resource version\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAdds resources specified in a resource file to a component version.\nSo far, only component archives are supported as target.\u003c/p\u003e","tags":[],"title":"resources"},{"content":"Usage ocm download resources [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}\rOptions --check-verified enable verification store -c, --constraints constraints version constraint -d, --download-handlers use download handler if possible --downloader \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; artifact downloader (\u0026lt;name\u0026gt;[:\u0026lt;artifact type\u0026gt;[:\u0026lt;media type\u0026gt;[:\u0026lt;priority\u0026gt;]]]=\u0026lt;JSON target config\u0026gt;) (default []) -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 --verified string file used to remember verifications for downloads (default \u0026#34;~/.ocm/verified\u0026#34;) --verify verify downloads\rDescription Download resources of a component version. Resources are specified by identities. An identity consists of a name argument followed by optional \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; arguments.\nThe 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:\n\u0026lt;component\u003e/\u0026lt;version\u003e{/\u0026lt;nested component\u003e/\u0026lt;version\u003e} 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 used. If additional identity attributes are required, this name is append by a comma separated list of \u0026lt;name\u0026gt;=\u0026lt;\u0026gt;value\u0026gt; pairs separated by a \u0026ldquo;-\u0026rdquo; from the plain name. This attribute list is alphabetical order:\n\u0026lt;resource name\u003e[-[\u0026lt;name\u003e=\u0026lt;\u003evalue\u003e]{,\u0026lt;name\u003e=\u0026lt;\u003evalue\u003e}] If the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry If the \u0026ndash;downloader option is specified, appropriate downloader handlers are configured for the operation. It has the following format\n\u0026lt;name\u003e:\u0026lt;artifact type\u003e:\u0026lt;media type\u003e=\u0026lt;yaml target config\u003e The downloader name may be a path expression with the following possibilities:\nhelm/artifact: download helm chart resources\nThe helm downloader is able to download helm chart resources as helm chart packages. Thus, the downloader may perform transformations. For example, if the helm chart is currently stored as an oci artifact, the downloader performs the necessary extraction to provide the helm chart package from within that oci artifact.\nThe following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar+gzip application/vnd.cncf.helm.chart.content.v1.tar+gzip It accepts no config.\nlandscaper/blueprint: uploading an OCI artifact to an OCI registry\nThe artifact downloader is able to transfer OCI artifact-like resources into an OCI registry given by the combination of the download target and the registration config.\nIf no config is given, the target must be an OCI reference with a potentially omitted repository. The repo part is derived from the reference hint provided by the resource\u0026rsquo;s access specification.\nIf the config is given, the target is used as repository name prefixed with an optional repository prefix given by the configuration.\nThe following artifact media types are supported:\napplication/vnd.docker.distribution.manifest.v2+tar application/vnd.docker.distribution.manifest.v2+tar+gzip application/vnd.gardener.landscaper.blueprint.layer.v1.tar application/vnd.gardener.landscaper.blueprint.layer.v1.tar+gzip application/vnd.gardener.landscaper.blueprint.v1+tar application/vnd.gardener.landscaper.blueprint.v1+tar+gzip application/vnd.oci.image.manifest.v1+tar application/vnd.oci.image.manifest.v1+tar+gzip application/x-tar application/x-tar+gzip application/x-tgz It accepts a config with the following fields:\nociConfigTypes: a list of accepted OCI config archive mime types defaulted by application/vnd.gardener.landscaper.blueprint.config.v1. This handler is by default registered for the following artifact types: landscaper.gardener.cloud/blueprint,blueprint\noci/artifact: downloading an OCI artifact and optionally re-uploading to an OCI registry\nThe artifact download resources stored as oci artifact. Furthermore, it allows to specify another OCI registry as download destination, thereby, providing a kind of transfer functionality.\nIf no config is given, the target must be an OCI reference with a potentially omitted repository. The repo part is derived from the reference hint provided by the resource\u0026rsquo;s access specification.\nIf the config is given, the target is used as repository name prefixed with an optional repository prefix given by the configuration.\nThe following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar+gzip application/vnd.oci.image.index.v1+tar+gzip It accepts a config with the following fields:\nnamespacePrefix: a namespace prefix used for the uploaded artifacts ociRef: an OCI repository reference repository: an OCI repository specification for the target OCI registry ocm/dirtree: downloading directory tree-like resources\nThe dirtree downloader is able to download directory-tree like resources as directory structure (default) or archive. The following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar+gzip application/x-tgz application/x-tar+gzip application/x-tar By default, it is registered for the following resource types:\ndirectoryTree filesystem It accepts a config with the following fields:\nasArchive: flag to request an archive download ociConfigTypes: a list of accepted OCI config archive mime types defaulted by application/vnd.oci.image.config.v1+json. plugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\nSee ocm ocm-downloadhandlers for further details on using download handlers.\nThe 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 \u0026ndash;download-handlers option. Otherwise the resource as returned by the access method is stored.\nWith the option \u0026ndash;recursive the complete reference tree of a component reference is traversed.\nIf a component lookup for building a reference closure is required the \u0026ndash;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.\nIf the verification store is enabled, resources downloaded from signed or verified component versions are verified against their digests provided by the component version.(not supported for using downloaders for the resource download).\nThe usage of the verification store is enabled by \u0026ndash;check-verified or by specifying a verification file with \u0026ndash;verified.\nSee Also ocm download\t— Download oci artifacts, resources or complete components ","date":"0001-01-01","id":108,"permalink":"/docs/cli-reference/download/resources/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm download resources [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --check-verified enable verification store\n -c, --constraints constraints version constraint\n -d, --download-handlers use download handler if possible\n --downloader \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; artifact downloader (\u0026lt;name\u0026gt;[:\u0026lt;artifact type\u0026gt;[:\u0026lt;media type\u0026gt;[:\u0026lt;priority\u0026gt;]]]=\u0026lt;JSON target config\u0026gt;) (default [])\n -x, --executable download executable for local platform\n -h, --help help for resources\n --latest restrict component versions to latest\n --lookup stringArray repository name or spec for closure lookup fallback\n -O, --outfile string output file or directory\n -r, --recursive follow component reference nesting\n --repo string repository name or spec\n -t, --type stringArray resource type filter\n --verified string file used to remember verifications for downloads (default \u0026#34;~/.ocm/verified\u0026#34;)\n --verify verify downloads\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eDownload resources of a component version. Resources are specified\nby identities. An identity consists of\na name argument followed by optional \u003ccode\u003e\u0026lt;key\u0026gt;=\u0026lt;value\u0026gt;\u003c/code\u003e\narguments.\u003c/p\u003e","tags":[],"title":"resources"},{"content":"Usage ocm get resources [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}\rOptions -c, --constraints constraints version constraint -h, --help help for resources --latest restrict component versions to latest --lookup stringArray repository name or spec for closure lookup fallback -o, --output string output mode (JSON, json, tree, treewide, wide, yaml) -r, --recursive follow component reference nesting --repo string repository name or spec -s, --sort stringArray sort fields\rDescription Get resources of a component version. Resources are specified by identities. An identity consists of a name argument followed by optional \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; arguments.\nIf the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry With the option \u0026ndash;recursive the complete reference tree of a component reference is traversed.\nIf a component lookup for building a reference closure is required the \u0026ndash;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.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json tree treewide wide yaml See Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":109,"permalink":"/docs/cli-reference/get/resources/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get resources [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -c, --constraints constraints version constraint\n -h, --help help for resources\n --latest restrict component versions to latest\n --lookup stringArray repository name or spec for closure lookup fallback\n -o, --output string output mode (JSON, json, tree, treewide, wide, yaml)\n -r, --recursive follow component reference nesting\n --repo string repository name or spec\n -s, --sort stringArray sort fields\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eGet resources of a component version. Resources are specified\nby identities. An identity consists of\na name argument followed by optional \u003ccode\u003e\u0026lt;key\u0026gt;=\u0026lt;value\u0026gt;\u003c/code\u003e\narguments.\u003c/p\u003e","tags":[],"title":"resources"},{"content":"Usage ocm add routingslips [\u0026lt;options\u0026gt;] \u0026lt;component-version\u0026gt; \u0026lt;routing-slip\u0026gt; \u0026lt;type\u0026gt;\rOptions -S, --algorithm string signature handler (default \u0026#34;RSASSA-PKCS1-V1_5\u0026#34;) --comment string comment field value --digest string parent digest to use --entry YAML routing slip entry specification (YAML) -h, --help help for routingslips --links strings links to other slip/entries (\u0026lt;slipname\u0026gt;[@\u0026lt;digest\u0026gt;]) --lookup stringArray repository name or spec for closure lookup fallback --repo string repository name or spec\rDescription Add a routing slip entry for the specified routing slip name to the given component version. The name is typically a DNS domain name followed by some qualifiers separated by a slash (/). It is possible to use arbitrary types, the type is not checked, if it is not known. Accordingly, an arbitrary config given as JSON or YAML can be given to determine the attribute set of the new entry for unknown types.\nThe following list describes the well-known entry types explicitly supported by this version of the CLI, their versions and specification formats. Other kinds of entries can be configured using the \u0026ndash;entry option.\nEntry type comment\nAn unstructured comment as entry in a routing slip.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\ncomment string\nAny text as entry in a routing slip.\nOptions used to configure fields: \u0026ndash;comment\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry If a component lookup for building a reference closure is required the \u0026ndash;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.\nExamples $ ocm add routingslip ghcr.io/mandelsoft/ocm//ocmdemoinstaller:0.0.1-dev mandelsoft.org comment --entry \u0026#34;comment=some text\u0026#34;\rSee Also ocm add\t— Add elements to a component repository or component version ","date":"0001-01-01","id":110,"permalink":"/docs/cli-reference/add/routingslips/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm add routingslips [\u0026lt;options\u0026gt;] \u0026lt;component-version\u0026gt; \u0026lt;routing-slip\u0026gt; \u0026lt;type\u0026gt;\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -S, --algorithm string signature handler (default \u0026#34;RSASSA-PKCS1-V1_5\u0026#34;)\n --comment string comment field value\n --digest string parent digest to use\n --entry YAML routing slip entry specification (YAML)\n -h, --help help for routingslips\n --links strings links to other slip/entries (\u0026lt;slipname\u0026gt;[@\u0026lt;digest\u0026gt;])\n --lookup stringArray repository name or spec for closure lookup fallback\n --repo string repository name or spec\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAdd a routing slip entry for the specified routing slip name to the given\ncomponent version. The name is typically a DNS domain name followed by some\nqualifiers separated by a slash (/). It is possible to use arbitrary types,\nthe type is not checked, if it is not known. Accordingly, an arbitrary config\ngiven as JSON or YAML can be given to determine the attribute set of the new\nentry for unknown types.\u003c/p\u003e","tags":[],"title":"routingslips"},{"content":"Usage ocm get routingslips [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt;}\rOptions --all-columns show all table columns -c, --constraints constraints version constraint --fail-on-error fail on validation error -h, --help help for routingslips --latest restrict component versions to latest --lookup stringArray repository name or spec for closure lookup fallback -o, --output string output mode (JSON, json, wide, yaml) --repo string repository name or spec -s, --sort stringArray sort fields -v, --verify verify signature\rDescription Get all or the selected routing slips for a component version specification.\nIf the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry If a component lookup for building a reference closure is required the \u0026ndash;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.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json wide yaml See Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":111,"permalink":"/docs/cli-reference/get/routingslips/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get routingslips [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --all-columns show all table columns\n -c, --constraints constraints version constraint\n --fail-on-error fail on validation error\n -h, --help help for routingslips\n --latest restrict component versions to latest\n --lookup stringArray repository name or spec for closure lookup fallback\n -o, --output string output mode (JSON, json, wide, yaml)\n --repo string repository name or spec\n -s, --sort stringArray sort fields\n -v, --verify verify signature\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eGet all or the selected routing slips for a component version specification.\u003c/p\u003e","tags":[],"title":"routingslips"},{"content":"Usage ocm create rsakeypair [\u0026lt;private key file\u0026gt; [\u0026lt;public key file\u0026gt;]] {\u0026lt;subject-attribute\u0026gt;=\u0026lt;value\u0026gt;}\rOptions --ca create certificate for a signing authority --ca-cert string certificate authority to sign public key --ca-key string private key for certificate authority -E, --encrypt encrypt private key with new key -e, --encryptionKey string encrypt private key with given key -h, --help help for rsakeypair --root-certs string root certificates used to validate used certificate authority --validity duration certificate validity (default 87600h0m0s)\rDescription Create an RSA public key pair and save to files.\nThe default for the filename to store the private key is rsa.priv. If no public key file is specified, its name will be derived from the filename for the private key (suffix .pub for public key or .cert for certificate). If a certificate authority is given (\u0026ndash;ca-cert) the public key will be signed. In this case a subject (at least common name/issuer) and a private key (\u0026ndash;ca-key) for the ca used to sign the key is required.\nIf only a subject is given and no ca, the public key will be self-signed. A signed public key always contains the complete certificate chain. If a non-self-signed ca is used to sign the key, its certificate chain is verified. Therefore, an additional root certificate (\u0026ndash;root-certs) is required, if no public root certificate was used to create the used ca.\nFor signing the public key the following subject attributes are supported:\nCN, common-name, issuer: Common Name/Issuer O, organization, org: Organization OU, organizational-unit, org-unit: Organizational Unit STREET (multiple): Street Address POSTALCODE, postal-code (multiple): Postal Code L, locality (multiple): Locality S, province, (multiple): Province C, country, (multiple): Country Examples $ ocm create rsakeypair mandelsoft.priv mandelsoft.cert issuer=mandelsoft\rSee Also ocm create\t— Create transport or component archive ","date":"0001-01-01","id":112,"permalink":"/docs/cli-reference/create/rsakeypair/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm create rsakeypair [\u0026lt;private key file\u0026gt; [\u0026lt;public key file\u0026gt;]] {\u0026lt;subject-attribute\u0026gt;=\u0026lt;value\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --ca create certificate for a signing authority\n --ca-cert string certificate authority to sign public key\n --ca-key string private key for certificate authority\n -E, --encrypt encrypt private key with new key\n -e, --encryptionKey string encrypt private key with given key\n -h, --help help for rsakeypair\n --root-certs string root certificates used to validate used certificate authority\n --validity duration certificate validity (default 87600h0m0s)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eCreate an RSA public key pair and save to files.\u003c/p\u003e","tags":[],"title":"rsakeypair"},{"content":"Usage ocm set [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for set\rSee Also Sub Commands ocm set pubsub\t— Set the pubsub spec for an ocm repository ","date":"0001-01-01","id":113,"permalink":"/docs/cli-reference/set/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm set [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for set\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/set/pubsub/\"\u003eocm set \u003cb\u003epubsub\u003c/b\u003e\u003c/a\u003e\t — Set the pubsub spec for an ocm repository\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"set"},{"content":"Usage ocm show [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for show\rSee Also Sub Commands ocm show tags\t— show dedicated tags of OCI artifacts ocm show versions\t— show dedicated versions (semver compliant) ","date":"0001-01-01","id":114,"permalink":"/docs/cli-reference/show/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm show [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for show\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/show/tags/\"\u003eocm show \u003cb\u003etags\u003c/b\u003e\u003c/a\u003e\t — show dedicated tags of OCI artifacts\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/show/versions/\"\u003eocm show \u003cb\u003eversions\u003c/b\u003e\u003c/a\u003e\t — show dedicated versions (semver compliant)\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"show"},{"content":"Usage ocm sign [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for sign\rSee Also Sub Commands ocm sign componentversions\t— Sign component version ocm sign hash\t— sign hash ","date":"0001-01-01","id":115,"permalink":"/docs/cli-reference/sign/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm sign [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for sign\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/sign/componentversions/\"\u003eocm sign \u003cb\u003ecomponentversions\u003c/b\u003e\u003c/a\u003e\t — Sign component version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/sign/hash/\"\u003eocm sign \u003cb\u003ehash\u003c/b\u003e\u003c/a\u003e\t — sign hash\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"sign"},{"content":"Usage ocm add source-configuration [\u0026lt;options\u0026gt;] \u0026lt;target\u0026gt; {\u0026lt;configfile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\rOptions --access YAML blob access specification (YAML) --accessComponent string component for access specification --accessHostname string hostname used for access --accessRepository string repository or registry URL --accessType string type of blob access specification --accessVersion string version for access specification --artifactId string maven artifact id --body string body of a http request --bucket string bucket name --classifier string maven classifier --commit string git commit id --digest string blob digest --extension string maven extension name --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; source extra identity (default []) --globalAccess YAML access specification for global access --groupId string maven group id --header \u0026lt;name\u0026gt;:\u0026lt;value\u0026gt;,\u0026lt;value\u0026gt;,... http headers (default {}) -h, --help help for source-configuration --hint string (repository) hint for local artifacts --identityPath {\u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;} identity path for specification --input YAML blob input specification (YAML) --inputComponent string component name --inputCompress compress option for input --inputData !bytesBase64 data (string, !!string or !\u0026lt;base64\u0026gt; --inputExcludes stringArray excludes (path) for inputs --inputFollowSymlinks follow symbolic links during archive creation for inputs --inputFormattedJson YAML JSON formatted text --inputHelmRepository string helm repository base URL --inputIncludes stringArray includes (path) for inputs --inputJson YAML JSON formatted text --inputLibraries stringArray library path for inputs --inputPath filepath path field for input --inputPlatforms stringArray input filter for image platforms ([os]/[architecture]) --inputPreserveDir preserve directory in archive for inputs --inputRepository string repository or registry for inputs --inputText string utf8 text --inputType string type of blob input specification --inputValues YAML YAML based generic values for inputs --inputVariants stringArray (platform) variants for inputs --inputVersion string version info for inputs --inputYaml YAML YAML formatted text --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; source label (leading * indicates signature relevant, optional version separated by @) --mediaType string media type for artifact blob representation --name string source name --noredirect http redirect behavior --package string package or object name --reference string reference name --region string region name -s, --settings stringArray settings file with variable settings (yaml) --size int blob size --source YAML source meta data (yaml) --type string source type --url string artifact or server url --verb string http request method --version string source version\rDescription Add a source specification to a source config file used by ocm add sources.\nIt is possible to describe a single source via command line options. The meta data of this element is described by the argument of option \u0026ndash;source, which must be a YAML or JSON string. Alternatively, the name and version can be specified with the options \u0026ndash;name and \u0026ndash;version. With the option \u0026ndash;extra it is possible to add extra identity attributes. Explicitly specified options override values specified by the \u0026ndash;source option. (Note: Go templates are not supported for YAML-based option values. Besides this restriction, the finally composed element description is still processed by the selected template engine.)\nThe source type can be specified with the option \u0026ndash;type. Therefore, the minimal required meta data for elements can be completely specified by dedicated options and don\u0026rsquo;t need the YAML option.\nTo describe the content of this element one of the options \u0026ndash;access or \u0026ndash;input must be given. They take a YAML or JSON value describing an attribute set, also. The structure of those values is similar to the access or input fields of the description file format. Elements must follow the resource meta data description scheme of the component descriptor.\nIf not specified anywhere the artifact type will be defaulted to directoryTree.\nIf expressions/templates are used in the specification file an appropriate templater and the required settings might be required to provide a correct input validation.\nThis command accepts additional source specification files describing the sources to add to a component version.\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" The resource specification supports the following blob input types, specified with the field type in the input field:\nInput type binary\nThis blob type is used to provide base64 encoded binary content. The specification supports the following fields:\ndata []byte\nThe binary data to provide.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputData, \u0026ndash;mediaType\nInput type dir\nThe path must denote a directory relative to the resources file, which is packed with tar and optionally compressed if the compress field is set to true. If the field preserveDir is set to true the directory itself is added to the tar. If the field followSymLinks is set to true, symbolic links are not packed but their targets files or folders. With the list fields includeFiles and excludeFiles it is possible to specify which files should be included or excluded. The values are regular expression used to match relative file paths. If no includes are specified all file not explicitly excluded are used.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the file path to directory relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/x-tar and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the file content should be stored compressed or not.\npreserveDir bool\nThis OPTIONAL property describes whether the specified directory with its basename should be included as top level folder.\nfollowSymlinks bool\nThis OPTIONAL property describes whether symbolic links should be followed or included as links.\nexcludeFiles list of regex\nThis OPTIONAL property describes regular expressions used to match files that should NOT be included in the tar file. It takes precedence over the include match.\nincludeFiles list of regex\nThis OPTIONAL property describes regular expressions used to match files that should be included in the tar file. If this option is not given all files not explicitly excluded are used.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputExcludes, \u0026ndash;inputFollowSymlinks, \u0026ndash;inputIncludes, \u0026ndash;inputPath, \u0026ndash;inputPreserveDir, \u0026ndash;mediaType\nInput type docker\nThe path must denote an image tag that can be found in the local docker daemon. The denoted image is packed as OCI artifact set. The OCI image will contain an informational back link to the component version using the manifest annotation software.ocm/component-version.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the image name to import from the local docker daemon.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputPath\nInput type dockermulti\nThis input type describes the composition of a multi-platform OCI image. The various variants are taken from the local docker daemon. They should be built with the \u0026ldquo;buildx\u0026rdquo; command for cross platform docker builds (see https://ocm.software/docs/tutorials/best-practices/#building-multi-architecture-images). The denoted images, as well as the wrapping image index, are packed as OCI artifact set. They will contain an informational back link to the component version using the manifest annotation software.ocm/component-version.\nThis blob type specification supports the following fields:\nvariants []string\nThis REQUIRED property describes a set of image names to import from the local docker daemon used to compose a resulting image index.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputVariants\nInput type file\nThe path must denote a file relative the resources file. The content is compressed if the compress field is set to true.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the path to the file relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;mediaType\nInput type helm\nThe path must denote an helm chart archive or directory relative to the resources file or a chart name in a helm chart repository. The denoted chart is packed as an OCI artifact set. For the filesystem version additional provider info is taken from a file with the same name and the suffix .prov.\nIf the chart should just be stored as plain archive, please use the type file or dir, instead.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the file path to the helm chart relative to the resource file location.\nversion string\nThis OPTIONAL property can be set to configure an explicit version hint. If not specified the version from the chart will be used. Basically, it is a good practice to use the component version for local resources This can be achieved by using templating for this attribute in the resource file.\nhelmRepository string\nThis OPTIONAL property can be set, if the helm chart should be loaded from a helm repository instead of the local filesystem. It describes the base URL of the chart repository. If specified, the path field must describe the name of the chart in the chart repository, and version must describe the version of the chart imported from the chart repository\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\ncaCertFile string\nThis OPTIONAL property can be used to specify a relative filename for the TLS root certificate used to access a helm repository.\ncaCert string\nThis OPTIONAL property can be used to specify a TLS root certificate used to access a helm repository.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputHelmRepository, \u0026ndash;inputPath, \u0026ndash;inputVersion, \u0026ndash;mediaType\nInput type maven\nThe repoUrl is the url pointing either to the http endpoint of a maven repository (e.g. https://repo.maven.apache.org/maven2/) or to a file system based maven repository (e.g. file://local/directory).\nThis blob type specification supports the following fields:\nrepoUrl string\nThis REQUIRED property describes the url from which the resource is to be accessed.\ngroupId string\nThis REQUIRED property describes the groupId of a maven artifact.\nartifactId string\nThis REQUIRED property describes artifactId of a maven artifact.\nversion string\nThis REQUIRED property describes the version of a maven artifact.\nclassifier string\nThis OPTIONAL property describes the classifier of a maven artifact.\nextension string\nThis OPTIONAL property describes the extension of a maven artifact.\nOptions used to configure fields: \u0026ndash;artifactId, \u0026ndash;classifier, \u0026ndash;extension, \u0026ndash;groupId, \u0026ndash;inputPath, \u0026ndash;inputVersion, \u0026ndash;url\nInput type npm\nThe registry is the url pointing to the npm registry from which a resource is downloaded.\nThis blob type specification supports the following fields:\nregistry string\nThis REQUIRED property describes the url from which the resource is to be downloaded.\npackage string\nThis REQUIRED property describes the name of the package to download.\nversion string\nThis is an OPTIONAL property describing the version of the package to download. If not defined, latest will be used automatically.\nOptions used to configure fields: \u0026ndash;inputRepository, \u0026ndash;inputVersion, \u0026ndash;package\nInput type ociArtifact\nThis input type is used to import an OCI image from an OCI registry. If it is a multi-arch image the set of platforms to be imported can be filtered using the \u0026ldquo;platforms\u0026rdquo; attribute. The path must denote an OCI image reference.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the OCI image reference of the image to import.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nplatforms []string\nThis OPTIONAL property can be used to filter index artifacts to include only images for dedicated operating systems/architectures. Elements must meet the syntax [\u0026lt;os\u0026gt;]/[\u0026lt;architecture\u0026gt;].\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;inputPlatforms, \u0026ndash;mediaType\nInput type ociImage\nDEPRECATED: This type is deprecated, please use ociArtifact instead.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;inputPlatforms, \u0026ndash;mediaType\nInput type ocm\nThis input type allows to get a resource artifact from an OCM repository.\nThis blob type specification supports the following fields:\nocmRepository repository specification\nThis REQUIRED property describes the OCM repository specification\ncomponent string\nThis REQUIRED property describes the component na,e\nversion string\nThis REQUIRED property describes the version of a maven artifact.\nresourceRef relative resource reference\nThis REQUIRED property describes the resource reference for the desired resource relative to the given component version .\nOptions used to configure fields: \u0026ndash;identityPath, \u0026ndash;inputComponent, \u0026ndash;inputRepository, \u0026ndash;inputVersion\nInput type spiff\nThe path must denote a spiff template relative the resources file. The content is compressed if the compress field is set to true.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the path to the file relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nvalues map[string]any\nThis OPTIONAL property describes an additional value binding for the template processing. It will be available under the node inputvalues.\nlibraries []string\nThis OPTIONAL property describes a list of spiff libraries to include in template processing.\nThe variable settings from the command line are available as binding, also. They are provided under the node values.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputLibraries, \u0026ndash;inputPath, \u0026ndash;inputValues, \u0026ndash;mediaType\nInput type utf8\nThis blob type is used to provide inline text based content (UTF8). The specification supports the following fields:\ntext string\nThe utf8 string content to provide.\njson JSON or JSON string interpreted as JSON\nThe content emitted as JSON.\nformattedJson YAML/JSON or JSON/YAML string interpreted as JSON\nThe content emitted as formatted JSON.\nyaml AML/JSON or JSON/YAML string interpreted as YAML\nThe content emitted as YAML.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputFormattedJson, \u0026ndash;inputJson, \u0026ndash;inputText, \u0026ndash;inputYaml, \u0026ndash;mediaType\nInput type wget\nThe url is the url pointing to the http endpoint from which a resource is downloaded. The mimeType can be used to specify the MIME type of the resource.\nThis blob type specification supports the following fields:\nurl string\nThis REQUIRED property describes the url from which the resource is to be downloaded.\nmediaType string\nThis OPTIONAL property describes the media type of the resource to be downloaded. If omitted, ocm tries to read the mediaType from the Content-Type header of the http response. If the mediaType cannot be set from the Content-Type header as well, ocm tries to deduct the mediaType from the URL. If that is not possible either, the default media type is defaulted to application/octet-stream.\nheader map[string][]string\nThis OPTIONAL property describes the http headers to be set in the http request to the server.\nverb string\nThis OPTIONAL property describes the http verb (also known as http request method) for the http request. If omitted, the http verb is defaulted to GET.\nbody []byte\nThis OPTIONAL property describes the http body to be included in the request.\nnoredirect bool\nThis OPTIONAL property describes whether http redirects should be disabled. If omitted, it is defaulted to false (so, per default, redirects are enabled).\nOptions used to configure fields: \u0026ndash;body, \u0026ndash;header, \u0026ndash;mediaType, \u0026ndash;noredirect, \u0026ndash;url, \u0026ndash;verb\nThe following list describes the supported access methods, their versions and specification formats. Typically there is special support for the CLI artifact add commands. The access method specification can be put below the access field. If always requires the field type describing the kind and version shown below.\nAccess type gitHub\nThis method implements the access of the content of a git commit stored in a GitHub repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nRepository URL with or without scheme.\nref (optional) string\nOriginal ref used to get the commit from\ncommit string\nThe sha/id of the git commit\nOptions used to configure fields: \u0026ndash;accessHostname, \u0026ndash;accessRepository, \u0026ndash;commit\nAccess type helm\nThis method implements the access of a Helm chart stored in a Helm repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nhelmRepository string\nHelm repository URL.\nhelmChart string\nThe name of the Helm chart and its version separated by a colon.\nversion string\nThe version of the Helm chart if not specified as part of the chart name.\ncaCert string\nAn optional TLS root certificate.\nkeyring string\nAn optional keyring used to verify the chart.\nIt uses the consumer identity type HelmChartRepository with the fields for a hostpath identity matcher (see ocm get credentials).\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type localBlob\nThis method is used to store a resource blob along with the component descriptor on behalf of the hosting OCM repository.\nIts implementation is specific to the implementation of OCM repository used to read the component descriptor. Every repository implementation may decide how and where local blobs are stored, but it MUST provide an implementation for this method.\nRegardless of the chosen implementation the attribute specification is defined globally the same.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nlocalReference string\nRepository type specific location information as string. The value may encode any deep structure, but typically just an access path is sufficient.\nmediaType string\nThe media type of the blob used to store the resource. It may add format information like +tar or +gzip.\nreferenceName (optional) string\nThis optional attribute may contain identity information used by other repositories to restore some global access with an identity related to the original source.\nFor example, if an OCI artifact originally referenced using the access method ociArtifact is stored during some transport step as local artifact, the reference name can be set to its original repository name. An import step into an OCI based OCM repository may then decide to make this artifact available again as regular OCI artifact.\nglobalAccess (optional) access method specification\nIf a resource blob is stored locally, the repository implementation may decide to provide an external access information (independent of the OCM model).\nFor example, an OCI artifact stored as local blob can be additionally stored as regular OCI artifact in an OCI registry.\nThis additional external access information can be added using a second external access method specification.\nOptions used to configure fields: \u0026ndash;globalAccess, \u0026ndash;hint, \u0026ndash;mediaType, \u0026ndash;reference\nAccess type maven\nThis method implements the access of a Maven artifact in a Maven repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nURL of the Maven repository\ngroupId string\nThe groupId of the Maven artifact\nartifactId string\nThe artifactId of the Maven artifact\nversion string\nThe version name of the Maven artifact\nclassifier string\nThe optional classifier of the Maven artifact\nextension string\nThe optional extension of the Maven artifact\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;artifactId, \u0026ndash;classifier, \u0026ndash;extension, \u0026ndash;groupId\nAccess type none\ndummy resource with no access\nAccess type npm\nThis method implements the access of an NPM package in an NPM registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregistry string\nBase URL of the NPM registry.\npackage string\nThe name of the NPM package\nversion string\nThe version name of the NPM package\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type ociArtifact\nThis method implements the access of an OCI artifact stored in an OCI registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI image/artifact reference following the possible docker schemes:\n\u0026lt;repo\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;digest\u0026gt;@\u0026lt;tag\u0026gt; [\u0026lt;port\u0026gt;]/\u0026lt;repo path\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;version\u0026gt;@\u0026lt;tag\u0026gt; Options used to configure fields: \u0026ndash;reference\nAccess type ociBlob\nThis method implements the access of an OCI blob stored in an OCI repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI repository reference (this artifact name used to store the blob).\nmediaType string\nThe media type of the blob\ndigest string\nThe digest of the blob used to access the blob in the OCI repository.\nsize integer\nThe size of the blob\nOptions used to configure fields: \u0026ndash;digest, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;size\nAccess type ocm\nThis method implements the access of any resource artifact stored in an OCM repository. Only repository types supporting remote access should be used.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nocmRepository json\nThe repository spec for the OCM repository\ncomponent string\n(Optional) The name of the component. The default is the own component.\nversion string\n(Optional) The version of the component. The default is the own component version.\nresourceRef relative resource ref\nThe resource reference of the denoted resource relative to the given component version.\nIt uses the consumer identity and credentials for the intermediate repositories and the final resource access.\nOptions used to configure fields: \u0026ndash;accessComponent, \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;identityPath\nAccess type s3\nThis method implements the access of a blob stored in an S3 bucket.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucket string\nThe name of the S3 bucket containing the blob\nkey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nVersion v2\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucketName string\nThe name of the S3 bucket containing the blob\nobjectKey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nOptions used to configure fields: \u0026ndash;accessVersion, \u0026ndash;bucket, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;region\nAccess type wget\nThis method implements access to resources stored on an http server.\nThe following versions are supported:\nVersion v1\nThe url is the url pointing to the http endpoint from which a resource is downloaded. The mimeType can be used to specify the MIME type of the resource.\nThis blob type specification supports the following fields:\nurl string This REQUIRED property describes the url from which the resource is to be downloaded.\nmediaType string This OPTIONAL property describes the media type of the resource to be downloaded. If omitted, ocm tries to read the mediaType from the Content-Type header of the http response. If the mediaType cannot be set from the Content-Type header as well, ocm tries to deduct the mediaType from the URL. If that is not possible either, the default media type is defaulted to application/octet-stream.\nheader map[string][]string This OPTIONAL property describes the http headers to be set in the http request to the server.\nverb string This OPTIONAL property describes the http verb (also known as http request method) for the http request. If omitted, the http verb is defaulted to GET.\nbody []byte This OPTIONAL property describes the http body to be included in the request.\nnoredirect bool This OPTIONAL property describes whether http redirects should be disabled. If omitted, it is defaulted to false (so, per default, redirects are enabled).\nOptions used to configure fields: \u0026ndash;body, \u0026ndash;header, \u0026ndash;mediaType, \u0026ndash;noredirect, \u0026ndash;url, \u0026ndash;verb\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" Examples $ ocm add source-config sources.yaml --name sources --type filesystem --access \u0026#39;{ \u0026#34;type\u0026#34;: \u0026#34;gitHub\u0026#34;, \u0026#34;repoUrl\u0026#34;: \u0026#34;ocm.software/ocm\u0026#34;, \u0026#34;commit\u0026#34;: \u0026#34;xyz\u0026#34; }\u0026#39;\rSee Also ocm add\t— Add elements to a component repository or component version ","date":"0001-01-01","id":116,"permalink":"/docs/cli-reference/add/source-configuration/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm add source-configuration [\u0026lt;options\u0026gt;] \u0026lt;target\u0026gt; {\u0026lt;configfile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --access YAML blob access specification (YAML)\n --accessComponent string component for access specification\n --accessHostname string hostname used for access\n --accessRepository string repository or registry URL\n --accessType string type of blob access specification\n --accessVersion string version for access specification\n --artifactId string maven artifact id\n --body string body of a http request\n --bucket string bucket name\n --classifier string maven classifier\n --commit string git commit id\n --digest string blob digest\n --extension string maven extension name\n --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; source extra identity (default [])\n --globalAccess YAML access specification for global access\n --groupId string maven group id\n --header \u0026lt;name\u0026gt;:\u0026lt;value\u0026gt;,\u0026lt;value\u0026gt;,... http headers (default {})\n -h, --help help for source-configuration\n --hint string (repository) hint for local artifacts\n --identityPath {\u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;} identity path for specification\n --input YAML blob input specification (YAML)\n --inputComponent string component name\n --inputCompress compress option for input\n --inputData !bytesBase64 data (string, !!string or !\u0026lt;base64\u0026gt;\n --inputExcludes stringArray excludes (path) for inputs\n --inputFollowSymlinks follow symbolic links during archive creation for inputs\n --inputFormattedJson YAML JSON formatted text\n --inputHelmRepository string helm repository base URL\n --inputIncludes stringArray includes (path) for inputs\n --inputJson YAML JSON formatted text\n --inputLibraries stringArray library path for inputs\n --inputPath filepath path field for input\n --inputPlatforms stringArray input filter for image platforms ([os]/[architecture])\n --inputPreserveDir preserve directory in archive for inputs\n --inputRepository string repository or registry for inputs\n --inputText string utf8 text\n --inputType string type of blob input specification\n --inputValues YAML YAML based generic values for inputs\n --inputVariants stringArray (platform) variants for inputs\n --inputVersion string version info for inputs\n --inputYaml YAML YAML formatted text\n --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; source label (leading * indicates signature relevant, optional version separated by @)\n --mediaType string media type for artifact blob representation\n --name string source name\n --noredirect http redirect behavior\n --package string package or object name\n --reference string reference name\n --region string region name\n -s, --settings stringArray settings file with variable settings (yaml)\n --size int blob size\n --source YAML source meta data (yaml)\n --type string source type\n --url string artifact or server url\n --verb string http request method\n --version string source version\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAdd a source specification to a source config file used by \u003ca href=\"/docs/cli-reference/add/sources/\"\u003eocm add sources\u003c/a\u003e.\u003c/p\u003e","tags":[],"title":"source-configuration"},{"content":"Usage ocm add sources [\u0026lt;options\u0026gt;] [\u0026lt;target\u0026gt;] {\u0026lt;resourcefile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\rOptions --access YAML blob access specification (YAML) --accessComponent string component for access specification --accessHostname string hostname used for access --accessRepository string repository or registry URL --accessType string type of blob access specification --accessVersion string version for access specification --addenv access environment for templating --artifactId string maven artifact id --body string body of a http request --bucket string bucket name --classifier string maven classifier --commit string git commit id --digest string blob digest --dry-run evaluate and print source specifications --extension string maven extension name --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; source extra identity (default []) -F, --file string target file/directory (default \u0026#34;component-archive\u0026#34;) --globalAccess YAML access specification for global access --groupId string maven group id --header \u0026lt;name\u0026gt;:\u0026lt;value\u0026gt;,\u0026lt;value\u0026gt;,... http headers (default {}) -h, --help help for sources --hint string (repository) hint for local artifacts --identityPath {\u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;} identity path for specification --input YAML blob input specification (YAML) --inputComponent string component name --inputCompress compress option for input --inputData !bytesBase64 data (string, !!string or !\u0026lt;base64\u0026gt; --inputExcludes stringArray excludes (path) for inputs --inputFollowSymlinks follow symbolic links during archive creation for inputs --inputFormattedJson YAML JSON formatted text --inputHelmRepository string helm repository base URL --inputIncludes stringArray includes (path) for inputs --inputJson YAML JSON formatted text --inputLibraries stringArray library path for inputs --inputPath filepath path field for input --inputPlatforms stringArray input filter for image platforms ([os]/[architecture]) --inputPreserveDir preserve directory in archive for inputs --inputRepository string repository or registry for inputs --inputText string utf8 text --inputType string type of blob input specification --inputValues YAML YAML based generic values for inputs --inputVariants stringArray (platform) variants for inputs --inputVersion string version info for inputs --inputYaml YAML YAML formatted text --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; source label (leading * indicates signature relevant, optional version separated by @) --mediaType string media type for artifact blob representation --name string source name --noredirect http redirect behavior -O, --output string output file for dry-run --package string package or object name -P, --preserve-signature preserve existing signatures --reference string reference name --region string region name -R, --replace replace existing elements -s, --settings stringArray settings file with variable settings (yaml) --size int blob size --source YAML source meta data (yaml) --templater string templater to use (go, none, spiff, subst) (default \u0026#34;subst\u0026#34;) --type string source type --url string artifact or server url --verb string http request method --version string source version\rDescription Add information about the sources, e.g. commits in a Github repository, that have been used to create the resources specified in a resource file to a component version. So far only component archives are supported as target.\nThis command accepts source specification files describing the sources to add to a component version. Elements must follow the source meta data description scheme of the component descriptor. Besides referential sources using the access attribute to describe the access method, it is possible to describe local sources fed by local data using the input field (see below).\nThe description file might contain:\na single source a list of sources under the key sources a list of yaml documents with a single source or source list It is possible to describe a single source via command line options. The meta data of this element is described by the argument of option \u0026ndash;source, which must be a YAML or JSON string. Alternatively, the name and version can be specified with the options \u0026ndash;name and \u0026ndash;version. With the option \u0026ndash;extra it is possible to add extra identity attributes. Explicitly specified options override values specified by the \u0026ndash;source option. (Note: Go templates are not supported for YAML-based option values. Besides this restriction, the finally composed element description is still processed by the selected template engine.)\nThe source type can be specified with the option \u0026ndash;type. Therefore, the minimal required meta data for elements can be completely specified by dedicated options and don\u0026rsquo;t need the YAML option.\nTo describe the content of this element one of the options \u0026ndash;access or \u0026ndash;input must be given. They take a YAML or JSON value describing an attribute set, also. The structure of those values is similar to the access or input fields of the description file format.\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" The resource specification supports the following blob input types, specified with the field type in the input field:\nInput type binary\nThis blob type is used to provide base64 encoded binary content. The specification supports the following fields:\ndata []byte\nThe binary data to provide.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputData, \u0026ndash;mediaType\nInput type dir\nThe path must denote a directory relative to the resources file, which is packed with tar and optionally compressed if the compress field is set to true. If the field preserveDir is set to true the directory itself is added to the tar. If the field followSymLinks is set to true, symbolic links are not packed but their targets files or folders. With the list fields includeFiles and excludeFiles it is possible to specify which files should be included or excluded. The values are regular expression used to match relative file paths. If no includes are specified all file not explicitly excluded are used.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the file path to directory relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/x-tar and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the file content should be stored compressed or not.\npreserveDir bool\nThis OPTIONAL property describes whether the specified directory with its basename should be included as top level folder.\nfollowSymlinks bool\nThis OPTIONAL property describes whether symbolic links should be followed or included as links.\nexcludeFiles list of regex\nThis OPTIONAL property describes regular expressions used to match files that should NOT be included in the tar file. It takes precedence over the include match.\nincludeFiles list of regex\nThis OPTIONAL property describes regular expressions used to match files that should be included in the tar file. If this option is not given all files not explicitly excluded are used.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputExcludes, \u0026ndash;inputFollowSymlinks, \u0026ndash;inputIncludes, \u0026ndash;inputPath, \u0026ndash;inputPreserveDir, \u0026ndash;mediaType\nInput type docker\nThe path must denote an image tag that can be found in the local docker daemon. The denoted image is packed as OCI artifact set. The OCI image will contain an informational back link to the component version using the manifest annotation software.ocm/component-version.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the image name to import from the local docker daemon.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputPath\nInput type dockermulti\nThis input type describes the composition of a multi-platform OCI image. The various variants are taken from the local docker daemon. They should be built with the \u0026ldquo;buildx\u0026rdquo; command for cross platform docker builds (see https://ocm.software/docs/tutorials/best-practices/#building-multi-architecture-images). The denoted images, as well as the wrapping image index, are packed as OCI artifact set. They will contain an informational back link to the component version using the manifest annotation software.ocm/component-version.\nThis blob type specification supports the following fields:\nvariants []string\nThis REQUIRED property describes a set of image names to import from the local docker daemon used to compose a resulting image index.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputVariants\nInput type file\nThe path must denote a file relative the resources file. The content is compressed if the compress field is set to true.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the path to the file relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;mediaType\nInput type helm\nThe path must denote an helm chart archive or directory relative to the resources file or a chart name in a helm chart repository. The denoted chart is packed as an OCI artifact set. For the filesystem version additional provider info is taken from a file with the same name and the suffix .prov.\nIf the chart should just be stored as plain archive, please use the type file or dir, instead.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the file path to the helm chart relative to the resource file location.\nversion string\nThis OPTIONAL property can be set to configure an explicit version hint. If not specified the version from the chart will be used. Basically, it is a good practice to use the component version for local resources This can be achieved by using templating for this attribute in the resource file.\nhelmRepository string\nThis OPTIONAL property can be set, if the helm chart should be loaded from a helm repository instead of the local filesystem. It describes the base URL of the chart repository. If specified, the path field must describe the name of the chart in the chart repository, and version must describe the version of the chart imported from the chart repository\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\ncaCertFile string\nThis OPTIONAL property can be used to specify a relative filename for the TLS root certificate used to access a helm repository.\ncaCert string\nThis OPTIONAL property can be used to specify a TLS root certificate used to access a helm repository.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputHelmRepository, \u0026ndash;inputPath, \u0026ndash;inputVersion, \u0026ndash;mediaType\nInput type maven\nThe repoUrl is the url pointing either to the http endpoint of a maven repository (e.g. https://repo.maven.apache.org/maven2/) or to a file system based maven repository (e.g. file://local/directory).\nThis blob type specification supports the following fields:\nrepoUrl string\nThis REQUIRED property describes the url from which the resource is to be accessed.\ngroupId string\nThis REQUIRED property describes the groupId of a maven artifact.\nartifactId string\nThis REQUIRED property describes artifactId of a maven artifact.\nversion string\nThis REQUIRED property describes the version of a maven artifact.\nclassifier string\nThis OPTIONAL property describes the classifier of a maven artifact.\nextension string\nThis OPTIONAL property describes the extension of a maven artifact.\nOptions used to configure fields: \u0026ndash;artifactId, \u0026ndash;classifier, \u0026ndash;extension, \u0026ndash;groupId, \u0026ndash;inputPath, \u0026ndash;inputVersion, \u0026ndash;url\nInput type npm\nThe registry is the url pointing to the npm registry from which a resource is downloaded.\nThis blob type specification supports the following fields:\nregistry string\nThis REQUIRED property describes the url from which the resource is to be downloaded.\npackage string\nThis REQUIRED property describes the name of the package to download.\nversion string\nThis is an OPTIONAL property describing the version of the package to download. If not defined, latest will be used automatically.\nOptions used to configure fields: \u0026ndash;inputRepository, \u0026ndash;inputVersion, \u0026ndash;package\nInput type ociArtifact\nThis input type is used to import an OCI image from an OCI registry. If it is a multi-arch image the set of platforms to be imported can be filtered using the \u0026ldquo;platforms\u0026rdquo; attribute. The path must denote an OCI image reference.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the OCI image reference of the image to import.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nplatforms []string\nThis OPTIONAL property can be used to filter index artifacts to include only images for dedicated operating systems/architectures. Elements must meet the syntax [\u0026lt;os\u0026gt;]/[\u0026lt;architecture\u0026gt;].\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;inputPlatforms, \u0026ndash;mediaType\nInput type ociImage\nDEPRECATED: This type is deprecated, please use ociArtifact instead.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;inputPlatforms, \u0026ndash;mediaType\nInput type ocm\nThis input type allows to get a resource artifact from an OCM repository.\nThis blob type specification supports the following fields:\nocmRepository repository specification\nThis REQUIRED property describes the OCM repository specification\ncomponent string\nThis REQUIRED property describes the component na,e\nversion string\nThis REQUIRED property describes the version of a maven artifact.\nresourceRef relative resource reference\nThis REQUIRED property describes the resource reference for the desired resource relative to the given component version .\nOptions used to configure fields: \u0026ndash;identityPath, \u0026ndash;inputComponent, \u0026ndash;inputRepository, \u0026ndash;inputVersion\nInput type spiff\nThe path must denote a spiff template relative the resources file. The content is compressed if the compress field is set to true.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the path to the file relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nvalues map[string]any\nThis OPTIONAL property describes an additional value binding for the template processing. It will be available under the node inputvalues.\nlibraries []string\nThis OPTIONAL property describes a list of spiff libraries to include in template processing.\nThe variable settings from the command line are available as binding, also. They are provided under the node values.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputLibraries, \u0026ndash;inputPath, \u0026ndash;inputValues, \u0026ndash;mediaType\nInput type utf8\nThis blob type is used to provide inline text based content (UTF8). The specification supports the following fields:\ntext string\nThe utf8 string content to provide.\njson JSON or JSON string interpreted as JSON\nThe content emitted as JSON.\nformattedJson YAML/JSON or JSON/YAML string interpreted as JSON\nThe content emitted as formatted JSON.\nyaml AML/JSON or JSON/YAML string interpreted as YAML\nThe content emitted as YAML.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputFormattedJson, \u0026ndash;inputJson, \u0026ndash;inputText, \u0026ndash;inputYaml, \u0026ndash;mediaType\nInput type wget\nThe url is the url pointing to the http endpoint from which a resource is downloaded. The mimeType can be used to specify the MIME type of the resource.\nThis blob type specification supports the following fields:\nurl string\nThis REQUIRED property describes the url from which the resource is to be downloaded.\nmediaType string\nThis OPTIONAL property describes the media type of the resource to be downloaded. If omitted, ocm tries to read the mediaType from the Content-Type header of the http response. If the mediaType cannot be set from the Content-Type header as well, ocm tries to deduct the mediaType from the URL. If that is not possible either, the default media type is defaulted to application/octet-stream.\nheader map[string][]string\nThis OPTIONAL property describes the http headers to be set in the http request to the server.\nverb string\nThis OPTIONAL property describes the http verb (also known as http request method) for the http request. If omitted, the http verb is defaulted to GET.\nbody []byte\nThis OPTIONAL property describes the http body to be included in the request.\nnoredirect bool\nThis OPTIONAL property describes whether http redirects should be disabled. If omitted, it is defaulted to false (so, per default, redirects are enabled).\nOptions used to configure fields: \u0026ndash;body, \u0026ndash;header, \u0026ndash;mediaType, \u0026ndash;noredirect, \u0026ndash;url, \u0026ndash;verb\nThe following list describes the supported access methods, their versions and specification formats. Typically there is special support for the CLI artifact add commands. The access method specification can be put below the access field. If always requires the field type describing the kind and version shown below.\nAccess type gitHub\nThis method implements the access of the content of a git commit stored in a GitHub repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nRepository URL with or without scheme.\nref (optional) string\nOriginal ref used to get the commit from\ncommit string\nThe sha/id of the git commit\nOptions used to configure fields: \u0026ndash;accessHostname, \u0026ndash;accessRepository, \u0026ndash;commit\nAccess type helm\nThis method implements the access of a Helm chart stored in a Helm repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nhelmRepository string\nHelm repository URL.\nhelmChart string\nThe name of the Helm chart and its version separated by a colon.\nversion string\nThe version of the Helm chart if not specified as part of the chart name.\ncaCert string\nAn optional TLS root certificate.\nkeyring string\nAn optional keyring used to verify the chart.\nIt uses the consumer identity type HelmChartRepository with the fields for a hostpath identity matcher (see ocm get credentials).\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type localBlob\nThis method is used to store a resource blob along with the component descriptor on behalf of the hosting OCM repository.\nIts implementation is specific to the implementation of OCM repository used to read the component descriptor. Every repository implementation may decide how and where local blobs are stored, but it MUST provide an implementation for this method.\nRegardless of the chosen implementation the attribute specification is defined globally the same.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nlocalReference string\nRepository type specific location information as string. The value may encode any deep structure, but typically just an access path is sufficient.\nmediaType string\nThe media type of the blob used to store the resource. It may add format information like +tar or +gzip.\nreferenceName (optional) string\nThis optional attribute may contain identity information used by other repositories to restore some global access with an identity related to the original source.\nFor example, if an OCI artifact originally referenced using the access method ociArtifact is stored during some transport step as local artifact, the reference name can be set to its original repository name. An import step into an OCI based OCM repository may then decide to make this artifact available again as regular OCI artifact.\nglobalAccess (optional) access method specification\nIf a resource blob is stored locally, the repository implementation may decide to provide an external access information (independent of the OCM model).\nFor example, an OCI artifact stored as local blob can be additionally stored as regular OCI artifact in an OCI registry.\nThis additional external access information can be added using a second external access method specification.\nOptions used to configure fields: \u0026ndash;globalAccess, \u0026ndash;hint, \u0026ndash;mediaType, \u0026ndash;reference\nAccess type maven\nThis method implements the access of a Maven artifact in a Maven repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nURL of the Maven repository\ngroupId string\nThe groupId of the Maven artifact\nartifactId string\nThe artifactId of the Maven artifact\nversion string\nThe version name of the Maven artifact\nclassifier string\nThe optional classifier of the Maven artifact\nextension string\nThe optional extension of the Maven artifact\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;artifactId, \u0026ndash;classifier, \u0026ndash;extension, \u0026ndash;groupId\nAccess type none\ndummy resource with no access\nAccess type npm\nThis method implements the access of an NPM package in an NPM registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregistry string\nBase URL of the NPM registry.\npackage string\nThe name of the NPM package\nversion string\nThe version name of the NPM package\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type ociArtifact\nThis method implements the access of an OCI artifact stored in an OCI registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI image/artifact reference following the possible docker schemes:\n\u0026lt;repo\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;digest\u0026gt;@\u0026lt;tag\u0026gt; [\u0026lt;port\u0026gt;]/\u0026lt;repo path\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;version\u0026gt;@\u0026lt;tag\u0026gt; Options used to configure fields: \u0026ndash;reference\nAccess type ociBlob\nThis method implements the access of an OCI blob stored in an OCI repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI repository reference (this artifact name used to store the blob).\nmediaType string\nThe media type of the blob\ndigest string\nThe digest of the blob used to access the blob in the OCI repository.\nsize integer\nThe size of the blob\nOptions used to configure fields: \u0026ndash;digest, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;size\nAccess type ocm\nThis method implements the access of any resource artifact stored in an OCM repository. Only repository types supporting remote access should be used.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nocmRepository json\nThe repository spec for the OCM repository\ncomponent string\n(Optional) The name of the component. The default is the own component.\nversion string\n(Optional) The version of the component. The default is the own component version.\nresourceRef relative resource ref\nThe resource reference of the denoted resource relative to the given component version.\nIt uses the consumer identity and credentials for the intermediate repositories and the final resource access.\nOptions used to configure fields: \u0026ndash;accessComponent, \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;identityPath\nAccess type s3\nThis method implements the access of a blob stored in an S3 bucket.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucket string\nThe name of the S3 bucket containing the blob\nkey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nVersion v2\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucketName string\nThe name of the S3 bucket containing the blob\nobjectKey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nOptions used to configure fields: \u0026ndash;accessVersion, \u0026ndash;bucket, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;region\nAccess type wget\nThis method implements access to resources stored on an http server.\nThe following versions are supported:\nVersion v1\nThe url is the url pointing to the http endpoint from which a resource is downloaded. The mimeType can be used to specify the MIME type of the resource.\nThis blob type specification supports the following fields:\nurl string This REQUIRED property describes the url from which the resource is to be downloaded.\nmediaType string This OPTIONAL property describes the media type of the resource to be downloaded. If omitted, ocm tries to read the mediaType from the Content-Type header of the http response. If the mediaType cannot be set from the Content-Type header as well, ocm tries to deduct the mediaType from the URL. If that is not possible either, the default media type is defaulted to application/octet-stream.\nheader map[string][]string This OPTIONAL property describes the http headers to be set in the http request to the server.\nverb string This OPTIONAL property describes the http verb (also known as http request method) for the http request. If omitted, the http verb is defaulted to GET.\nbody []byte This OPTIONAL property describes the http body to be included in the request.\nnoredirect bool This OPTIONAL property describes whether http redirects should be disabled. If omitted, it is defaulted to false (so, per default, redirects are enabled).\nOptions used to configure fields: \u0026ndash;body, \u0026ndash;header, \u0026ndash;mediaType, \u0026ndash;noredirect, \u0026ndash;url, \u0026ndash;verb\nThe \u0026ndash;replace option allows users to specify whether adding an element with the same name and extra identity but different version as an existing element, append (false) or replace (true) the existing element.\nThe \u0026ndash;preserve-signature option prohibits changes of signature relevant elements.\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" Examples $ ocm add sources --file path/to/cafile sources.yaml\rSee Also ocm add\t— Add elements to a component repository or component version ","date":"0001-01-01","id":117,"permalink":"/docs/cli-reference/add/sources/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm add sources [\u0026lt;options\u0026gt;] [\u0026lt;target\u0026gt;] {\u0026lt;resourcefile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --access YAML blob access specification (YAML)\n --accessComponent string component for access specification\n --accessHostname string hostname used for access\n --accessRepository string repository or registry URL\n --accessType string type of blob access specification\n --accessVersion string version for access specification\n --addenv access environment for templating\n --artifactId string maven artifact id\n --body string body of a http request\n --bucket string bucket name\n --classifier string maven classifier\n --commit string git commit id\n --digest string blob digest\n --dry-run evaluate and print source specifications\n --extension string maven extension name\n --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; source extra identity (default [])\n -F, --file string target file/directory (default \u0026#34;component-archive\u0026#34;)\n --globalAccess YAML access specification for global access\n --groupId string maven group id\n --header \u0026lt;name\u0026gt;:\u0026lt;value\u0026gt;,\u0026lt;value\u0026gt;,... http headers (default {})\n -h, --help help for sources\n --hint string (repository) hint for local artifacts\n --identityPath {\u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;} identity path for specification\n --input YAML blob input specification (YAML)\n --inputComponent string component name\n --inputCompress compress option for input\n --inputData !bytesBase64 data (string, !!string or !\u0026lt;base64\u0026gt;\n --inputExcludes stringArray excludes (path) for inputs\n --inputFollowSymlinks follow symbolic links during archive creation for inputs\n --inputFormattedJson YAML JSON formatted text\n --inputHelmRepository string helm repository base URL\n --inputIncludes stringArray includes (path) for inputs\n --inputJson YAML JSON formatted text\n --inputLibraries stringArray library path for inputs\n --inputPath filepath path field for input\n --inputPlatforms stringArray input filter for image platforms ([os]/[architecture])\n --inputPreserveDir preserve directory in archive for inputs\n --inputRepository string repository or registry for inputs\n --inputText string utf8 text\n --inputType string type of blob input specification\n --inputValues YAML YAML based generic values for inputs\n --inputVariants stringArray (platform) variants for inputs\n --inputVersion string version info for inputs\n --inputYaml YAML YAML formatted text\n --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; source label (leading * indicates signature relevant, optional version separated by @)\n --mediaType string media type for artifact blob representation\n --name string source name\n --noredirect http redirect behavior\n -O, --output string output file for dry-run\n --package string package or object name\n -P, --preserve-signature preserve existing signatures\n --reference string reference name\n --region string region name\n -R, --replace replace existing elements\n -s, --settings stringArray settings file with variable settings (yaml)\n --size int blob size\n --source YAML source meta data (yaml)\n --templater string templater to use (go, none, spiff, subst) (default \u0026#34;subst\u0026#34;)\n --type string source type\n --url string artifact or server url\n --verb string http request method\n --version string source version\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAdd information about the sources, e.g. commits in a Github repository,\nthat have been used to create the resources specified in a resource file to a component version.\nSo far only component archives are supported as target.\u003c/p\u003e","tags":[],"title":"sources"},{"content":"Usage ocm get sources [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}\rOptions -c, --constraints constraints version constraint -h, --help help for sources --latest restrict component versions to latest --lookup stringArray repository name or spec for closure lookup fallback -o, --output string output mode (JSON, json, tree, wide, yaml) -r, --recursive follow component reference nesting --repo string repository name or spec -s, --sort stringArray sort fields\rDescription Get sources of a component version. Sources are specified by identities. An identity consists of a name argument followed by optional \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; arguments.\nIf the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry With the option \u0026ndash;recursive the complete reference tree of a component reference is traversed.\nIf a component lookup for building a reference closure is required the \u0026ndash;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.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json tree wide yaml See Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":118,"permalink":"/docs/cli-reference/get/sources/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get sources [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -c, --constraints constraints version constraint\n -h, --help help for sources\n --latest restrict component versions to latest\n --lookup stringArray repository name or spec for closure lookup fallback\n -o, --output string output mode (JSON, json, tree, wide, yaml)\n -r, --recursive follow component reference nesting\n --repo string repository name or spec\n -s, --sort stringArray sort fields\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eGet sources of a component version. Sources are specified\nby identities. An identity consists of\na name argument followed by optional \u003ccode\u003e\u0026lt;key\u0026gt;=\u0026lt;value\u0026gt;\u003c/code\u003e\narguments.\u003c/p\u003e","tags":[],"title":"sources"},{"content":"Usage ocm show tags [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;version pattern\u0026gt;}\rOptions -h, --help help for tags -l, --latest show only latest tags --repo string repository name or spec -o, --semantic show semantic tags -s, --semver show only semver compliant tags\rDescription Match tags of an artifact against some patterns.\nIf the repository/registry option is specified, the given names are interpreted relative to the specified registry using the syntax\n\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as extended OCI artifact references.\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e]/\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] The \u0026ndash;repo option takes a repository/OCI registry specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz are possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nArtifactSet: v1 CommonTransportFormat: v1 DockerDaemon: v1 Empty: v1 OCIRegistry: v1 oci: v1 ociRegistry Examples $ ocm show tags ghcr.io/open-component-model/ocm/ocm.software/ocmcli/ocmcli-image $ ocm oci show tags ghcr.io/open-component-model/ocm/ocm.software/ocmcli/ocmcli-image\rSee Also ocm show\t— Show tags or versions ","date":"0001-01-01","id":119,"permalink":"/docs/cli-reference/show/tags/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm show tags [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;version pattern\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for tags\n -l, --latest show only latest tags\n --repo string repository name or spec\n -o, --semantic show semantic tags\n -s, --semver show only semver compliant tags\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eMatch tags of an artifact against some patterns.\u003c/p\u003e","tags":[],"title":"tags"},{"content":"","date":"0001-01-01","id":120,"permalink":"/tags/","summary":"","tags":[],"title":"Tags"},{"content":"Description Tiny OCM Installer (TOI) is a small toolset on top of the Open Component Model. It provides a possibility to run images taken from a component version with user configuration and feed them with the content of this component version. It is some basic mechanism, which can be used to execute simple installation steps based on content described by the Open Component Model (see ocm bootstrap package).\nTherefore, a dedicated resource type toiPackage is defined, which describes an installation package to be handled by TOI. When calling the ocm bootstrap package command it is selected by a resource identity pattern. The first resource in given component version matching the pattern is used. A possible use case could be to provide different packages for different environments. The resource can use an identity attribute platform=\u0026lt;value\u0026gt;. By specifying just the platform attribute, the appropriate package will be chosen.\nThe bootstrap command uses this package resource to determine a TOI executor together with executor configuration and additional client specific settings to describe a dedicated installation.\nTo do this the package describes dedicated actions that can be executed by the bootstrap command. Every action (for example install) refers to an executor, which is executed to perform the action.\nAn executor is basically an image following the TOI specification for passing information into the image execution and receiving results from the execution. An executor specification can be described in two ways:\nit either directly describes a resource of type ociImage or it describes a resource of type toiExecutor, which defines the image to use and some default settings. It furthermore describes the features and requirements of the executor image. The package describes configuration values for every configured executor as well as general credentials requirements and required user configuration which must be passed along with the bootstrap command. The executor specification may then optionally map this package global settings into executor specific views.\nAfter validation of the input and its mapping to an executor specific format, finally, a container with the selected executor image is created, that contains the content of the initial component version in form of a Common Transport Archive and all the specified configuration data.\nThe execution of the container may do the needful to achieve the goal of the requested action and provide some labeled output files, which will be passed to the caller.\nThe toiPackage Resource This resource describes an installable software package, whose content is contained in the component version, which contains the package resource.\nIt is a plain yaml resource with the media types media type application/x-yaml, text/yaml or\napplication/vnd.toi.ocm.software.package.v1+yaml) containing information required to control the instantiation of an executor.\nIt has the following format:\ndescription (optional) string\nA short description of the installation package and some configuration hints.\nexecutors []ExecutorSpecification\nconfigTemplate (optional) yaml\nThis is a spiff template used to generate The user config that is finally passed to the executor. If no template is specified the user parameter input will be processed directly without template.\nconfigScheme (optional) yaml\nThis is a JSONSCHEMA used to validate the user input prior to merging with the template\ntemplateLibraries (optional) []ResourceReference\nThis is a list of resources whose content is used as additional stubs for the template processing.\ncredentials (optional) map[string]CredentialRequest\nHere the package may request the provisioning of some credentials with a dedicated name/purpose and structure. If specified the bootstrap command requites the specification of a credentials file providing the information how to satisfy those credential requests.\nadditionalResources (optional) map[string]AdditionalResource)\nA set of additional resources specified by an OCM resource reference or direct data as byte, string or yaml. The key describes the meaning of the resource. The following keys have a special meaning:\nconfigFile: an example template for a parameter file credentialsFile: an example template for a credentials file Those templates can be downloaded with ocm bootstrap configuration.\nExecutorSpecification The executor specification describes the available actions and their mapping to executors. It uses the following fields:\nactions []string\nThe list of actions this executor can be used for. If nothings is specified the executor will be used for all actions. The first matching executor entry will be used to execute an action by the bootstrap command\nresourceRef []ResourceReference\nAn OCM resource reference describing a component version resource relative to the component version containing the package resource.\nconfig (optional) yaml\nThis is optional static executor config passed to the executor as is. It is to describe the set of elements on which the actual execution of the executor should work on.\nparameterMapping (optional) spiff yaml\nThis is an optional spiff template used to process the actual package parameter set passed by the caller to transform it to the requirements of the actual executor.\nA package has a global parameter setting, but possibly multiple different executors for different actions. They might have different requirements/formats concerning the parameter input. Therefore, the executor specification allows to map the provided user input, accordingly.\ncredentialMapping (optional) map[string]string\nThis is an optional mapping to map credential names used by the package to the needs of dedicated executors.\nA package has global parameter setting, but possibly multiple different executors for different action. They might have different requirements/formats concerning the parameter input. There the executor specification allows to map the provided user input, accordingly\nimage (development) object\nInstead of a resourceRef it is possible to directly specify an absolute image.\nATTENTION: this is intended for development purposes, ONLY. Do not use it for final component versions.\nIt has the field ref and the optional field digest.\noutputs (optional) map[string]string\nThis field can be used to map the names of outputs provided by a dedicated executor outputs to package outputs.\nResourceReference An OCM resource reference describes a resource of a component version. It is always evaluated relative to the component version providing the resource that contains the resource reference. It uses the following fields:\nresourcePath (optional) []Identity\nThis is sequence of reference identities used to follow a chain of component version references starting with the actual component version. If not specified the specified resource will be taken from the actual component version.\nresource Identity\nThis is the identity of the resource in the selected component version.\nAdditionalResource This field has either the fields of a ResourceReference to refer to the content of an OCM resource or the field:\ncontent string|[]byte|YAML\nEither a resource reference or the field content must be given. The content field may contain a string or an inline YAML document. For larger content the resource reference form should be preferred.\nIdentity An identity specification is a map[string]string. It describes the identity attributes of a desired resource in a component version. It always has at least one identity attribute name, which is the resource name field of the desired resource. If this resource defines additional identity attributes, the complete set must be specified.\nInput Mapping for Executors An optional parameterMapping in the executor section can be used to process the global package user-specified parameters to provide specific values expected by the executor.\nThis is done by a spiff template. Here special functions are provided to access specific content:\nhasCredentials(string[,string]) bool\nThis function can be used to check whether dedicated credentials are effectively provided for the actual installation.\nThe name is the name of the credentials as described in the credentials request section optionally mapped to the name used for the executor (field credentialMapping).\nIf the second argument is given, it checks for the named property in the credential set.\ngetCredentials(string[,string]) map[string]string | string\nThis functions provides the property set of the provided credentials.\nIf the second argument is given, it returns the named property in the selected credential set.\nIf the property name is an asterisks (*) a single property is expected, whose value is returned.\nUser Config vs Executor Config An executor is typically able to handle a complete class of installations. It describes a dedicated installation mechanism, but not a dedicated installation source. Although, there might be specialized images for dedicated installation sources, in general the idea is to provide more general executors, for example an helm executor, which is able to handle any helm chart, not just a dedicated helm deployment.\nBecause of this, there is a clear separation between an installation specific configuration, which is provided by the user calling the TOI commands, and the parameterization of the executor, which is completely specified in the package.\nThe task of the package is to represent a dedicated deployment source. As such it has to provide information to tell the executor what to install, while the user configuration is used to describe the instance specific settings.\nBack to the example of a helm installer executor, the executor config contained in the package resource describes the helm chart, which should be installed and the way how the user input is mapped to chart values. Here, also the localizations are described in an executor specific way.\nTherefore, an executor expects a dedicated configuration format, which can be specified in the executor resource in form of a JSON scheme.\nThe package then may provide a package specific scheme for the instance configuration. This value-set is dependent on the installation source (the helm chart in this example).\nFor further details you have to refer to the dedicated executor and package definitions.\nThe toiExecutor Resource Instead of directly describing an image resource in the package file, it is possible to refer to a resource of type toiExecutor. This is a yaml file with the media type application/x-yaml, text/yaml or application/vnd.toi.ocm.software.package.v1+yaml) containing common information about the executor. If this flavor is used by the package, this information is used to validate settings in the package specification.\nIt has the following format:\nimageRef ResourceReference\nThis field reference the image resource relative to the component version providing the executor resource\nconfigTemplate (optional) yaml\nThis a spiff template used to generate The executor config from the package specification that is finally passed to the executor. If no template is specified the executor config specified in the package will be processed directly without template.\nconfigScheme (optional) yaml\nThis is a JSONSCHEMA used to validate the executor config from the package prior to merging with the template\ntemplateLibraries (optional) []ResourceReference\nThis is a list of resources whose content is used as additional stubs for the template processing.\ncredentials (optional) map[string]CredentialRequest\nHere the executor may request the provisioning of some credentials with a dedicated name/purpose and structure. If specified it will be propagated to a using package. It this uses an own credentials section, this one will be filtered and checked for the actual executor.\noutputs (optional) map[string]OutputSpecification\nThis field can be used to describe the provided outputs of this executor. The OutputSpecification contains only the field description, so far. It is intended to be extended to contain further information to more formally describe the type of output.\nimage (development) object\nInstead of an imageRef it is possible to directly specify an absolute image.\nATTENTION: this is intended for development purposes, ONLY. Do not use it for final component versions.\nIt has the field ref and the optional field digest.\nClient Parameters Common to all executors a parameter file can be provided by the caller. The package specification may provide a spiff template for this parameter file. It can be used, for example to provide useful defaults. The actually provided content is merged with this template.\nTo validate user configuration a JSON scheme can be provided. The user input is validated first against this scheme before the actual merge is done.\nCredentials Additionally credentials can be requested to be provided by a client. This is done with the credentials field. It is a map of credentials names and their meaning and/or handling.\nIt uses the following fields:\ndescription string\nThis field should describe the purpose of the credential.\nproperties map[string]string\nThis field should describe the used credential fields\nconsumerId map[string]\nThis field can be used to optionally define a consumer id that should be set in the OCM support library, if used by the executor. At least the field type and one additional field must be set.\nCredentials are provided in an ocm config file (see ocm configfile). It uses a memory credential repository with the name default to store the credentials under the given name. Additionally appropriate consumer ids will be propagated, if requested in the credentials request config.\nExecutor Image Contract The executor image is called with the action as additional argument. It is expected that is defines a default entry point and a potentially empty list of standard arguments.\nIt is called with two arguments:\nname of the action to execute\nidentity of the component version containing the package the executor is executed for.\nThis can be used to access the component descriptor to get access to further described resources in the executor config\nThe container used to execute the executor image gets prepared a standard filesystem structure used to provide all the executor inputs before the execution and reading provided executor outputs after the execution.\n/ └── toi ├── inputs │ ├── config configuration from package specification │ ├── ocmrepo OCM filesystem repository containing the complete │ │ component version of the package │ └── parameters merged complete parameter file ├── outputs │ ├── \u0026lt;out\u003e any number of arbitrary output data provided │ │ by executor │ └── ... └── run good practice: typical location for the executed command After processing it is possible to return named outputs. The name of an output must be a filename. The executor section in the package specification maps those files to logical outputs in the outputs section.\n\u0026lt;file name by executor\u003e -\u003e \u0026lt;logical output name\u003e Basically the output may contain any data, but is strongly recommended to use yaml or json files, only. This enables further formal processing by the TOI toolset.\nExamples description: | This package is just an example. executors: - actions: - install resourceRef: resource: name: installerimage config: level: info # parameterMapping: # optional spiff mapping of Package configuration to # .... # executor parameters outputs: test: bla credentials: target: description: kubeconfig for target kubernetes cluster consumerId: type: Kubernetes purpose: target configTemplate: parameters: username: admin password: (( \u0026amp;merge )) configScheme: type: object required: - parameters additionalProperties: false properties: parameters: type: object required: - password additionalProperties: false properties: username: type: string password: type: string additionalResources: configFile: resource: name: config-file\rSee Also ","date":"0001-01-01","id":121,"permalink":"/docs/cli-reference/help/toi-bootstrapping/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eTiny OCM Installer (TOI) is a small toolset on top of the Open Component Model.\nIt provides a possibility to run images taken from a component version with user\nconfiguration and feed them with the content of this component version.\nIt is some basic mechanism, which can be used to execute simple installation\nsteps based on content described by the Open Component Model\n(see \u003ca href=\"https://github.com/open-component-model/ocm/blob/main/docs/reference/ocm_bootstrap_package.md\"\u003eocm bootstrap package\u003c/a\u003e).\u003c/p\u003e","tags":[],"title":"toi-bootstrapping"},{"content":"Usage ocm transfer [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for transfer\rSee Also Sub Commands ocm transfer artifacts\t— transfer OCI artifacts ocm transfer commontransportarchive\t— transfer transport archive ocm transfer componentarchive\t— transfer component archive to some component repository ocm transfer componentversions\t— transfer component version ","date":"0001-01-01","id":122,"permalink":"/docs/cli-reference/transfer/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm transfer [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for transfer\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/transfer/artifacts/\"\u003eocm transfer \u003cb\u003eartifacts\u003c/b\u003e\u003c/a\u003e\t — transfer OCI artifacts\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/transfer/commontransportarchive/\"\u003eocm transfer \u003cb\u003ecommontransportarchive\u003c/b\u003e\u003c/a\u003e\t — transfer transport archive\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/transfer/componentarchive/\"\u003eocm transfer \u003cb\u003ecomponentarchive\u003c/b\u003e\u003c/a\u003e\t — transfer component archive to some component repository\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/transfer/componentversions/\"\u003eocm transfer \u003cb\u003ecomponentversions\u003c/b\u003e\u003c/a\u003e\t — transfer component version\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"transfer"},{"content":"Usage ocm create transportarchive [\u0026lt;options\u0026gt;] \u0026lt;path\u0026gt;\rOptions -f, --force remove existing content -h, --help help for transportarchive -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\rDescription Create a new empty OCM/OCI transport archive. This might be either a directory prepared to host artifact content or a tar/tgz file.\nSee Also ocm create\t— Create transport or component archive ","date":"0001-01-01","id":123,"permalink":"/docs/cli-reference/create/transportarchive/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm create transportarchive [\u0026lt;options\u0026gt;] \u0026lt;path\u0026gt;\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -f, --force remove existing content\n -h, --help help for transportarchive\n -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eCreate a new empty OCM/OCI transport archive. This might be either a directory prepared\nto host artifact content or a tar/tgz file.\u003c/p\u003e","tags":[],"title":"transportarchive"},{"content":"Usage ocm get verified [\u0026lt;options\u0026gt;] {\u0026lt;component / version}\rOptions -h, --help help for verified -o, --output string output mode (JSON, json, wide, yaml) -s, --sort stringArray sort fields --verified string verified file (default \u0026#34;~/.ocm/verified\u0026#34;)\rDescription Get lists remembered verified component versions.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json wide yaml Examples $ ocm get verified $ ocm get verified -f verified.yaml acme.org/component -o yaml\rSee Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":124,"permalink":"/docs/cli-reference/get/verified/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get verified [\u0026lt;options\u0026gt;] {\u0026lt;component / version}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for verified\n -o, --output string output mode (JSON, json, wide, yaml)\n -s, --sort stringArray sort fields\n --verified string verified file (default \u0026#34;~/.ocm/verified\u0026#34;)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eGet lists remembered verified component versions.\u003c/p\u003e","tags":[],"title":"verified"},{"content":"Usage ocm verify [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for verify\rSee Also Sub Commands ocm verify componentversions\t— Verify signature of component version ","date":"0001-01-01","id":125,"permalink":"/docs/cli-reference/verify/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm verify [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for verify\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/verify/componentversions/\"\u003eocm verify \u003cb\u003ecomponentversions\u003c/b\u003e\u003c/a\u003e\t — Verify signature of component version\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"verify"},{"content":"Usage ocm show versions [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;version pattern\u0026gt;}\rOptions -h, --help help for versions -l, --latest show only latest version --repo string repository name or spec -s, --semantic show semantic version\rDescription Match versions of a component against some patterns.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry Examples $ ocm show versions ghcr.io/mandelsoft/cnudie//github.com/mandelsoft/playground\rSee Also ocm show\t— Show tags or versions ","date":"0001-01-01","id":126,"permalink":"/docs/cli-reference/show/versions/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm show versions [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;version pattern\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for versions\n -l, --latest show only latest version\n --repo string repository name or spec\n -s, --semantic show semantic version\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eMatch versions of a component against some patterns.\u003c/p\u003e","tags":[],"title":"versions"}] \ No newline at end of file +[{"content":"The following is an example of a public-key-based signed component descriptor containing a resource, source and one component reference. It uses the default v2 schema.\nThe component is publicly available in the GitHub package repository and can be inspected using the following command:\nocm componentversion get --repo ghcr.io/phoban01/ocm github.com/weaveworks/weave-gitops -oyaml\rmeta: # component schema version schemaVersion: v2 component: # name of the component. Must start with URL-prefix that should be controlled # by the owner of the component to avoid collisions # regex: ^[a-z][-a-z0-9]*([.][a-z][-a-z0-9]*)*[.][a-z]{2,}(/[a-z][-a-z0-9_]*([.][a-z][-a-z0-9_]*)*)+$ name: github.com/weaveworks/weave-gitops # version of the component. Must adhere to “relaxed SemVer” # major, minor (+ optional patch level) - optional v-prefix # regex: ^[v]?(0|[1-9]\\\\d*)(?:\\\\.(0|[1-9]\\\\d*))?(?:\\\\.(0|[1-9]\\\\d*))?(?:-((?:0|[1-9]\\\\d*|\\\\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\\\\.(?:0|[1-9]\\\\d*|\\\\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\\\\+([0-9a-zA-Z-]+(?:\\\\.[0-9a-zA-Z-]+)*))?$ version: v1.0.0 # component provider provider: weaveworks # list of labels that can contain arbitrary metadata in form of K/V pairs # labels can be added on component root, resource, source and reference level labels: - name: link-to-documentation value: https://github.com/weaveworks/weave-gitops # list of repository context the component version \u0026#34;lived\u0026#34; in, # with the current one at the top repositoryContexts: - baseUrl: ghcr.io componentNameMapping: urlPath subPath: phoban01/ocm type: OCIRegistry # list of resources that describe the payload of the component resources: # resource name - name: image # resource location (external repository or internal to this repository) relation: external # resource type type: ociImage # resource version. Must also adhere to “relaxed SemVer” (see `component.versio` above`) version: v0.14.1 # metadata describing how to access the resource access: # type of access information type: ociArtifact imageReference: ghcr.io/weaveworks/wego-app:v0.14.1 # signing metadata for the resource (if component has been signed) digest: hashAlgorithm: SHA-256 normalisationAlgorithm: ociArtifactDigest/v1 value: efa2b9980ca2de65dc5a0c8cc05638b1a4b4ce8f6972dc08d0e805e5563ba5bb # list of sources that describe the input for creating the resources sources: # source name - name: weave-gitops # source type type: git # source version. Must also adhere to “relaxed SemVer” (see `component.versio` above`) version: v0.14.1 # metadata describing how to access the source access: commit: 727513969553bfcc603e1c0ae1a75d79e4132b58 ref: refs/tags/v0.14.1 repoUrl: github.com/weaveworks/weave-gitops type: gitHub # list of references to other components componentReferences: # reference name - name: prometheus # reference version version: v1.0.0 # referenced component name componentName: cncf.io/prometheus # signing metadata for the referenced resource (if component has been signed) digest: hashAlgorithm: SHA-256 normalisationAlgorithm: jsonNormalisation/v1 value: 04eb20b6fd942860325caf7f4415d1acf287a1aabd9e4827719328ba25d6f801 # list of signatures used for signing and verification signatures: # name of the signature - name: ww-dev # digest of the signature including the algorithm used digest: hashAlgorithm: SHA-256 normalisationAlgorithm: jsonNormalisation/v1 value: 4faff7822616305ecd09284d7c3e74a64f2269dcc524a9cdf0db4b592b8cee6a # signature including the algorithm used signature: algorithm: RSASSA-PSS mediaType: application/vnd.ocm.signature.rsa value: 26468587671bdbd2166cf5f69829f090c10768511b15e804294fcb26e552654316c8f4851ed396f279ec99335e5f4b11cb043feb97f1f9a42115f4fda2d31ae8b481b7303b9a913d3a4b92d446fbee9ed487c93b09e513f3f68355040ec08454675e1f407422062abbd2681f70dd5488ad29020b30cfa7e001455c550458da96166bc3243c8426977d73352aface5323fb2b5a374e9c31b272a59c160b85631231c9fc2f23c032401b80fef937029a39111cee34470c61ae86cd4942553466411a5a116159fdcc10e50fe9360c5184028e72d1fe9c7315f26e15d7b4849f62d197501b8cc6b6f1b1391ecc2fc2fc0c1290d2554594505b25fa8f9bfb28c8df24\r","date":"2023-01-17","id":0,"permalink":"/docs/component-descriptors/version-2/","summary":"\u003cp\u003eThe following is an example of a public-key-based signed component descriptor containing a resource, source and one component reference. It uses the default \u003ccode\u003ev2\u003c/code\u003e schema.\u003c/p\u003e","tags":[],"title":"Version 2"},{"content":"","date":"2024-07-10","id":1,"permalink":"/docs/tutorials/ocm-and-gitops/","summary":"","tags":[],"title":"OCM and GitOps"},{"content":"","date":"2020-10-06","id":2,"permalink":"/docs/overview/","summary":"","tags":[],"title":"Overview"},{"content":"The Open Component Model (OCM) project provides an open standard for describing software artifacts and lifecycle metadata, with the purpose to securely deliver and deploy software products. It facilitates asynchronous handling of various lifecycle management processes, such as compliance checks, security scans, deployments, and more, in a decoupled and streamlined manner. OCM provides the ability to deliver software securely, consistently, and compliantly across cloud, on-prem, hybrid and air-gapped environments.\nBelow are the main projects, but please also check out the others in our Github org.\nOCM Specification - The ocm-spec repository contains the OCM specification, which provides a formal description of OCM and its format to describe software artifacts and a storage layer to persist those and make them accessible from remote. OCM Core Library - The ocm core library contains an API for interacting with OCM elements. A guided tour on how to work with the library can be found here. OCM CLI - With the ocm command line interface end users can interact with OCM elements, helping them create component versions and embed them in CI and CD processes. Examples can be found in this Makefile. OCM Controller - The ocm-controllers are designed to enable the automated deployment of software using the Open Component Model and Flux. OCM Website - The ocm-website you are currently visiting. It is built using Hugo and hosted on Github Pages. ","date":"0001-01-01","id":3,"permalink":"/docs/overview/about/","summary":"\u003cp\u003eThe Open Component Model (OCM) project provides an open standard for describing software artifacts and lifecycle metadata, with the purpose to securely deliver and deploy software products. It facilitates asynchronous handling of various lifecycle management processes, such as compliance checks, security scans, deployments, and more, in a decoupled and streamlined manner. OCM provides the ability to deliver software securely, consistently, and compliantly across cloud, on-prem, hybrid and air-gapped environments.\u003c/p\u003e","tags":[],"title":"About the OCM Project"},{"content":"In today\u0026rsquo;s cloud era, enterprises still grapple with tools and processes rooted in outdated on-premises and monolithic thinking. Ad-hoc, fragmented toolsets are used across software lifecycle processes, severely impacting the ability to deliver software securely, consistently, and compliantly across cloud, on-prem, hybrid and air-gapped environments.\nOverly complex, bespoke CI/CD pipelines and the lack of automation across the whole lifecyle process create a tedious, error-prone, and ineffective approach to managing software at scale. This operational nightmare is compounded by the absence of a standardized way to describe software components and their associated technical artifacts.\nRequirements Towards a Modern Software Component Model Immutable and Unique Component Identity A crucial requirement is the ability to assign an immutable and globally unique Component Identity to each software component. This identifier acts as a \u0026ldquo;correlation ID,\u0026rdquo; allowing all lifecycle management processes, such as security compliance and vulnerability scanning, to correlate their outputs to a single, identifiable software component.\nArtifact Descriptions with Location Information The model should facilitate the description of all technical artifacts required for deploying a specific version of a software component. This list, termed a \u0026ldquo;Software Bill of Delivery\u0026rdquo; (SBoD), outlines only the artifacts needed for successful deployment. Additionally, the description must encompass the technical access location from which each artifact can be retrieved.\nSeparation of Component Identity and Artifact Location In certain environments, artifacts are required to be stored in local registries, mandating the copying of technical artifacts into these target environments. This is especially true for private or air-gapped scenarios where retrieving artifacts from their original location is not feasible due to restricted or non-existent internet access or compliance reasons. To address this, the model must enable the separation of a software component\u0026rsquo;s immutable ID from the current location of its technical artifacts. The Component Identity must remain stable across all boundaries and system environments, while the artifact locations should be changeable.\nTechnology-Agnostic At its core, the model must be technology-agnostic, capable of supporting not only modern containerized cloud products but also legacy software. Many larger companies operate hybrid landscapes comprising modern cloud-native products running on cloud infrastructures and legacy applications that have not yet transitioned (or may never transition) to the public cloud or be containerized. To cater to such scenarios, it is crucial for the software component model to handle both cloud-native and legacy software, necessitating complete agnosticism regarding the technologies used by the described software components and their artifacts.\nExtensibility The model should be designed with extensibility in mind, enabling straightforward adaptation to future trends and technologies without constantly impacting the tools and processes employed for software lifecycle management.\nSigning The model should provide out-of-the-box support for signing and verification processes. This capability allows consumers of software components to verify that the delivered components have not been tampered with. Importantly, the signing and verification support must account for the possibility that the technical artifact locations may change over time, implying that these specific locations should not be part of the signing process.\nNetwork Effects Components described using OCM are primed for secure consumption and immediate integration into higher-level components (or products). The ability to link to trusted and already attested components can facilitate adoption across different teams within an organization, directly improving efficiency (akin to the proficiency of package models like Maven or npm). Moreover, with other parties also describing components using OCM, commercial contracts can cover the necessary technical trust outside the organization, simplifying the secure import and compliant re-use of these components. OCM envisions fostering a network effect across the industry.\nOCM: Streamlining Software Lifecycle Management The Open Component Model (OCM) is the much-needed life-raft for organizations drowning in software lifecycle management complexity. By establishing a standardized way to describe software components and their artifacts, OCM tackles the core issues plaguing enterprises. By linking additional metadata using OCM’s identities, it facilitates asynchronous handling of various lifecycle management processes, such as compliance checks, security scans, deployments, and more, in a decoupled and streamlined manner.\nUnique Component Identities: OCM assigns an immutable, globally unique ID to each component, enabling seamless correlation across all lifecycle tools and processes like a \u0026ldquo;compliance dashboard\u0026rdquo;.\nSoftware Bill of Delivery: OCM enables the precise specification of all technical artifacts required for delivering a software component. This compilation, termed a \u0026ldquo;Software Bill of Delivery\u0026rdquo; (SBoD), comprehensively lists the necessary artifacts along with their corresponding location information to facilitate seamless access.\nStable IDs, Changing Artifact Locations: OCM cleanly separates the immutable component ID from the changeable artifact locations, essential for hybrid/private environments.\nTechnology Agnosticism: Being agnostic to implementation technologies like container images, NPM packages or binaries, OCM effortlessly handles both cloud-native and legacy apps.\nFuture-Proof Extensibility: OCM\u0026rsquo;s extensible design allows simple adaptation to emerging trends without disrupting existing tooling.\nTrusted Signatures: Built-in signing and verification ensure artifact integrity even as artifact locations change over time.\nWith OCM, a \u0026ldquo;single source of truth\u0026rdquo; is established for all software artifacts across the lifecycle. Compliance checks, security scans, deployments, and more become streamlined operations anchored to OCM\u0026rsquo;s standardized component definitions.\nMoreover, by fostering component reuse within and across organizations, OCM unlocks powerful network effects akin to package managers, boosting productivity, and simplifying commercial software consumption.\nIn essence, OCM is the missing link that finally empowers organizations to tame the software lifecycle beast through a consistent, location-agnostic way to identify, access, exchange and verify software artifacts at scale.\n","date":"2020-10-06","id":4,"permalink":"/docs/overview/benefits-of-ocm/","summary":"\u003cp\u003eIn today\u0026rsquo;s cloud era, enterprises still grapple with tools and processes rooted in outdated on-premises and monolithic thinking. Ad-hoc, fragmented toolsets are used across software lifecycle processes, severely impacting the ability to deliver software securely, consistently, and compliantly across cloud, on-prem, hybrid and air-gapped environments.\u003c/p\u003e","tags":[],"title":"Benefits of OCM"},{"content":"As the Open Component Model (OCM) revolves around components, it is essential to establish a common understanding of the fundamental terminology employed throughout this website. The following section provides concise definitions of key terms, laying the groundwork for the documentation and tutorials that follow.\nFor a comprehensive exploration of every aspect of this topic, please refer to the OCM Specification OCM Specification and its Glossary.\nComponents in OCM The concept of a Component can vary widely, often defined with very specific views on granularity or other technical attributes. OCM takes a different approach, focusing on the intended purpose and overall meaning of components.\nIn OCM, Components group a set of semantically related Component Versions. Each Component Version is uniquely and globally identified by a Component Identity and can reference other Components. A Component Version can also contain Artifacts and a formal description on how to access them. These Artifacts come in two categories: resources, which describe the payload (e.g.,OCI images), and sources, which describe the input for creating resources (e.g., source code).\nOCM Coordinates OCM Coordinates are used to reference OCM Component Versions and Artifacts within OCM Component Versions. Coordinates referring to an OCM Component Version are also called Component Identity, whereas relative Coordinates referring to an artifact are called Artifact Identity. Component Identities are globally unique and may be used to refer to full Component Versions. Artifact Identities are always relative to a Component Version and may only be used in conjunction with a Component Identity.\nIn detail:\nComponent Identity Component Name: Identifies a component. Must start with URL-prefix that should be controlled by the owner of the component to avoid collisions. Component Version: If used with a Component name, identifies a specific Component Version. Must adhere to \u0026ldquo;relaxed SemVer\u0026rdquo; (major, minor (+ optional patch level) - optional v-prefix). Artifact Identity Within a Component Version, all Artifacts must have a unique identity. Every Source Identity or Resource Identity always includes a name that typically expresses the intended purpose.\nArtifacts may also have additional extraIdentity attributes that contribute to their identities. extraIdentity attributes are string-to-string maps.\nExamples Assuming there is a component named example.org/my-component with two versions, 1.2.3 and 1.3.0, declaring a resource with the name my-resource, the following OCM Coordinates can be used to reference different elements:\nexample.org/my-component: all versions of the component (1.2.3 + 1.3.0) example.org/my-component:1.2.3: version 1.2.3 of the component example.org/my-component:1.2.3:resource/my-resource: my-resource as declared by the component version ","date":"2020-10-06","id":5,"permalink":"/docs/overview/important-terms/","summary":"\u003cp\u003eAs the Open Component Model (OCM) revolves around components, it is essential to establish a common understanding of the fundamental terminology employed throughout this website. The following section provides concise definitions of key terms, laying the groundwork for the documentation and tutorials that follow.\u003c/p\u003e","tags":[],"title":"Important Terms"},{"content":"Where to find the OCM specification The most up-to-date version of the OCM specification offers you a deep insight to all technical details of the Open Component Model and explains all elements the model OCM is based on.\n","date":"0001-01-01","id":6,"permalink":"/docs/overview/specification/","summary":"\u003ch2 id=\"where-to-find-the-ocm-specification\"\u003eWhere to find the OCM specification\u003c/h2\u003e\n\u003cp\u003eThe most up-to-date version of the \u003ca href=\"https://github.com/open-component-model/ocm-spec/blob/main/README.md\"\u003eOCM specification\u003c/a\u003e offers you a deep insight to all technical details of the Open Component Model and explains all elements the model OCM is based on.\u003c/p\u003e","tags":[],"title":"Specification"},{"content":"","date":"2023-11-07","id":7,"permalink":"/docs/getting-started/","summary":"","tags":[],"title":"Getting Started"},{"content":"Overview You can install the latest release of the OCM CLI from any of the following sources (more details below):\nHomebrew Nix AUR Docker Podman GitHub Releases Bash To install with bash for macOS or Linux, execute the following command:\ncurl -s https://ocm.software/install.sh | sudo bash\rInstall using Homebrew # Homebrew (macOS and Linux) brew install open-component-model/tap/ocm\rInstall using Nix (with Flakes) # Nix (macOS, Linux, and Windows) # ad hoc cmd execution nix run github:open-component-model/ocm -- --help nix run github:open-component-model/ocm#helminstaller -- --help # install development version nix profile install github:open-component-model/ocm # or release \u0026lt;version\u0026gt; nix profile install github:open-component-model/ocm/\u0026lt;version\u0026gt; #check installation nix profile list | grep ocm # optionally, open a new shell and verify that cmd completion works ocm --help\rsee: Flakes\nInstall from AUR (Arch Linux User Repository) git-url: https://aur.archlinux.org/ocm-cli.git package-url: https://aur.archlinux.org/packages/ocm-cli\n# if not using a helper util git clone https://aur.archlinux.org/ocm-cli.git cd ocm-cli makepkg -i\rAUR Documentation\nInstall using Docker / Podman podman run -t ghcr.io/open-component-model/ocm:latest --help\rBuild and Run It Yourself podman build -t ocm . podman run --rm -t ocm --loglevel debug --help\ror interactively:\npodman run --rm -it ocm /bin/sh\rYou can pass in the following arguments to override the predefined defaults:\nGO_VERSION: The golang version to be used for compiling. ALPINE_VERSION: The alpine version to be used as the base image. GO_PROXY: Your go proxy to be used for fetching dependencies. Please check hub.docker.com for possible version combinations.\npodman build -t ocm --build-arg GO_VERSION=1.22 --build-arg ALPINE_VERSION=3.19 --build-arg GO_PROXY=https://proxy.golang.org .\ron MS Windows using Chocolatey choco install ocm-cli\rsee: chocolatey community package: ocm-cli\nusing winget winget install ocm-cli\rsee: microsoft/winget-pkgs: Open-Component-Model\nBuilding from Source Prerequisites git golang make Installation Process Clone the open-component-model/ocm repo:\ngit clone https://github.com/open-component-model/ocm\rEnter the repository directory (cd ocm/) and install the cli using make:\nmake install\rPlease note that the OCM CLI is installed in your go/bin directory, so you might need to add this directory to your PATH.\nVerify the installation:\nocm version\r","date":"0001-01-01","id":8,"permalink":"/docs/getting-started/installing-the-ocm-cli/","summary":"\u003ch2 id=\"overview\"\u003eOverview\u003c/h2\u003e\n\u003cp\u003eYou can install the latest release of the OCM CLI from any of the following sources (more details below):\u003c/p\u003e","tags":[],"title":"Installing the OCM CLI"},{"content":"","date":"2023-03-13","id":9,"permalink":"/docs/getting-started/getting-started-with-ocm/","summary":"","tags":[],"title":"First Steps with OCM"},{"content":"This and the following chapters walk you through some basic steps to get started with OCM concepts and the OCM CLI. You will learn how to create a component version, display and examine the component, and how to transport and sign it.\nTo follow the steps described in this section, you will need to:\nInstall the OCM Command Line Interface (CLI) The CLI is used to interact with component versions and registries. Install it like described in Installing the OCM CLI.\nObtain Access to an OCM Repository This can be any OCI registry for which you have write permission (e.g., GitHub Packages). An OCM repository based on an OCI registry is identified by a leading OCI repository prefix. For example: ghcr.io/\u0026lt;YOUR-ORG\u0026gt;/ocm.\nObtain Credentials for the CLI to Access the OCM Repository Using the Docker Configuration File The easiest way to do this is to reuse your Docker configuration json file.\nTo do this, create a file named .ocmconfig in your home directory with the following content:\ntype: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software repositories: - repository: type: DockerConfig/v1 # The path to the Docker configuration file dockerConfigFile: \u0026#34;~/.docker/config.json\u0026#34; propagateConsumerIdentity: true - type: attributes.config.ocm.software attributes: cache: ~/.ocm/cache\rUsing Basic Authentication Alternatively, you can use basic authentication. Create a file named .ocmconfig in your home directory with the following content:\ntype: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software consumers: - identity: type: ociRegistry hostname: \u0026lt;YOUR-REGISTRY\u0026gt;/\u0026lt;YOUR-REPO\u0026gt; # e.g. ghcr.io/acme/acme credentials: - type: Credentials properties: username: \u0026lt;YOUR-USERNAME\u0026gt; password: \u0026lt;YOUR-PASSWORD\u0026gt;\rMore information on the credentials topic can be seen by running the OCM CLI help topic command ocm credential-handling and in this guide with many examples for different repository types.\n","date":"2023-03-13","id":10,"permalink":"/docs/getting-started/getting-started-with-ocm/prerequisites/","summary":"\u003cp\u003eThis and the following chapters walk you through some basic steps to get started with OCM concepts and the OCM CLI.\nYou will learn how to create a component version, display and examine the component, and how to transport and sign it.\u003c/p\u003e","tags":[],"title":"Prerequisites"},{"content":"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.\nComponent 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.\nNote 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.\nThe command ocm add componentversions directly creates a component version from a component-constructor.yaml file and stores it in a local CTF archive.\nCreate 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.\nWe start by creating a test folder where we execute all required steps for this example and navigating into it:\nmkdir /tmp/helloworld cd /tmp/helloworld\rNow we download the podinfo Helm Chart that we want to use as local resource and extract it:\nhelm repo add podinfo https://stefanprodan.github.io/podinfo helm pull --untar podinfo/podinfo\rCreate 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).\nComponent 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.\nAs mentioned before our example component will just contain a Helm Chart and a Docker image as resources:\n# specify a schema to validate the configuration and get auto-completion in your editor # yaml-language-server: $schema=https://ocm.software/schemas/configuration-schema.yaml components: - name: github.com/acme.org/helloworld # version needs to follow \u0026#34;relaxed\u0026#34; SemVer version: 1.0.0 provider: name: acme.org resources: # local Helm chart resource - name: mychart type: helmChart input: type: helm path: ./podinfo # remote image resource - name: image type: ociArtifact version: 1.0.0 access: type: ociArtifact imageReference: gcr.io/google_containers/echoserver:1.10\rA resource is described either by its access information to a remote repository or by locally provided resources.\nFor remote access, the field access is used to describe the access method. The type field is used to specify the kind of access.\nIf 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.\nAvailable access and input types are described here.\nFor more complex scenarios, the description files might use variable substitution (templating), see Best Practices.\nAdd 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:\nocm add componentversions --create --file ctf-hello-world component-constructor.yaml\rprocessing component-constructor.yaml... processing document 1... processing index 1 found 1 component adding component github.com/acme.org/helloworld:1.0.0... adding resource helmChart: \u0026#34;name\u0026#34;=\u0026#34;mychart\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;\u0026lt;componentversion\u0026gt;\u0026#34;... adding resource ociArtifact: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;1.0.0\u0026#34;...\rWhat happened? The command creates the CTF archive (option --create) and adds the listed components with the described resources.\nctf-hello-world/ ├── artifact-index.json └── blobs ├── sha256.125cf912d0f67b2b49e4170e684638a05a12f2fcfbdf3571e38a016273620b54 ├── sha256.1cb2098e31e319df7243490464b48a8af138389abe9522c481ebc27dede4277b ├── sha256.974e652250ffaba57b820c462ce603fc1028a608b0fa09caef227f9e0167ce09 └── sha256.d442bdf33825bace6bf08529b6f00cf0aacc943f3be6130325e1eb4a5dfae3a5\rThe transport archive\u0026rsquo;s contents can be found in artifact-index.json. This file contains the list of component version artifacts to be transported.\njq . ${CTF_ARCHIVE}/artifact-index.json\r{ \u0026#34;schemaVersion\u0026#34;: 1, \u0026#34;artifacts\u0026#34;: [ { \u0026#34;repository\u0026#34;: \u0026#34;component-descriptors/github.com/acme/helloworld\u0026#34;, \u0026#34;tag\u0026#34;: \u0026#34;1.0.0\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:d3cf4858f5387eaea194b7e40b7f6eb23460a658ad4005c5745361978897e043\u0026#34; } ] }\rThe 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/.\nThe component version is described as an OCI manifest:\njq . ${CTF_ARCHIVE}/blobs/sha256.d3cf4858f5387eaea194b7e40b7f6eb23460a658ad4005c5745361978897e043\r{ \u0026#34;schemaVersion\u0026#34;: 2, \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.manifest.v1+json\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.ocm.software.component.config.v1+json\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:0dd94de11c17f995648c8e817971581bce4b016f53d4d2bf2fff9fcda37d7b95\u0026#34;, \u0026#34;size\u0026#34;: 201 }, \u0026#34;layers\u0026#34;: [ { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.ocm.software.component-descriptor.v2+yaml+tar\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:4ab29c8acb0c8b002a5037e6d9edf2d657222da76fee2a10f38d65ecd981d0c6\u0026#34;, \u0026#34;size\u0026#34;: 3072 }, { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.manifest.v1+tar+gzip\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:b2dc5088f005d27ea39b427c2e67e91e2b6b80d3e85eca2476a019003c402904\u0026#34;, \u0026#34;size\u0026#34;: 16122 } ] }\rNotice 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:\ntar xvf ${CTF_ARCHIVE}/blobs/sha256.4ab29c8acb0c8b002a5037e6d9edf2d657222da76fee2a10f38d65ecd981d0c6 -O - component-descriptor.yaml\rmeta: schemaVersion: v2 component: name: github.com/acme/helloworld version: 1.0.0 provider: acme.org componentReferences: [] repositoryContexts: [] resources: - access: localReference: sha256:b2dc5088f005d27ea39b427c2e67e91e2b6b80d3e85eca2476a019003c402904 mediaType: application/vnd.oci.image.manifest.v1+tar+gzip referenceName: github.com/acme/helloworld/podinfo:6.7.0 type: localBlob digest: ... name: mychart relation: local type: helmChart version: 1.0.0 - access: imageReference: gcr.io/google_containers/echoserver:1.10 type: ociArtifact digest: ... name: image relation: external type: ociArtifact version: 1.0.0 sources: []\rThe 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.\n","date":"2023-03-13","id":11,"permalink":"/docs/getting-started/getting-started-with-ocm/create-a-component-version/","summary":"\u003ch2 id=\"creating-and-storing-component-versions\"\u003eCreating and Storing Component Versions\u003c/h2\u003e\n\u003cp\u003eComponent Versions are created using a \u003ccode\u003ecomponent-constructor.yaml\u003c/code\u003e 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.\u003c/p\u003e","tags":[],"title":"Create a Component Version"},{"content":"List Component Versions To show a component stored in an OCM repository or CTF archive (which itself is an OCM repository), the ocm get componentversion command can be used:\nocm get componentversion ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0\rCOMPONENT VERSION PROVIDER ocm.software/toi/demo/helmdemo 0.12.0 ocm.software\rTo see the component descriptor of the displayed component version, use the output format option -o yaml:\nocm get cv ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 -o yaml\rcomponent: componentReferences: - componentName: ocm.software/toi/installers/helminstaller name: installer version: 0.12.0 creationTime: \u0026#34;2024-07-19T14:32:13Z\u0026#34; name: ocm.software/toi/demo/helmdemo provider: ocm.software repositoryContexts: - baseUrl: ghcr.io componentNameMapping: urlPath subPath: open-component-model/ocm type: OCIRegistry resources: - access: localReference: sha256:8a2fe6af4ce56249094622c9d618e24b4cfb461a7dfa6a42cce31749189bc499 mediaType: application/vnd.toi.ocm.software.package.v1+yaml type: localBlob digest: ... labels: - name: commit value: e5ca3001323b75ee5793a786089f1f410e9e8db3 name: package relation: local type: toiPackage version: 0.12.0 - access: imageReference: ghcr.io/open-component-model/ocm/ocm.software/toi/demo/helmdemo/echoserver:0.1.0 type: ociArtifact digest: ... name: chart relation: local type: helmChart version: 0.12.0 ...\rTo refer to the content of a component repository, the component name can be appended to the repository specification separated by // (you can also use the --repo option to specifiy the repository).\nIn the example above, ghcr.io/open-component-model/ocm is the OCM repository, whereas ocm.software/toi/demo/helmdemo is the component stored in this component repository.\nOptionally, a specific version can be appended, separated by a colon (:). If no version is specified, all component versions will be displayed.\nWith the option --recursive, it is possible to show the complete component version, including the component versions it references.\nocm get cv ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 --recursive\rREFERENCEPATH COMPONENT VERSION PROVIDER IDENTITY ocm.software/toi/demo/helmdemo 0.12.0 ocm.software ocm.software/toi/demo/helmdemo:0.12.0 ocm.software/toi/installers/helminstaller 0.12.0 ocm.software \u0026#34;name\u0026#34;=\u0026#34;installer\u0026#34;\rTo get a tree view, add the option -o tree:\nocm get cv ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 --recursive -o tree\rNESTING COMPONENT VERSION PROVIDER IDENTITY └─ ⊗ ocm.software/toi/demo/helmdemo 0.12.0 ocm.software └─ ocm.software/toi/installers/helminstaller 0.12.0 ocm.software \u0026#34;name\u0026#34;=\u0026#34;installer\u0026#34;\rAs mentioned before a CTF archive itself is an OCM repository, so we can execute the same commands on a CTF archive. So, let\u0026rsquo;s get the information about the component github.com/acme.org/helloworld we created in the previous step and that we stored in the CTF archive /tmp/helloworld/ctf-hello-world:\nocm get cv /tmp/helloworld/ctf-hello-world//github.com/acme.org/helloworld:1.0.0\rCOMPONENT VERSION PROVIDER github.com/acme.org/helloworld 0.1.0 ocm.software\rList the Resources of a Component Version To list the resources found in a component version tree, the command ocm get resources can be used:\nocm get resources ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 --recursive -o tree\rCOMPONENT NAME VERSION IDENTITY TYPE RELATION └─ ocm.software/toi/demo/helmdemo 0.12.0 ├─ chart 0.12.0 helmChart local ├─ config-example 0.12.0 yaml local ├─ creds-example 0.12.0 yaml local ├─ image 1.0 ociImage external ├─ package 0.12.0 toiPackage local └─ ocm.software/toi/installers/helminstaller installer 0.12.0 ├─ toiexecutor 0.12.0 toiExecutor local └─ toiimage 0.12.0 ociImage local\rDownload the Resources of a Component Version Use the ocm download command to download resources such as component versions, individual resources or artifacts:\nocm download resource ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 chart -O helmchart.tgz\rhelmchart.tgz: 4707 byte(s) written\rBecause it is stored as OCI artifact in an OCI registry, the filesystem format used for OCI artifacts is the blob format.\nWhat happened? The file helmchart.tgz was downloaded.\ntar xvf helmchart.tgz\rx index.json x oci-layout x blobs x blobs/sha256.a9dd654eed17e786b5c5445e8bc48f3a47371c2efe392a53a3fbecd9e942b696 x blobs/sha256.c8017985866ceb44c2426a4ad9a429d6aec1f6818cb6dccbf964623139c1d1d5 x blobs/sha256.ea8e5b44cd1aff1f3d9377d169ad795be20fbfcd58475a62341ed8fb74d4788c\r$ jq . index.json\r{ \u0026#34;schemaVersion\u0026#34;: 2, \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.index.v1+json\u0026#34;, \u0026#34;manifests\u0026#34;: [ { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.manifest.v1+json\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:c8017985866ceb44c2426a4ad9a429d6aec1f6818cb6dccbf964623139c1d1d5\u0026#34;, \u0026#34;size\u0026#34;: 410, \u0026#34;annotations\u0026#34;: { \u0026#34;org.opencontainers.image.ref.name\u0026#34;: \u0026#34;0.1.0\u0026#34;, \u0026#34;software.ocm/tags\u0026#34;: \u0026#34;0.1.0\u0026#34; } } ], \u0026#34;annotations\u0026#34;: { \u0026#34;software.ocm/main\u0026#34;: \u0026#34;sha256:c8017985866ceb44c2426a4ad9a429d6aec1f6818cb6dccbf964623139c1d1d5\u0026#34; } }\rDownload with Download Handlers To use a format more suitable for the content technology, enable the usage of download handlers.\nIf a download handler is available for the artifact type and the blob media type used to store the blob in the OCM repository, it will convert the blob format into a more suitable format:\nocm download resource -d ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 chart -O helmchart.tgz\rhelmchart.tgz: 3763 byte(s) written\rWhat happened? The downloaded archive is now a regular Helm Chart archive:\ntar tvf helmchart.tgz\r-rw-r--r-- 0 0 0 136 Jul 19 16:32 echoserver/Chart.yaml -rw-r--r-- 0 0 0 1842 Jul 19 16:32 echoserver/values.yaml -rw-r--r-- 0 0 0 1755 Jul 19 16:32 echoserver/templates/NOTES.txt -rw-r--r-- 0 0 0 1802 Jul 19 16:32 echoserver/templates/_helpers.tpl -rw-r--r-- 0 0 0 1848 Jul 19 16:32 echoserver/templates/deployment.yaml -rw-r--r-- 0 0 0 922 Jul 19 16:32 echoserver/templates/hpa.yaml -rw-r--r-- 0 0 0 2083 Jul 19 16:32 echoserver/templates/ingress.yaml -rw-r--r-- 0 0 0 367 Jul 19 16:32 echoserver/templates/service.yaml -rw-r--r-- 0 0 0 324 Jul 19 16:32 echoserver/templates/serviceaccount.yaml -rw-r--r-- 0 0 0 385 Jul 19 16:32 echoserver/templates/tests/test-connection.yaml -rw-r--r-- 0 0 0 349 Jul 19 16:32 echoserver/.helmignore\rDownload an Image For example, for OCI images, the OCI format is more suitable:\nocm download resource ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 image -O image.tgz\rimage.tgz: 46181313 byte(s) written\rWhat happened? The file image.tgz was downloaded.\ntar xvf image.tgz\rx index.json x oci-layout x blobs x blobs/sha256.06679f57dba70a6875e4ae5843ba2483ecab6ec48182ca8720ddc5b1863bad52 x blobs/sha256.28c6282d04f63710146ace6c7be14a40c7ee6a71a2f91316928469e4aafe0d92 x blobs/sha256.2d3e25b9e93ad26878862abee5ed02683206f6f6d57e311cdd1dedf3662b61c8 x blobs/sha256.365ec60129c5426b4cf160257c06f6ad062c709e0576c8b3d9a5dcc488f5252d x blobs/sha256.4b12f3ef8e65aaf1fd77201670deb98728a8925236d8f1f0473afa5abe9de119 x blobs/sha256.76d46396145f805d716dcd1607832e6a1257aa17c0c2646a2a4916e47059dd54 x blobs/sha256.7fd34bf149707ca78b3bb90e4ba68fe9a013465e5d03179fb8d3a3b1cac8be27 x blobs/sha256.b0e3c31807a2330c86f07d45a6d80923d947a8a66745a2fd68eb3994be879db6 x blobs/sha256.bc391bffe5907b0eaa04e96fd638784f77d39f1feb7fbe438a1dae0af2675205 x blobs/sha256.cb5c1bddd1b5665e1867a7fa1b5fa843a47ee433bbb75d4293888b71def53229 x blobs/sha256.d5157969118932d522396fe278eb722551751c7aa7473e6d3f03e821a74ee8ec x blobs/sha256.e0962580d8254d0b1ef35006d7e2319eb4870e63dc1f9573d2406c7c47d442d2\rjq . index.json\r{ \u0026#34;schemaVersion\u0026#34;: 2, \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.index.v1+json\u0026#34;, \u0026#34;manifests\u0026#34;: [ { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.docker.distribution.manifest.v2+json\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:cb5c1bddd1b5665e1867a7fa1b5fa843a47ee433bbb75d4293888b71def53229\u0026#34;, \u0026#34;size\u0026#34;: 2400, \u0026#34;annotations\u0026#34;: { \u0026#34;org.opencontainers.image.ref.name\u0026#34;: \u0026#34;1.10\u0026#34;, \u0026#34;software.ocm/tags\u0026#34;: \u0026#34;1.10\u0026#34; } } ], \u0026#34;annotations\u0026#34;: { \u0026#34;software.ocm/main\u0026#34;: \u0026#34;sha256:cb5c1bddd1b5665e1867a7fa1b5fa843a47ee433bbb75d4293888b71def53229\u0026#34; } }\rDownload an Executable The Open Component Model allows to publish platform-specific executables. In this case, the platform specification is used by convention as extra identity for the artifacts that are contained in the component version.\nExample:\nocm get componentversion ghcr.io/open-component-model/ocm//ocm.software/ocmcli:0.1.0-dev -o yaml\r... resources: - name: ocmcli extraIdentity: architecture: amd64 os: linux relation: local type: executable version: 0.1.0-dev access: localReference: sha256:1a8827761f0aaa897d1d4330c845121c157e905d1ff300ba5488f8c423bc7cd9 mediaType: application/octet-stream type: localBlob - name: ocmcli extraIdentity: architecture: arm64 os: darwin relation: local type: executable version: 0.1.0-dev access: localReference: sha256:9976b18dc16ae2b2b3fc56686f18f4896d44859f1ea6221f70e83517f697e289 mediaType: application/octet-stream type: localBlob ...\rNote that the resources shown above have the same name and type executable but a different extra-identity. If a component version complies to this convention, executables can directly be downloaded for the specified platform with the use of the -x option. If only one executable is contained in the component version, the resource name can be omitted. Example:\nocm download resource -x --latest ghcr.io/open-component-model/ocm//ocm.software/ocmcli\rocm: 83369938 byte(s) written\rWhat happened? file ocm\rocm: Mach-O 64-bit executable arm64\rWith the option --latest, the latest matching component version is used for download. With the option --constraints, version constraints can be configured. For example: --constraints 0.1.x will select all patch versions of 0.1. Together with --latest, the latest patch version is selected.\nThe option -x enables the executable download handler, which provides the x-bit of the downloaded files. Additionally, it filters all matching resources for executables and the correct platform.\nDownload a Full Component Version Download entire component versions using the ocm download componentversion command:\nocm download componentversions ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 -O helloworld\rhelloworld: downloaded\rThe result is a CTF archive. This can then be modified using the ocm add ... commands shown earlier.\nWhat happened? The component version was downloaded.\ntree helloworld\rhelloworld/ ├── blobs │ ├── sha256.87cef1e2233bf5591030ac854e2556fbe6a00a28bb5640e25a9cb69ece519c5a │ ├── sha256.8a2fe6af4ce56249094622c9d618e24b4cfb461a7dfa6a42cce31749189bc499 │ └── sha256.e790920a11de2016de64225280efcf062e14b767955f7508de64fd5192e3fb3a └── component-descriptor.yaml\rDownload OCI Artifacts Download OCI artifacts from an OCI registry, such as OCI images, with the ocm download artifacts command:\nocm download artifact ghcr.io/open-component-model/ocm-controller:v0.24.0 -O ocm-controller\rocm-controller: downloaded\rWhat happened? The OCI image echoserver was downloaded.\ntree echoserver\rocm-controller/ ├── blobs │ ├── sha256.05d57e68048827c243cd477025f96064df9f4d83b8639ed04306f0647c9cfe78 │ ├── sha256.0f8b424aa0b96c1c388a5fd4d90735604459256336853082afb61733438872b5 │ ├── sha256.1069fc2daed1aceff7232f4b8ab21200dd3d8b04f61be9da86977a34a105dfdc │ ├── sha256.286c61c9a31ace5fa0b8832c8e8e30d66bf32138f2f787463235aa0071f714ea │ ├── sha256.2bdf44d7aa71bf3a0da2de0563ad0e3882948d699b4991edf8c0ab44e7f26ae3 │ ├── sha256.35fddc32f468fc8d276fa1b6a72cac27f35a0080233c2ddc6a03fab224024dbc │ ├── sha256.3f4e2c5863480125882d92060440a5250766bce764fee10acdbac18c872e4dc7 │ ├── sha256.452e9eed7ecfd0c2b44ac6fda20cee66ab98aec38ba30aa868e02445be7c8bb0 │ ├── sha256.80a8c047508ae5cd6a591060fc43422cb8e3aea1bd908d913e8f0146e2297fea │ ├── sha256.9375d0c4fac611287075434624a464af5b6bb026947698a06577ad348f607d56 │ ├── sha256.b40161cd83fc5d470d6abe50e87aa288481b6b89137012881d74187cfbf9f502 │ ├── sha256.c8022d07192eddbb2a548ba83be5e412f7ba863bbba158d133c9653bb8a47768 │ ├── sha256.d557676654e572af3e3173c90e7874644207fda32cd87e9d3d66b5d7b98a7b21 │ └── sha256.d858cbc252ade14879807ff8dbc3043a26bbdb92087da98cda831ee040b172b3 ├── index.json └── oci-layout\r","date":"2023-03-13","id":12,"permalink":"/docs/getting-started/getting-started-with-ocm/display-and-examine-component-versions/","summary":"\u003ch2 id=\"list-component-versions\"\u003eList Component Versions\u003c/h2\u003e\n\u003cp\u003eTo show a component stored in an OCM repository or CTF archive (which itself is an OCM repository), the \u003ca href=\"https://github.com/open-component-model/ocm/blob/main/docs/reference/ocm_get_componentversions.md\"\u003e\u003ccode\u003eocm get componentversion\u003c/code\u003e\u003c/a\u003e command can be used:\u003c/p\u003e","tags":[],"title":"Display and Examine Component Versions"},{"content":"The section Bundle Composed Components explained how to bundle multiple component version into a transport archive.\nDuring the transfer, it is possible to include component references as local blobs. It is also possible to include references in a recursive way.\nHere is an example of a recursive transfer from one OCI registry to another, which includes resources and references:\nocm transfer componentversion --recursive --copy-resources ghcr.io/open-component-model/ocm//ocm.software/toi/demo/helmdemo:0.12.0 another-registry/\rtransferring version \u0026#34;ocm.software/toi/demo/helmdemo:0.12.0\u0026#34;... transferring version \u0026#34;ocm.software/toi/installers/helminstaller:0.12.0\u0026#34;... ...resource 0 toiimage[ociImage](ocm.software/toi/installers/helminstaller/helminstaller:0.12.0)... ...resource 1 toiexecutor[toiExecutor]... ...adding component version... ...resource 0 package[toiPackage]... ...resource 1 chart[helmChart](ocm.software/toi/demo/helmdemo/echoserver:0.1.0)... ...resource 2 image[ociImage](google-containers/echoserver:1.10)... ...resource 3 config-example[yaml]... ...resource 4 creds-example[yaml]... ...adding component version... 2 versions transferred\rThe OCM CLI\u0026rsquo;s transfer command can be used to transfer component versions, component archives, transport archives, and artifacts. See ocm transfer -h for more information.\nMore examples on the transport archive and the common transfer format (CTF) can be found in the ocm-spec.\n","date":"2023-03-13","id":13,"permalink":"/docs/getting-started/getting-started-with-ocm/transport-ocm-component-versions/","summary":"\u003cp\u003eThe section \u003ca href=\"/docs/getting-started/getting-started-with-ocm/create-a-component-version#bundle-composed-components\"\u003eBundle Composed Components\u003c/a\u003e explained how to bundle multiple component version into a transport archive.\u003c/p\u003e\n\u003cp\u003eDuring the transfer, it is possible to include component references as local blobs. It is also possible to include references in a recursive way.\u003c/p\u003e","tags":[],"title":"Transport OCM Component Versions"},{"content":"Component versions can be signed to ensure integrity along a transport chain.\nSigning requires a key pair, a signature, and, optionally, an issuer, as well as an algorithm and a name for the signature.\nA component version can have multiple signatures with different names. A normalization of the component version is used for signing. See Signing Process and Normalization for more details. Currently, only signing according to the RSA PKCS #1 v1.5 signature algorithm is supported.\nTo follow the examples, one must follow the instructions from the section Create a Component Version.\nCreate a key pair using the OCM CLI:\nocm create rsakeypair acme.priv\rcreated rsa key pair acme.priv[acme.pub]\rThis creates two files. One named acme.priv for the private key and for convenience one named acme.pub for the public key.\nUse the sign componentversion command to sign a component version:\nocm sign componentversion --signature acme-sig --private-key=acme.priv ${OCM_REPO}//${COMPONENT}:${VERSION}\rapplying to version \u0026#34;github.com/acme/helloworld:1.0.0\u0026#34;[github.com/acme/helloworld:1.0.0]... resource 0: \u0026#34;name\u0026#34;=\u0026#34;mychart\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] resource 1: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] successfully signed github.com/acme/helloworld:1.0.0 (digest SHA-256:...)\rYou can also sign a common transport archive before uploading to a component repository:\nocm sign componentversion --signature acme-sig --private-key=acme.priv ${CTF_ARCHIVE}\rapplying to version \u0026#34;github.com/acme.org/helloworld:1.0.0\u0026#34;[github.com/acme.org/helloworld:1.0.0]... resource 0: \u0026#34;name\u0026#34;=\u0026#34;mychart\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] resource 1: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] successfully signed github.com/acme.org/helloworld:1.0.0 (digest SHA-256:...)\rWhat happened? Digests will be created for all described artifacts and referenced component versions. Then for the top-level component versions, the component-version digests are signed. The signature and digests are stored in the component descriptor(s):\njq . ${CTF_ARCHIVE}/artifact-index.json\r{ \u0026#34;schemaVersion\u0026#34;: 1, \u0026#34;artifacts\u0026#34;: [ { \u0026#34;repository\u0026#34;: \u0026#34;component-descriptors/github.com/acme.org/helloworld\u0026#34;, \u0026#34;tag\u0026#34;: \u0026#34;1.0.0\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:02b12782d66fc6504f0003bb11a8e2610ac8f3d616bc1a4545df17a6e9aca5c6\u0026#34; } ] }\rBeside the digests of the component descriptor layer, nothing has changed:\njq . ${CTF_ARCHIVE}/blobs/sha256.02b12782d66fc6504f0003bb11a8e2610ac8f3d616bc1a4545df17a6e9aca5c6\r{ \u0026#34;schemaVersion\u0026#34;: 2, \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.manifest.v1+json\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.ocm.software.component.config.v1+json\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:38ba9898cb8d2c5ad34274549632836b391f5acc96268f0276d6857e87b97141\u0026#34;, \u0026#34;size\u0026#34;: 201 }, \u0026#34;layers\u0026#34;: [ { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.ocm.software.component-descriptor.v2+yaml+tar\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:c9705f0045f91c2cba49ce922dd65da27e66796e3a1fdc7a6fc01058357f2cd4\u0026#34;, \u0026#34;size\u0026#34;: 3584 }, { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.manifest.v1+tar+gzip\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:125cf912d0f67b2b49e4170e684638a05a12f2fcfbdf3571e38a016273620b54\u0026#34;, \u0026#34;size\u0026#34;: 16119 } ] }\rtar xvf ${CTF_ARCHIVE}/blobs/sha256.c9705f0045f91c2cba49ce922dd65da27e66796e3a1fdc7a6fc01058357f2cd4 -O - component-descriptor.yaml\rmeta: schemaVersion: v2 component: name: github.com/acme.org/helloworld version: 1.0.0 provider: acme.org componentReferences: [] repositoryContexts: [] resources: - access: localReference: sha256:125cf912d0f67b2b49e4170e684638a05a12f2fcfbdf3571e38a016273620b54 mediaType: application/vnd.oci.image.manifest.v1+tar+gzip referenceName: github.com/acme.org/helloworld/podinfo:6.7.0 type: localBlob digest: ... name: mychart relation: local type: helmChart version: 1.0.0 - access: imageReference: gcr.io/google_containers/echoserver:1.10 type: ociArtifact digest: ... name: image relation: external type: ociArtifact version: 1.0.0 sources: [] signatures: - digest: ... name: acme-sig signature: algorithm: RSASSA-PKCS1-V1_5 mediaType: application/vnd.ocm.signature.rsa value: ...\rSigning with Certificates The public key from the last example cannot be validated. This can be changed by using a certificate instead of a pure public key. The certificate is signed by a CA. This ensures the authenticity of the described public key. Additionally, the common name of the certificate is validated against the issuer attribute of the signature stored in the component descriptor.\nThe following example creates a CA and signing certificates that are used to sign a component version.\nCreate the root CA:\nocm create rsakeypair --ca CN=certificate-authority root.priv\rcreated rsa key pair root.priv[root.cert]\rCreate the CA that is used to create signing certificates:\nocm create rsakeypair --ca CN=acme.org --ca-key root.priv --ca-cert root.cert ca.priv\rcreated rsa key pair ca.priv[ca.cert]\rCreate signing certificates from the CA:\nocm create rsakeypair CN=acme.org C=DE --ca-key ca.priv --ca-cert ca.cert --root-certs root.cert key.priv\rcreated rsa key pair key.priv[key.cert]\rYou can use additional attributes of the certificate like O, OU or C. See usage for details. The certificate can be requested by any official certificate authority instead. It requires the usage types x509.KeyUsageDigitalSignature and x509.ExtKeyUsageCodeSigning.\nFor signing the component version you need to provide the issuer, then run:\nocm sign componentversion ${CTF_ARCHIVE} --private-key key.priv --public-key key.cert --ca-cert root.cert --signature acme.org --issuer CN=acme.org\rapplying to version \u0026#34;github.com/acme.org/helloworld:1.0.0\u0026#34;[github.com/acme.org/helloworld:1.0.0]... resource 0: \u0026#34;name\u0026#34;=\u0026#34;mychart\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] resource 1: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] successfully signed github.com/acme.org/helloworld:1.0.0 (digest SHA-256:...)\rNow the issuer will be stored along the signature and will be checked when verifying with the certificate instead of the public key.\nSignature Verification You can verify a signed component version. Therefore, a public key or a certificate provided by the signer is required. If a certificate is provided, it is validated according to its certificate chain. If an official CA is used instead, you need the certificate of the used root CA.\nIf you followed the previous examples, you can verify the signature of a component version as follows:\nocm verify componentversions --signature acme-sig --public-key=acme.pub ${OCM_REPO}//${COMPONENT}:${VERSION}\rapplying to version \u0026#34;github.com/acme/helloworld:1.0.0\u0026#34;[github.com/acme/helloworld:1.0.0]... resource 0: \u0026#34;name\u0026#34;=\u0026#34;mychart\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] resource 1: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] successfully verified github.com/acme/helloworld:1.0.0 (digest SHA-256:...)\rocm verify component ${CTF_ARCHIVE} --ca-cert root.cert --issuer CN=acme.org\rapplying to version \u0026#34;github.com/acme.org/helloworld:1.0.0\u0026#34;[github.com/acme.org/helloworld:1.0.0]... resource 0: \u0026#34;name\u0026#34;=\u0026#34;mychart\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] resource 1: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;: digest SHA-256:...[ociArtifactDigest/v1] no public key found for signature \u0026#34;acme.org\u0026#34; -\u0026gt; extract key from signature successfully verified github.com/acme.org/helloworld:1.0.0 (digest SHA-256:...)\r","date":"2023-03-13","id":14,"permalink":"/docs/getting-started/getting-started-with-ocm/sign-component-versions/","summary":"\u003cp\u003eComponent versions can be signed to ensure integrity along a transport chain.\u003c/p\u003e\n\u003cp\u003eSigning requires a key pair, a signature, and, optionally, an issuer, as well as an algorithm and a\nname for the signature.\u003c/p\u003e","tags":[],"title":"Sign Component Versions"},{"content":"","date":"2020-10-06","id":15,"permalink":"/docs/controller/","summary":"","tags":[],"title":"OCM Controllers"},{"content":"This document explains the architecture of the OCM Kubernetes Controller Set (KCS). The purpose of the KCS is to enable the automated deployment of components using Kubernetes and Flux.\nThe following functions are provided as part of the KCS:\nReplication: replication of components from one OCM repository to another Signature Verification: verification of component signatures before resources are reconciled Resource Reconciliation: individual resources can be extracted from a component and reconciled to machines internal or external to the cluster Resource transformation: resource localization \u0026amp; configuration can be performed out of the box, with any other kind of modification supported via an extensible architecture Component unpacking: multiple resources can be extracted from a component and transformed with a common set of user definable operations Git synchronization: resources extracted from a component can be pushed to a git repository One of the central design decisions underpinning KCS is that resources should be composable. To this end we have introduced the concept of Snapshots; snapshots are immutable, Flux-compatible, single layer OCI images containing a single OCM resource. Snapshots are stored in an in-cluster registry and in addition to making component resources accessible for transformation, they also can be used as a caching mechanism to reduce unnecessary calls to the source OCM registry.\nControllers The KCS consists of the following controllers:\nOCM controller Replication controller Git sync controller OCM controller The ocm-controller is responsible for the core work necessary to utilise resources from an OCM component in a Kubernetes cluster. This includes resolving ComponentDescriptor metadata for a particular component version, performing authentication to OCM repositories, retrieving artifacts from OCM repositories, making individual resources from the OCM component available within the cluster, performing localization and configuration.\nSnapshots are used to pass resources between controllers and are stored in an in-cluster registry.\nThe ocm-controller consists of 5 sub-controllers:\nComponent Version Controller Resource Controller Snapshot Controller Localization Controller Configuration Controller FluxDeployer Controller Component Version Controller The Component Version controller reconciles component versions from an OCI repository by fetching the component descriptor and any referenced component descriptors. The component version controller will also verify signatures for all the public keys provided. The Component Version controller does not fetch any resources other than component descriptors. It is used by downstream controllers to access component descriptors and to attest the validity of component signatures. Downstream controllers can look up a component descriptor via the status field of the component version resource.\nsequenceDiagram User-\u003e\u003eKubernetes API: submit ComponentVersion CR Kubernetes API--\u003e\u003eComponent Version Controller: Component Version Created Event Component Version Controller-\u003e\u003eOCM Repository: Find latest component matching semver Component Version Controller-\u003e\u003eOCM Repository: Validate signatures Component Version Controller-\u003e\u003eOCM Repository: Download Component Descriptor Component Version Controller-\u003e\u003eKubernetes API: Submit Component Descriptor CR Component Version Controller-\u003e\u003eKubernetes API: Update Component Version status\rThe custom resource for the component version controller looks as follows:\napiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion metadata: name: component-x namespace: default spec: interval: 10m0s component: github.com/open-component-model/component-x version: semver: \u0026#34;\u0026gt;=v1.0.0\u0026#34; repository: url: ghcr.io/jane-doe secretRef: name: ghcr-creds verify: - name: dev-signature publicKey: secretRef: name: signing-key\rResource Controller The resource controller extracts resources from a component so that they may be used within the cluster. The resource is written to a snapshot which enables it to be cached and used by downstream processes. Resources can be selected using the name and extraIdentity fields. The resource controller requests resources using the in-cluster registry client. This means that if a resource has previously been requested then the cached version will be returned. If the resource is not found in the cache then it will be fetched from the OCM registry and written to the cache. Once the resource has been resolved and is stored in the internal registry a Snapshot CR is created\nsequenceDiagram User-\u003e\u003eKubernetes API: submit Resource CR Kubernetes API--\u003e\u003eResource Controller: Resource Created Event Resource Controller-\u003e\u003eInternal Registry: Fetch resource from cache or upstream Resource Controller-\u003e\u003eKubernetes API: Create Snapshot CR Resource Controller-\u003e\u003eKubernetes API: Update Resource status\rThe custom resource for the Resource controller is as follows:\napiVersion: delivery.ocm.software/v1alpha1 kind: Resource metadata: name: manifests spec: interval: 10m0s sourceRef: name: component-x namespace: default resourceRef: name: manifests referencePath: - name: nested-component\rSnapshot Controller The Snapshot controller reconciles Snapshot Custom Resources. Currently, the functionality here is limited to updating the status thereby validating that the snapshotted resource exists. In the future we plan to expand the scope of this controller to include verification of snapshots.\nLocalization Controller The localization controller applies localization rules to a snapshot. Because localization is deemed a common operation it is included along with the configuration controller in the ocm-controller itself. Localizations can consume an OCM resource directly or a snapshot resource from the in-cluster registry. The configuration details for the localization operation are supplied via another OCM resource which should be a yaml file in the following format:\napiVersion: config.ocm.software/v1alpha1 kind: ConfigData metadata: name: ocm-config labels: env: test localization: - resource: name: image file: deploy.yaml image: spec.template.spec.containers[0].image\rLocalization parameters are specified under the localization stanza. The Localization controller will apply the localization rules that apply to the resource specified in the source field.\nsequenceDiagram User-\u003e\u003eKubernetes API: submit Localization CR Kubernetes API--\u003e\u003eLocalization Controller: Localization Created Event Localization Controller-\u003e\u003eInternal Registry: Fetch resource from cache or upstream Localization Controller-\u003e\u003eInternal Registry: Fetch configuration resource from cache or upstream Localization Controller-\u003e\u003eLocalization Controller: Apply matching localization rules Localization Controller-\u003e\u003eInternal Registry: Push localized resource to internal registry Localization Controller-\u003e\u003eKubernetes API: Create Snapshot CR Localization Controller-\u003e\u003eKubernetes API: Update Localization status\rThe custom resource for the Localization controllers is as follows:\napiVersion: delivery.ocm.software/v1alpha1 kind: Localization metadata: name: manifests spec: interval: 1m sourceRef: kind: Resource name: manifests resourceRef: name: manifests version: latest configRef: kind: ComponentVersion name: component-x resourceRef: name: config version: latest\rConfiguration Controller The configuration controller is used to configure resources for a particular environment and similar to localization the configured resource is written to a snapshot. Because configuration is deemed a common operation it is included along with the configuration controller in the ocm-controller itself. The behaviour is as described for the localization controller but instead of retrieving configuration from the localization stanza of the ConfigData file, the controller retrieves configuration information from the configuration stanza:\napiVersion: config.ocm.software/v1alpha1 kind: ConfigData metadata: name: ocm-config labels: env: test configuration: defaults: color: red message: Hello, world! schema: type: object additionalProperties: false properties: color: type: string message: type: string rules: - value: (( message )) file: configmap.yaml path: data.PODINFO_UI_MESSAGE - value: (( color )) file: configmap.yaml path: data.PODINFO_UI_COLOR\rAnd a configuration object might something like this:\napiVersion: delivery.ocm.software/v1alpha1 kind: Configuration metadata: name: configuration spec: interval: 1m0s sourceRef: # we configure the localized data kind: Localization name: manifests configRef: kind: ComponentVersion name: component-x resourceRef: name: config version: latest valuesFrom: fluxSource: sourceRef: kind: GitRepository # get the values from a git repository provided by flux name: flux-system namespace: flux-system path: ./values.yaml subPath: component-x-configs\rFluxDeployer controller The final piece in this puzzle is the deployment object. Note this might change in the future to provide more deployment options.\nCurrent, Flux is implemented using the FluxDeployer API. This provides a connection with Flux\u0026rsquo;s ability to apply manifest files taken from an OCI repository. Here, the OCI repository is the in-cluster registry and the path to it will be provided by the snapshot created by the last link in the chain.\nConsider the following example using the localized and configured resource from above:\napiVersion: delivery.ocm.software/v1alpha1 kind: FluxDeployer metadata: name: fluxdeployer-podinfo-pipeline-frontend spec: interval: 1m0s sourceRef: kind: Configuration name: configuration kustomizationTemplate: interval: 5s path: ./ prune: true targetNamespace: ocm-system\rThis will deploy any manifest files at path ./ in the result of the above configuration.\nReplication controller The Replication Controller handles the replication of components between OCI repositories. It consists of a single reconciler which manages subscriptions to a source OCI repository. A semver constraint is used to specify a target component version. Component versions satisfying the semver constraint will be copied to the destination OCI repository. The replication controller will verify signatures before performing replication.\napiVersion: delivery.ocm.software/v1alpha1 kind: ComponentSubscription metadata: name: componentsubscription-sample namespace: ocm-system spec: source: secretRef: name: source-access-secret url: oci://source destination: secretRef: name: destination-access-secret url: oci://destination component: \u0026#34;https://github.com/open-component-model/component-x\u0026#34; interval: 10m0s semver: \u0026#34;~v0.1.0\u0026#34; verify: - signature: name: signature-name key: name: verify-key-name status: latestVersion: \u0026#34;v0.1.1\u0026#34; replicatedVersion: \u0026#34;v0.1.0\u0026#34;\rsequenceDiagram User-\u003e\u003eKubernetes API: submit Component Subscription CR Kubernetes API--\u003e\u003eReplication Controller: Component Subscription Created Event Replication Controller-\u003e\u003eReplication Controller: Determine new component is available in source repository based on semver Replication Controller-\u003e\u003eSource OCM Repository: Verify signatures Source OCM Repository-\u003e\u003eDestination OCM Repository: Transfer component by value Replication Controller-\u003e\u003eKubernetes API: Update Component Subscription status\rIn-cluster Docker Registry The ocm-controller manages a deployment of the docker registry. This provides a caching mechanism for resources and storage for snapshots whilst also enabling integration with Flux. Usage of the in-cluster registry is transparent to the clients and is handled via the ocm client library provided by the controller sdk.\n","date":"2023-10-20","id":16,"permalink":"/docs/controller/architecture/","summary":"\u003cp\u003eThis document explains the architecture of the OCM Kubernetes Controller Set (KCS). The purpose of the KCS is to enable the automated deployment of components using Kubernetes and Flux.\u003c/p\u003e","tags":[],"title":"Architecture"},{"content":"ocm-controller The ocm-controller can be installed using the OCM CLI:\nocm controller install\rThis command will install the ocm-controller in the kubernetes cluster specified by the current KUBECONFIG context.\nThe following flags are available:\nFlags: -u, --base-url string the base url to the ocm-controller\u0026#39;s release page (default \u0026#34;https://github.com/open-component-model/ocm-controller/releases\u0026#34;) -c, --controller-name string name of the controller that\u0026#39;s used for status check (default \u0026#34;ocm-controller\u0026#34;) -d, --dry-run if enabled, prints the downloaded manifest file -h, --help help for install -n, --namespace string the namespace into which the controller is installed (default \u0026#34;ocm-system\u0026#34;) -a, --release-api-url string the base url to the ocm-controller\u0026#39;s API release page (default \u0026#34;https://api.github.com/repos/open-component-model/ocm-controller/releases\u0026#34;) -t, --timeout duration maximum time to wait for deployment to be ready (default 1m0s) -v, --version string the version of the controller to install (default \u0026#34;latest\u0026#34;) Description: Install either a specific or latest version of the ocm-controller.\rreplication-controller The replication-controller can be installed using kubectl:\nVERSION=$(curl -sL https://api.github.com/repos/open-component-model/replication-controller/releases/latest | jq -r \u0026#39;.name\u0026#39;) kubectl apply -f https://github.com/open-component-model/replication-controller/releases/download/$VERSION/install.yaml\r","date":"2023-06-27","id":17,"permalink":"/docs/controller/installation/","summary":"\u003ch2 id=\"ocm-controller\"\u003eocm-controller\u003c/h2\u003e\n\u003cp\u003eThe \u003ccode\u003eocm-controller\u003c/code\u003e can be installed using the \u003ca href=\"/docs/getting-started/installing-the-ocm-cli\"\u003eOCM CLI\u003c/a\u003e:\u003c/p\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame is-terminal not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" class=\"chroma\"\u003e\u003ccode class=\"language-bash\" data-lang=\"bash\"\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003eocm controller install\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003cp\u003eThis command will install the \u003ccode\u003eocm-controller\u003c/code\u003e in the kubernetes cluster specified by the current \u003ccode\u003eKUBECONFIG\u003c/code\u003e context.\u003c/p\u003e","tags":[],"title":"Installation"},{"content":"","date":"2023-01-17","id":18,"permalink":"/docs/component-descriptors/","summary":"","tags":[],"title":"Component Descriptors"},{"content":"","date":"2022-01-25","id":19,"permalink":"/docs/controller/controller-reference/","summary":"","tags":[],"title":"Kubernetes Controllers"},{"content":"","date":"2022-01-25","id":20,"permalink":"/docs/controller/controller-reference/api-reference/","summary":"","tags":[],"title":"API Reference"},{"content":"Packages:\ndelivery.ocm.software/v1alpha1 delivery.ocm.software/v1alpha1 Package v1alpha1 contains API Schema definitions for the delivery v1alpha1 API group\nResource Types: ComponentVersion ComponentVersion is the Schema for the ComponentVersions API.\nField Description metadata\nKubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec\nComponentVersionSpec component\nstring Component specifies the name of the ComponentVersion.\nversion\nVersion Version specifies the version information for the ComponentVersion.\nrepository\nRepository Repository provides details about the OCI repository from which the component descriptor can be retrieved.\ninterval\nKubernetes meta/v1.Duration Interval specifies the interval at which the Repository will be checked for updates.\nverify\n[]Signature (Optional) Verify specifies a list signatures that should be validated before the ComponentVersion is marked Verified.\nreferences\nReferencesConfig (Optional) References specifies configuration for the handling of nested component references.\nsuspend\nbool (Optional) Suspend can be used to temporarily pause the reconciliation of the ComponentVersion resource.\nserviceAccountName\nstring (Optional) ServiceAccountName can be used to configure access to both destination and source repositories. If service account is defined, it\u0026rsquo;s usually redundant to define access to either source or destination, but it is still allowed to do so. https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account\nstatus\nComponentVersionStatus ComponentVersionSpec (Appears on: ComponentVersion) ComponentVersionSpec specifies the configuration required to retrieve a component descriptor for a component version.\nField Description component\nstring Component specifies the name of the ComponentVersion.\nversion\nVersion Version specifies the version information for the ComponentVersion.\nrepository\nRepository Repository provides details about the OCI repository from which the component descriptor can be retrieved.\ninterval\nKubernetes meta/v1.Duration Interval specifies the interval at which the Repository will be checked for updates.\nverify\n[]Signature (Optional) Verify specifies a list signatures that should be validated before the ComponentVersion is marked Verified.\nreferences\nReferencesConfig (Optional) References specifies configuration for the handling of nested component references.\nsuspend\nbool (Optional) Suspend can be used to temporarily pause the reconciliation of the ComponentVersion resource.\nserviceAccountName\nstring (Optional) ServiceAccountName can be used to configure access to both destination and source repositories. If service account is defined, it\u0026rsquo;s usually redundant to define access to either source or destination, but it is still allowed to do so. https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account\nComponentVersionStatus (Appears on: ComponentVersion) ComponentVersionStatus defines the observed state of ComponentVersion.\nField Description observedGeneration\nint64 (Optional) ObservedGeneration is the last reconciled generation.\nconditions\n[]Kubernetes meta/v1.Condition (Optional) Conditions holds the conditions for the ComponentVersion.\ncomponentDescriptor\nReference (Optional) ComponentDescriptor holds the ComponentDescriptor information for the ComponentVersion.\nreconciledVersion\nstring (Optional) ReconciledVersion is a string containing the version of the latest reconciled ComponentVersion.\nverified\nbool (Optional) Verified is a boolean indicating whether all the specified signatures have been verified and are valid.\nConfigMapSource (Appears on: ValuesSource) Field Description sourceRef\ngithub.com/fluxcd/pkg/apis/meta.LocalObjectReference key\nstring subPath\nstring (Optional) Configuration Configuration is the Schema for the configurations API.\nField Description metadata\nKubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec\nMutationSpec interval\nKubernetes meta/v1.Duration sourceRef\nObjectReference configRef\nObjectReference (Optional) values\nk8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1.JSON (Optional) valuesFrom\nValuesSource (Optional) patchStrategicMerge\nPatchStrategicMerge (Optional) suspend\nbool (Optional) Suspend stops all operations on this object.\nstatus\nMutationStatus DeliverySpec DeliverySpec holds a set of targets onto which the pipeline output will be deployed.\nField Description targets\n[]WasmStep ElementMeta (Appears on: ResourceReference) Field Description name\nstring version\nstring extraIdentity\ngithub.com/open-component-model/ocm/pkg/contexts/ocm/compdesc/meta/v1.Identity labels\ngithub.com/open-component-model/ocm/pkg/contexts/ocm/compdesc/meta/v1.Labels FluxDeployer FluxDeployer is the Schema for the FluxDeployers API.\nField Description metadata\nKubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec\nFluxDeployerSpec sourceRef\nObjectReference interval\nKubernetes meta/v1.Duration The interval at which to reconcile the Kustomization and Helm Releases.\nkustomizationTemplate\ngithub.com/fluxcd/kustomize-controller/api/v1beta2.KustomizationSpec (Optional) helmReleaseTemplate\ngithub.com/fluxcd/helm-controller/api/v2beta1.HelmReleaseSpec (Optional) status\nFluxDeployerStatus FluxDeployerSpec (Appears on: FluxDeployer) FluxDeployerSpec defines the desired state of FluxDeployer.\nField Description sourceRef\nObjectReference interval\nKubernetes meta/v1.Duration The interval at which to reconcile the Kustomization and Helm Releases.\nkustomizationTemplate\ngithub.com/fluxcd/kustomize-controller/api/v1beta2.KustomizationSpec (Optional) helmReleaseTemplate\ngithub.com/fluxcd/helm-controller/api/v2beta1.HelmReleaseSpec (Optional) FluxDeployerStatus (Appears on: FluxDeployer) FluxDeployerStatus defines the observed state of FluxDeployer.\nField Description observedGeneration\nint64 (Optional) ObservedGeneration is the last reconciled generation.\nconditions\n[]Kubernetes meta/v1.Condition (Optional) kustomization\nstring (Optional) ociRepository\nstring (Optional) FluxValuesSource (Appears on: ValuesSource) Field Description sourceRef\ngithub.com/fluxcd/pkg/apis/meta.NamespacedObjectKindReference path\nstring subPath\nstring (Optional) Localization Localization is the Schema for the localizations API.\nField Description metadata\nKubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec\nMutationSpec interval\nKubernetes meta/v1.Duration sourceRef\nObjectReference configRef\nObjectReference (Optional) values\nk8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1.JSON (Optional) valuesFrom\nValuesSource (Optional) patchStrategicMerge\nPatchStrategicMerge (Optional) suspend\nbool (Optional) Suspend stops all operations on this object.\nstatus\nMutationStatus MutationObject MutationObject defines any object which produces a snapshot\nMutationSpec (Appears on: Configuration, Localization) MutationSpec defines a common spec for Localization and Configuration of OCM resources.\nField Description interval\nKubernetes meta/v1.Duration sourceRef\nObjectReference configRef\nObjectReference (Optional) values\nk8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1.JSON (Optional) valuesFrom\nValuesSource (Optional) patchStrategicMerge\nPatchStrategicMerge (Optional) suspend\nbool (Optional) Suspend stops all operations on this object.\nMutationStatus (Appears on: Configuration, Localization) MutationStatus defines a common status for Localizations and Configurations.\nField Description observedGeneration\nint64 (Optional) ObservedGeneration is the last reconciled generation.\nconditions\n[]Kubernetes meta/v1.Condition (Optional) latestSnapshotDigest\nstring (Optional) latestSourceVersion\nstring (Optional) latestConfigVersion\nstring (Optional) latestPatchSourceVersio\nstring (Optional) snapshotName\nstring (Optional) ObjectReference (Appears on: FluxDeployerSpec, MutationSpec, ResourcePipelineSpec, ResourceSpec) ObjectReference defines a resource which may be accessed via a snapshot or component version\nField Description NamespacedObjectKindReference\ngithub.com/fluxcd/pkg/apis/meta.NamespacedObjectKindReference (Members of NamespacedObjectKindReference are embedded into this type.) resourceRef\nResourceReference (Optional) PatchStrategicMerge (Appears on: MutationSpec) PatchStrategicMerge contains the source and target details required to perform a strategic merge.\nField Description source\nPatchStrategicMergeSource target\nPatchStrategicMergeTarget PatchStrategicMergeSource (Appears on: PatchStrategicMerge) PatchStrategicMergeSource contains the details required to retrieve the source from a Flux source.\nField Description sourceRef\ngithub.com/fluxcd/pkg/apis/meta.NamespacedObjectKindReference path\nstring PatchStrategicMergeTarget (Appears on: PatchStrategicMerge) PatchStrategicMergeTarget provides details about the merge target.\nField Description path\nstring PipelineSpec (Appears on: ResourcePipelineSpec) PipelineSpec holds the steps that constitute the pipeline.\nField Description steps\n[]WasmStep PublicKey (Appears on: Signature) PublicKey specifies access to a public key for verification.\nField Description secretRef\nKubernetes core/v1.LocalObjectReference (Optional) SecretRef is a reference to a Secret that contains a public key.\nvalue\nstring (Optional) Value defines a PEM/base64 encoded public key value.\nReference (Appears on: ComponentVersionStatus, Reference) Reference contains all referred components and their versions.\nField Description name\nstring Name specifies the name of the referenced component.\nversion\nstring Version specifies the version of the referenced component.\nreferences\n[]Reference References is a list of component references.\nextraIdentity\nmap[string]string (Optional) ExtraIdentity specifies additional identity attributes of the referenced component.\ncomponentDescriptorRef\ngithub.com/fluxcd/pkg/apis/meta.NamespacedObjectReference (Optional) ComponentDescriptorRef specifies the reference for the Kubernetes object representing the ComponentDescriptor.\nReferencesConfig (Appears on: ComponentVersionSpec) ReferencesConfig specifies how component references should be handled when reconciling the root component.\nField Description expand\nbool (Optional) Expand specifies if a Kubernetes API resource of kind ComponentDescriptor should be generated for each component reference that is present in the root ComponentVersion.\nRepository (Appears on: ComponentVersionSpec) Repository specifies access details for the repository that contains OCM ComponentVersions.\nField Description url\nstring URL specifies the URL of the OCI registry in which the ComponentVersion is stored. MUST NOT CONTAIN THE SCHEME.\nsecretRef\nKubernetes core/v1.LocalObjectReference (Optional) SecretRef specifies the credentials used to access the OCI registry.\nResource Resource is the Schema for the resources API.\nField Description metadata\nKubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec\nResourceSpec interval\nKubernetes meta/v1.Duration Interval specifies the interval at which the Repository will be checked for updates.\nsourceRef\nObjectReference SourceRef specifies the source object from which the resource should be retrieved.\nsuspend\nbool (Optional) Suspend can be used to temporarily pause the reconciliation of the Resource.\nstatus\nResourceStatus ResourcePipeline ResourcePipeline is the Schema for the resourcepipelines API.\nField Description metadata\nKubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec\nResourcePipelineSpec interval\nKubernetes meta/v1.Duration suspend\nbool (Optional) serviceAccountName\nstring (Optional) sourceRef\nObjectReference parameters\nk8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1.JSON (Optional) pipelineSpec\nPipelineSpec (Optional) status\nResourcePipelineStatus ResourcePipelineSource ResourcePipelineSource defines the component version and resource which will be processed by the pipeline.\nField Description name\nstring namespace\nstring (Optional) resource\nstring ResourcePipelineSpec (Appears on: ResourcePipeline) ResourcePipelineSpec defines the desired state of ResourcePipeline.\nField Description interval\nKubernetes meta/v1.Duration suspend\nbool (Optional) serviceAccountName\nstring (Optional) sourceRef\nObjectReference parameters\nk8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1.JSON (Optional) pipelineSpec\nPipelineSpec (Optional) ResourcePipelineStatus (Appears on: ResourcePipeline) ResourcePipelineStatus defines the observed state of ResourcePipeline.\nField Description observedGeneration\nint64 (Optional) ObservedGeneration is the last reconciled generation.\nconditions\n[]Kubernetes meta/v1.Condition (Optional) latestSnapshotDigest\nstring (Optional) snapshotName\nstring (Optional) ResourceReference (Appears on: ObjectReference) Field Description ElementMeta\nElementMeta (Members of ElementMeta are embedded into this type.) referencePath\n[]github.com/open-component-model/ocm/pkg/contexts/ocm/compdesc/meta/v1.Identity (Optional) ResourceSpec (Appears on: Resource) ResourceSpec defines the desired state of Resource.\nField Description interval\nKubernetes meta/v1.Duration Interval specifies the interval at which the Repository will be checked for updates.\nsourceRef\nObjectReference SourceRef specifies the source object from which the resource should be retrieved.\nsuspend\nbool (Optional) Suspend can be used to temporarily pause the reconciliation of the Resource.\nResourceStatus (Appears on: Resource) ResourceStatus defines the observed state of Resource.\nField Description observedGeneration\nint64 (Optional) ObservedGeneration is the last reconciled generation.\nconditions\n[]Kubernetes meta/v1.Condition (Optional) Conditions holds the conditions for the ComponentVersion.\nlastAppliedResourceVersion\nstring (Optional) LastAppliedResourceVersion holds the version of the resource that was last applied (if applicable).\nlastAppliedComponentVersion\nstring (Optional) LastAppliedComponentVersion holds the version of the last applied ComponentVersion for the ComponentVersion which contains this Resource.\nsnapshotName\nstring (Optional) SnapshotName specifies the name of the Snapshot that has been created to store the resource within the cluster and make it available for consumption by Flux controllers.\nlatestSnapshotDigest\nstring (Optional) LatestSnapshotDigest is a string representation of the digest for the most recent Resource snapshot.\nSignature (Appears on: ComponentVersionSpec) Signature defines the details of a signature to use for verification.\nField Description name\nstring Name specifies the name of the signature. An OCM component may have multiple signatures.\npublicKey\nPublicKey PublicKey provides a reference to a Kubernetes Secret of contain a blob of a public key that which will be used to validate the named signature.\nValuesSource (Appears on: MutationSpec) ValuesSource provides access to values from an external Source such as a ConfigMap or GitRepository. An optional subpath defines the path within the source from which the values should be resolved.\nField Description fluxSource\nFluxValuesSource (Optional) configMapSource\nConfigMapSource (Optional) Version (Appears on: ComponentVersionSpec) Version specifies version information that can be used to resolve a Component Version.\nField Description semver\nstring (Optional) Semver specifies a semantic version constraint for the Component Version.\nWasmStep (Appears on: DeliverySpec, PipelineSpec) WasmStep defines the name version and location of a wasm module that is stored// in an ocm component. The format of the module name must be :@. Optionally a registry address can be specified.\nField Description name\nstring module\nstring registry\nstring (Optional) values\nk8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1.JSON (Optional) timeout\nKubernetes meta/v1.Duration (Optional) This page was automatically generated with gen-crd-api-reference-docs\n","date":"2023-06-27","id":21,"permalink":"/docs/controller/controller-reference/api-reference/ocm-controller-api-v1/","summary":"\u003cp\u003ePackages:\u003c/p\u003e\n\u003cul class=\"simple\"\u003e\n\u003cli\u003e\n\u003ca href=\"#delivery.ocm.software%2fv1alpha1\"\u003edelivery.ocm.software/v1alpha1\u003c/a\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"delivery.ocm.software/v1alpha1\"\u003edelivery.ocm.software/v1alpha1\u003c/h2\u003e\n\u003cp\u003ePackage v1alpha1 contains API Schema definitions for the delivery v1alpha1 API group\u003c/p\u003e\nResource Types:\n\u003cul class=\"simple\"\u003e\u003c/ul\u003e\n\u003ch3 id=\"delivery.ocm.software/v1alpha1.ComponentVersion\"\u003eComponentVersion\n\u003c/h3\u003e\n\u003cp\u003eComponentVersion is the Schema for the ComponentVersions API.\u003c/p\u003e","tags":[],"title":"OCM Controller API v1"},{"content":"Packages:\ndelivery.ocm.software/v1alpha1 delivery.ocm.software/v1alpha1 Package v1alpha1 contains API Schema definitions for the delivery v1alpha1 API group\nResource Types: ComponentSubscription ComponentSubscription is the Schema for the componentsubscriptions API\nField Description metadata\nKubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec\nComponentSubscriptionSpec component\nstring Component specifies the name of the Component that should be replicated.\nsemver\nstring (Optional) Semver specifies an optional semver constraint that is used to evaluate the component versions that should be replicated.\nsource\nOCMRepository Source holds the OCM Repository details for the replication source.\ndestination\nOCMRepository (Optional) Destination holds the destination or target OCM Repository details. The ComponentVersion will be transfered into this repository.\ninterval\nKubernetes meta/v1.Duration Interval is the reconciliation interval, i.e. at what interval shall a reconciliation happen. This is used to requeue objects for reconciliation in case of success as well as already reconciling objects.\nserviceAccountName\nstring (Optional) ServiceAccountName can be used to configure access to both destination and source repositories. If service account is defined, it\u0026rsquo;s usually redundant to define access to either source or destination, but it is still allowed to do so. https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account\nverify\n[]Signature (Optional) Verify specifies a list signatures that must be verified before a ComponentVersion is replicated.\nstatus\nComponentSubscriptionStatus ComponentSubscriptionSpec (Appears on: ComponentSubscription) ComponentSubscriptionSpec defines the desired state of ComponentSubscription. It specifies the parameters that the replication controller will use to replicate a desired Component from a source OCM repository to a destination OCM repository.\nField Description component\nstring Component specifies the name of the Component that should be replicated.\nsemver\nstring (Optional) Semver specifies an optional semver constraint that is used to evaluate the component versions that should be replicated.\nsource\nOCMRepository Source holds the OCM Repository details for the replication source.\ndestination\nOCMRepository (Optional) Destination holds the destination or target OCM Repository details. The ComponentVersion will be transfered into this repository.\ninterval\nKubernetes meta/v1.Duration Interval is the reconciliation interval, i.e. at what interval shall a reconciliation happen. This is used to requeue objects for reconciliation in case of success as well as already reconciling objects.\nserviceAccountName\nstring (Optional) ServiceAccountName can be used to configure access to both destination and source repositories. If service account is defined, it\u0026rsquo;s usually redundant to define access to either source or destination, but it is still allowed to do so. https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account\nverify\n[]Signature (Optional) Verify specifies a list signatures that should be validated before the ComponentVersion is marked Verified.\nComponentSubscriptionStatus (Appears on: ComponentSubscription) ComponentSubscriptionStatus defines the observed state of ComponentSubscription\nField Description lastAttemptedVersion\nstring (Optional) LastAttemptedVersion defines the latest version encountered while checking component versions. This might be different from last applied version which should be the latest applied/replicated version. The difference might be caused because of semver constraint or failures during replication.\nobservedGeneration\nint64 (Optional) ObservedGeneration is the last reconciled generation.\nlastAppliedVersion\nstring (Optional) LastAppliedVersion defines the final version that has been applied to the destination component version.\nreplicatedRepositoryURL\nstring (Optional) ReplicatedRepositoryURL defines the final location of the reconciled Component.\nconditions\n[]Kubernetes meta/v1.Condition (Optional) OCMRepository (Appears on: ComponentSubscriptionSpec) OCMRepository specifies access details for an OCI based OCM Repository.\nField Description url\nstring URL specifies the URL of the OCI registry.\nsecretRef\nKubernetes core/v1.LocalObjectReference (Optional) SecretRef specifies the credentials used to access the OCI registry.\nSecretRef (Appears on: Signature) SecretRef clearly denotes that the requested option is a Secret.\nField Description secretRef\ngithub.com/fluxcd/pkg/apis/meta.LocalObjectReference Signature (Appears on: ComponentSubscriptionSpec) Signature defines the details of a signature to use for verification.\nField Description name\nstring Name specifies the name of the signature. An OCM component may have multiple signatures.\npublicKey\nSecretRef PublicKey provides a reference to a Kubernetes Secret that contains a public key which will be used to validate the named signature.\nThis page was automatically generated with gen-crd-api-reference-docs\n","date":"2023-07-10","id":22,"permalink":"/docs/controller/controller-reference/api-reference/replication-controller-api-v1/","summary":"\u003cp\u003ePackages:\u003c/p\u003e\n\u003cul class=\"simple\"\u003e\n\u003cli\u003e\n\u003ca href=\"#delivery.ocm.software%2fv1alpha1\"\u003edelivery.ocm.software/v1alpha1\u003c/a\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"delivery.ocm.software/v1alpha1\"\u003edelivery.ocm.software/v1alpha1\u003c/h2\u003e\n\u003cp\u003ePackage v1alpha1 contains API Schema definitions for the delivery v1alpha1 API group\u003c/p\u003e\nResource Types:\n\u003cul class=\"simple\"\u003e\u003c/ul\u003e\n\u003ch3 id=\"delivery.ocm.software/v1alpha1.ComponentSubscription\"\u003eComponentSubscription\n\u003c/h3\u003e\n\u003cp\u003eComponentSubscription is the Schema for the componentsubscriptions API\u003c/p\u003e","tags":[],"title":"Replication Controller API v1"},{"content":"","date":"2022-01-25","id":23,"permalink":"/docs/controller/controller-reference/ocm-controller/","summary":"","tags":[],"title":"OCM Controller"},{"content":"The ComponentVersion API produces component descriptors for a specific component version.\nExample The following is an example of a ComponentVersion:\napiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion metadata: name: podinfo namespace: default spec: interval: 10m0s component: phoban.io/podinfo repository: url: ghcr.io/phoban01 version: semver: \u0026#34;\u0026gt;=6.3.x\u0026#34;\rIn the above example:\nA ComponentVersion named podinfo is created, indicated by the .metadata.name field. The ocm-controller checks the OCM repository every 10m0s, indicated by the .spec.interval field. It retrieves the version matching the semver constraint specified by .spec.version.semver field. The resolved component descriptor and version are written to the .status.componentDescriptor and .status.reconciledVersion fields. Whenever a new version is available that satisfies .spec.version.semver and is greater than .status.reconciledVersion then the ocm-controller will fetch the new component version. You can run this example by saving the manifest into componentversion.yaml.\nApply the resource to the cluster: kubectl apply -f componentversion.yaml\rRun kubectl get componentversion to see the ComponentVersion NAME READY VERSION AGE STATUS podinfo True 6.3.6 8s Applied version: 6.3.6\rRun kubectl describe componentversion podinfo to see the ComponentVersion Status: Name: podinfo Namespace: default Labels: \u0026lt;none\u0026gt; Annotations: \u0026lt;none\u0026gt; API Version: delivery.ocm.software/v1alpha1 Kind: ComponentVersion Metadata: Creation Timestamp: 2023-06-28T15:41:57Z Generation: 1 Resource Version: 235307145 UID: 318963a5-3b4f-4098-b324-348a57e532ff Spec: Component: phoban.io/podinfo Interval: 10m0s Repository: URL: ghcr.io/phoban01 Version: Semver: \u0026gt;=6.3.x Status: Component Descriptor: Component Descriptor Ref: Name: phoban.io-podinfo-6.3.6-10372358058082697739 Namespace: default Name: phoban.io/podinfo Version: 6.3.6 Conditions: Last Transition Time: 2023-06-28T15:42:01Z Message: Applied version: 6.3.6 Observed Generation: 1 Reason: Succeeded Status: True Type: Ready Observed Generation: 1 Reconciled Version: 6.3.6 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Progressing 46s ocm-controller Version check succeeded, found latest version: 6.3.6 Normal Succeeded 43s ocm-controller Reconciliation finished, next run in 10m0s\rView the ComponentDescriptor for this ComponentVersion by running kubectl get componentdescriptor -oyaml \\ $(kubectl get cv podinfo -ojsonpath=\u0026#34;{.status.componentDescriptor.componentDescriptorRef.name}\u0026#34;)\rapiVersion: delivery.ocm.software/v1alpha1 kind: ComponentDescriptor metadata: creationTimestamp: \u0026#34;2023-06-28T15:42:01Z\u0026#34; generation: 1 name: phoban.io-podinfo-6.3.6-10372358058082697739 namespace: default ownerReferences: - apiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion name: podinfo uid: 318963a5-3b4f-4098-b324-348a57e532ff resourceVersion: \u0026#34;235307140\u0026#34; uid: 4efd4eb2-cb2d-4e0d-ae3c-f74cc59e3fa0 spec: resources: - access: globalAccess: digest: sha256:265a95fcccabded6d2040e1438b8b1c5bef1441adb60039adf54640c00b84003 mediaType: application/x-tar ref: ghcr.io/phoban01/component-descriptors/phoban.io/podinfo size: 3072 type: ociBlob localReference: sha256:265a95fcccabded6d2040e1438b8b1c5bef1441adb60039adf54640c00b84003 mediaType: application/x-tar type: localBlob name: deployment relation: local type: Directory version: 6.3.6 - access: globalAccess: digest: sha256:b3fe60d3213e6c11006b6f62d9f1bcc6a6e12da1b3aa5ee9f27943710262d351 mediaType: application/octet-stream ref: ghcr.io/phoban01/component-descriptors/phoban.io/podinfo size: 515 type: ociBlob localReference: sha256:b3fe60d3213e6c11006b6f62d9f1bcc6a6e12da1b3aa5ee9f27943710262d351 mediaType: application/octet-stream type: localBlob name: config relation: local type: PlainText version: 6.3.6 - access: imageReference: ghcr.io/stefanprodan/podinfo:6.3.5 type: ociArtifact name: image relation: external type: ociImage version: 6.3.5 version: 6.3.6\rWriting a ComponentVersion spec As with all other Kubernetes config, an ComponentVersion needs apiVersion, kind, and metadata fields. The name of an ComponentVersion object must be a valid DNS subdomain name.\nAn ComponentVersion also needs a .spec section.\nComponent .spec.component is a required field that specifies the name of the component.\nVersion .spec.version.semver specifies a semantic version constraint that is used to determine the specific component version or range of versions that will be reconciled.\nRepository .spec.repository provides the necessary configuration for the ocm-controller to access the OCI repository where the component version is stored.\nURL .spec.repository.url is a required field that denoting the registry in which the OCM component is stored.\nSecret Reference .spec.repository.secretRef.name is an optional field to specify a name reference to a Secret in the same namespace as the ComponentVersion, containing authentication credentials for the OCI repository.\nThis secret is expected to contain the keys username and password. You can create such a secret using kubectl:\nkubectl create secret generic registry-credentials --from-literal=username=$GITHUB_USER --from-literal=password=$GITHUB_TOKEN\rService Account Name .spec.serviceAccountName is an optional field to specify a name reference to a Service Account in the same namespace as the ComponentVersion. The controller will fetch the image pull secrets attached to the service account and use them for authentication.\nPublic OCI Repository access\nthat for a publicly accessible OCI repository, you don’t need to provide a secretRef nor serviceAccountName.\nInterval .spec.interval is a required field that specifies the interval at which the ComponentVersion must be reconciled.\nAfter successfully reconciling the object, the ocm-controller requeues it for inspection after the specified interval. The value must be in a Go recognized duration string format, e.g. 10m0s to reconcile the object every 10 minutes.\nIf the .metadata.generation of a resource changes (due to e.g. a change to the spec), this is handled instantly outside the interval window.\nVerify .spec.verify is an optional list of signatures that should be validated before the component version is marked as verified. A ComponentVersion that is not verified will not be consumed by downstream ocm-controller resources. Each signature item consists of a name and a publicKey.\nName .spec.verify.[].name is a required field that specifies the name of the signature that should be verified.\nPublic Key .spec.verify.[].publicKey is a required field that specifies a reference to a secret containing the public key that can be used to verify the signature. The key of the public key in the secret must match the name of the signature.\nFor example, the following ComponentVersion verifies two signatures:\napiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion metadata: name: podinfo namespace: default spec: interval: 10m0s component: phoban.io/podinfo repository: url: ghcr.io/phoban01 version: semver: \u0026#34;\u0026gt;=6.3.x\u0026#34; verify: - name: operations publicKey: secretRef: name: signing-keys - name: security publicKey: secretRef: name: signing-keys\rThe accompanying secret should be in the following format:\napiVersion: v1 kind: Secret metadata: name: signing-keys type: Opaque data: operations: \u0026lt;BASE64\u0026gt; security: \u0026lt;BASE64\u0026gt;\rSuspend .spec.suspend is an optional field to suspend the reconciliation of a ComponentVersion. When set to true, the controller will stop reconciling the ComponentVersion. When the field is set to false or removed, it will resume.\nDebugging ComponentVersions There are several ways to gather information about a ComponentVersion for debugging purposes.\nDescribe the ComponentVersion Describing an ComponentVersion using kubectl describe componentversion \u0026lt;repository-name\u0026gt; displays the latest recorded information for the resource in the Status and Events sections:\n... Status: ... Conditions: Last Transition Time: 2023-06-29T11:54:23Z Message: reconcilation in progress for component: phoban.io/podinfo Observed Generation: 1 Reason: ProgressingWithRetry Status: True Type: Reconciling Last Transition Time: 2023-06-29T11:54:23Z Message: failed to verify phoban.io/podinfo with constraint \u0026gt;=6.3.x Observed Generation: 1 Reason: ComponentVerificationFailed Status: False Type: Ready Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Progressing 18s ocm-controller Version check succeeded, found latest version: 6.3.6 Warning ComponentVerificationFailed 16s ocm-controller failed to get public key for verification: public key not found, retrying in 10m0s Warning ComponentVerificationFailed 16s ocm-controller Reconciliation did not succeed, retrying in 10m0s\rTrace emitted Events To view events for specific ComponentVersion(s), kubectl events can be used in combination with --for to list the Events for specific objects. For example, running:\nkubectl events --for ComponentVersion/\u0026lt;name\u0026gt;\routputs:\nLAST SEEN TYPE REASON OBJECT MESSAGE 38s Warning ComponentVerificationFailed ComponentVersion/podinfo failed to get public key for verification: public key not found, retrying in 10m0s 38s Warning ComponentVerificationFailed ComponentVersion/podinfo Reconciliation did not succeed, retrying in 10m0s\rBesides being reported in Events, the reconciliation errors are also logged by the controller. You can use a tool such as stern in tandem with grep to filter and refine the output of controller logs:\nstern ocm-controller -n ocm-system | grep ComponentVersion\rwill output the following log stream:\nocm-controller-bcf4cbbb8-crd4d manager 2023-06-29T11:54:21Z INFO Version check succeeded, found latest version: 6.3.6 {\u0026#34;name\u0026#34;: \u0026#34;podinfo\u0026#34;, \u0026#34;namespace\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;reconciler kind\u0026#34;: \u0026#34;ComponentVersion\u0026#34;, \u0026#34;reason\u0026#34;: \u0026#34;Progressing\u0026#34;, \u0026#34;annotations\u0026#34;: {}} ocm-controller-bcf4cbbb8-crd4d manager 2023-06-29T11:54:23Z ERROR failed to get public key for verification: public key not found, retrying in 10m0s {\u0026#34;name\u0026#34;: \u0026#34;podinfo\u0026#34;, \u0026#34;namespace\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;reconciler kind\u0026#34;: \u0026#34;ComponentVersion\u0026#34;, \u0026#34;annotations\u0026#34;: {}, \u0026#34;error\u0026#34;: \u0026#34;ComponentVerificationFailed\u0026#34;} ocm-controller-bcf4cbbb8-crd4d manager github.com/open-component-model/ocm-controller/controllers.(*ComponentVersionReconciler).Reconcile ocm-controller-bcf4cbbb8-crd4d manager 2023-06-29T11:54:23Z ERROR Reconciliation did not succeed, retrying in 10m0s {\u0026#34;name\u0026#34;: \u0026#34;podinfo\u0026#34;, \u0026#34;namespace\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;reconciler kind\u0026#34;: \u0026#34;ComponentVersion\u0026#34;, \u0026#34;annotations\u0026#34;: {}, \u0026#34;error\u0026#34;: \u0026#34;ComponentVerificationFailed\u0026#34;} ocm-controller-bcf4cbbb8-crd4d manager github.com/open-component-model/ocm-controller/controllers.(*ComponentVersionReconciler).Reconcile.func1 ocm-controller-bcf4cbbb8-crd4d manager github.com/open-component-model/ocm-controller/controllers.(*ComponentVersionReconciler).Reconcile\rComponentVersion Status Observed Generation The ocm-controller reports an observed generation in the ComponentVersion’s .status.observedGeneration. The observed generation is the latest .metadata.generation which resulted in either a ready state, or stalled due to error it can not recover from without human intervention.\nConditions ComponentVersion has various states during its lifecycle, reflected as Kubernetes Conditions. It can be reconciling while fetching the remote ComponentVersion or verifying signatures, it can be ready, or it can fail during reconciliation.\nComponent Descriptor The status contains a reference to the component descriptor for the reconciled component version.\nThe following fields make up the reference:\nname: name of the reconciled component. version: version of the reconciled component. extraIdentity: additional identity attributes of the reconciled component. references: a list of component references. componentDescriptorRef: a reference to the ComponentDescriptor Kubernetes representation. Reconciled Version The reconciled version status field holds the specific version that was reconciled by the ocm-controller.\nVerified ","date":"2023-06-28","id":24,"permalink":"/docs/controller/controller-reference/ocm-controller/component-version/","summary":"\u003cp\u003eThe \u003ccode\u003eComponentVersion\u003c/code\u003e API produces component descriptors for a specific component version.\u003c/p\u003e\n\u003ch2 id=\"example\"\u003eExample\u003c/h2\u003e\n\u003cp\u003eThe following is an example of a ComponentVersion:\u003c/p\u003e","tags":[],"title":"Component Version"},{"content":"OCM Controller API reference v1alpha1 Packages:\ndelivery.ocm.software/v1alpha1 delivery.ocm.software/v1alpha1 Package v1alpha1 contains API Schema definitions for the delivery v1alpha1 API group\nResource Types: Component Component gathers together reconciled information about a component.\nField Description name\nstring version\nstring registry\nRegistry ComponentSubscription ComponentSubscription is the Schema for the componentsubscriptions API\nField Description metadata\nKubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec\nComponentSubscriptionSpec interval\nKubernetes meta/v1.Duration Interval is the reconciliation interval, i.e. at what interval shall a reconciliation happen. This is used to requeue objects for reconciliation in case of success as well as already reconciling objects.\nsource\nOCMRepository destination\nOCMRepository component\nstring serviceAccountName\nstring (Optional) ServiceAccountName can be used to configure access to both destination and source repositories. If service account is defined, it\u0026rsquo;s usually redundant to define access to either source or destination, but it is still allowed to do so. https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account\nsemver\nstring (Optional) verify\n[]Signature status\nComponentSubscriptionStatus ComponentSubscriptionSpec (Appears on: ComponentSubscription) ComponentSubscriptionSpec defines the desired state of ComponentSubscription\nField Description interval\nKubernetes meta/v1.Duration Interval is the reconciliation interval, i.e. at what interval shall a reconciliation happen. This is used to requeue objects for reconciliation in case of success as well as already reconciling objects.\nsource\nOCMRepository destination\nOCMRepository component\nstring serviceAccountName\nstring (Optional) ServiceAccountName can be used to configure access to both destination and source repositories. If service account is defined, it\u0026rsquo;s usually redundant to define access to either source or destination, but it is still allowed to do so. https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account\nsemver\nstring (Optional) verify\n[]Signature ComponentSubscriptionStatus (Appears on: ComponentSubscription) ComponentSubscriptionStatus defines the observed state of ComponentSubscription\nField Description lastAttemptedVersion\nstring (Optional) LastAttemptedVersion defines the latest version encountered while checking component versions. This might be different from last applied version which should be the latest applied/replicated version. The difference might be caused because of semver constraint or failures during replication.\nobservedGeneration\nint64 (Optional) ObservedGeneration is the last reconciled generation.\nlastAppliedVersion\nstring (Optional) LastAppliedVersion defines the final version that has been applied to the destination component version.\nreplicatedRepositoryURL\nstring (Optional) ReplicatedRepositoryURL defines the final location of the reconciled Component.\nconditions\n[]Kubernetes meta/v1.Condition (Optional) OCMRepository (Appears on: ComponentSubscriptionSpec) OCMRepository defines details for a repository, such as access keys and the url.\nField Description url\nstring secretRef\ngithub.com/fluxcd/pkg/apis/meta.LocalObjectReference (Optional) Registry (Appears on: Component) Registry defines information about the location of a component.\nField Description url\nstring SecretRef (Appears on: Signature) SecretRef clearly denotes that the requested option is a Secret.\nField Description secretRef\ngithub.com/fluxcd/pkg/apis/meta.LocalObjectReference Signature (Appears on: ComponentSubscriptionSpec) Signature defines the details of a signature to use for verification.\nField Description name\nstring Name of the signature.\npublicKey\nSecretRef Key which is used for verification.\nThis page was automatically generated with gen-crd-api-reference-docs\n","date":"2022-01-25","id":25,"permalink":"/docs/controller/controller-reference/replication-controller/","summary":"\u003ch1\u003eOCM Controller API reference v1alpha1\u003c/h1\u003e\n\u003cp\u003ePackages:\u003c/p\u003e\n\u003cul class=\"simple\"\u003e\n\u003cli\u003e\n\u003ca href=\"#delivery.ocm.software%2fv1alpha1\"\u003edelivery.ocm.software/v1alpha1\u003c/a\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"delivery.ocm.software/v1alpha1\"\u003edelivery.ocm.software/v1alpha1\u003c/h2\u003e\n\u003cp\u003ePackage v1alpha1 contains API Schema definitions for the delivery v1alpha1 API group\u003c/p\u003e\nResource Types:\n\u003cul class=\"simple\"\u003e\u003c/ul\u003e\n\u003ch3 id=\"delivery.ocm.software/v1alpha1.Component\"\u003eComponent\n\u003c/h3\u003e\n\u003cp\u003eComponent gathers together reconciled information about a component.\u003c/p\u003e","tags":[],"title":"Replication Controller"},{"content":"The ComponentSubscription API produces component descriptors for a specific component version.\nExample The following is an example of a ComponentSubscription:\napiVersion: delivery.ocm.software/v1alpha1 kind: ComponentSubscription metadata: name: podinfo namespace: default spec: interval: 10m0s component: phoban.io/podinfo semver: \u0026#34;\u0026gt;=6.3.x\u0026#34; source: url: ghcr.io/phoban01 destination: url: ghcr.io/phoban01/foo secretRef: name: ghcr-credentials\rIn the above example:\nA ComponentSubscription named podinfo is created, indicated by the .metadata.name field. The replication-controller checks the Source repository every 10m0s, indicated by the .spec.interval field. It retrieves the version matching the semver constraint specified by .spec.version.semver field. Whenever a new version is available in the Source repository that satisfies .spec.semver and is greater than .status.lastAppliedVersion then the replication-controller will copy the component and all of it\u0026rsquo;s resources to the OCI repository specified in spec.destination. You can run this example by saving the manifest into subscription.yaml.\nCreate the registry access secret for GitHub Container Registry: GITHUB_USER={USERNAME} # replace with your GitHub Username. GITHUB_TOKEN={TOKEN} # replace with a GitHub Personal Access Token. kubectl create secret generic ghcr-credentials \\ --from-literal=username=$GITHUB_USER \\ --from-literal=password=$GITHUB_TOKEN\rApply the resource to the cluster, (making sure to update the destination repository details for your own ghcr.io account): kubectl apply -f subscription.yaml\rRun kubectl get componentsubscriptions to see the ComponentSubscription NAME AGE podinfo 8s\rRun kubectl describe componentsubscription podinfo to see the ComponentSubscription Status: ... Status: Conditions: Last Transition Time: 2023-07-12T08:46:09Z Message: Reconciliation success Observed Generation: 1 Reason: Succeeded Status: True Type: Ready Last Applied Version: 6.3.6 Observed Generation: 1 Replicated Repository URL: ghcr.io/phoban01/foo\rWriting a ComponentSubscription spec As with all other Kubernetes config, an ComponentSubscription needs apiVersion, kind, and metadata fields. The name of an ComponentSubscription object must be a valid DNS subdomain name.\nAn ComponentSubscription also needs a .spec section.\nComponent .spec.component is a required field that specifies the component\u0026rsquo;s name.\nVersion .spec.semver specifies a semantic version constraint used to determine the range of versions to be replicated.\nSource Repository .spec.source is a required field that provides the necessary configuration for the replication-controller to access the OCI repository where the source component versions are stored.\nSource Repository URL .spec.source.url is a required field denoting the registry in which the source OCM components are stored.\nSource Repository Secret Reference .spec.source.secretRef.name is an optional field to specify a name reference to a Secret in the same namespace as the ComponentSubscription, containing authentication credentials for the OCI repository.\nThis secret is expected to contain the keys username and password. You can create such a secret using kubectl:\nNote: that for a publicly accessible source repository, you don’t need to provide credentials.\nkubectl create secret generic registry-credentials --from-literal=username=$GITHUB_USER --from-literal=password=$GITHUB_TOKEN\rDestination Repository .spec.destination is an optional field that provides the necessary configuration for the replication-controller to access the destination repository into which components will be replicated.\nService Account Name .spec.serviceAccountName is an optional field to specify a name reference to a Service Account in the same namespace as the ComponentSubscription. The controller will fetch the image pull secrets attached to the service account and use them for authentication.\nInterval .spec.interval is a required field that specifies the interval at which the ComponentSubscription must be reconciled.\nAfter successfully reconciling the object, the replication-controller requeues it for inspection after the specified interval. The value must be in a Go recognized duration string format, e.g. 10m0s to reconcile the object every 10 minutes.\nIf the .metadata.generation of a resource changes (due to e.g. a change to the spec), this is handled instantly outside the interval window.\nVerify .spec.verify is an optional list of signatures that should be validated before the component version is replicated. Each signature item consists of a name and a publicKey.\nName .spec.verify.[].name is a required field that specifies the name of the signature that should be verified.\nPublic Key .spec.verify.[].publicKey is a required field that specifies a reference to a secret containing the public key that can be used to verify the signature. The key of the public key in the secret must match the name of the signature.\nFor example, the following ComponentSubscription verifies two signatures:\napiVersion: delivery.ocm.software/v1alpha1 kind: ComponentSubscription metadata: name: podinfo namespace: default spec: interval: 10m0s component: phoban.io/podinfo semver: \u0026#34;\u0026gt;=6.3.x\u0026#34; source: url: ghcr.io/phoban01 destination: url: ghcr.io/phoban01/foo secretRef: name: ghcr-credentials verify: - name: operations publicKey: secretRef: name: signing-keys - name: security publicKey: secretRef: name: signing-keys\rThe accompanying secret should be in the following format:\napiVersion: v1 kind: Secret metadata: name: signing-keys type: Opaque data: operations: \u0026lt;BASE64\u0026gt; security: \u0026lt;BASE64\u0026gt;\rDebugging ComponentSubscriptions There are several ways to gather information about a ComponentSubscription for debugging purposes.\nDescribe the ComponentSubscription Describing an ComponentSubscription using kubectl describe componentsubscription \u0026lt;subscription-name\u0026gt; displays the latest recorded information for the resource in the Status sections:\n... Status: Conditions: Last Transition Time: 2023-07-12T10:12:14Z Message: no matching versions found for constraint \u0026#39;\u0026gt;=7.3.x\u0026#39; Observed Generation: 2 Reason: PullingLatestVersionFailed Status: False Type: Ready Last Applied Version: 6.3.6 Observed Generation: 1 Replicated Repository URL: ghcr.io/phoban01/foo\rReconciliation errors are also logged by the controller. You can use a tool such as stern in tandem with grep to filter and refine the output of controller logs:\nstern replication-controller -n ocm-system | grep ComponentSubscription\rwill output the following log stream:\nreplication-controller-76848b97c5-4flrl manager 2023-07-12T10:13:05Z LEVEL(-4) credentials configured {\u0026#34;controller\u0026#34;: \u0026#34;componentsubscription\u0026#34;, \u0026#34;controllerGroup\u0026#34;: \u0026#34;delivery.ocm.software\u0026#34;, \u0026#34;controllerKind\u0026#34;: \u0026#34;ComponentSubscription\u0026#34;, \u0026#34;ComponentSubscription\u0026#34;: {\u0026#34;name\u0026#34;:\u0026#34;podinfo\u0026#34;,\u0026#34;namespace\u0026#34;:\u0026#34;default\u0026#34;}, \u0026#34;namespace\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;podinfo\u0026#34;, \u0026#34;reconcileID\u0026#34;: \u0026#34;a9eeba17-a533-4dc7-81fd-af97096d60aa\u0026#34;} replication-controller-76848b97c5-4flrl manager 2023-07-12T10:13:06Z ERROR Reconciler error {\u0026#34;controller\u0026#34;: \u0026#34;componentsubscription\u0026#34;, \u0026#34;controllerGroup\u0026#34;: \u0026#34;delivery.ocm.software\u0026#34;, \u0026#34;controllerKind\u0026#34;: \u0026#34;ComponentSubscription\u0026#34;, \u0026#34;ComponentSubscription\u0026#34;: {\u0026#34;name\u0026#34;:\u0026#34;podinfo\u0026#34;,\u0026#34;namespace\u0026#34;:\u0026#34;default\u0026#34;}, \u0026#34;namespace\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;podinfo\u0026#34;, \u0026#34;reconcileID\u0026#34;: \u0026#34;a9eeba17-a533-4dc7-81fd-af97096d60aa\u0026#34;, \u0026#34;error\u0026#34;: \u0026#34;failed to get latest component version: no matching versions found for constraint \u0026#39;\u0026gt;=7.3.x\u0026#39;\u0026#34;}\rComponentSubscription Status Observed Generation The replication-controller reports an observed generation in the ComponentSubscription\u0026rsquo;s .status.observedGeneration. The observed generation is the latest .metadata.generation, which resulted in either a ready state or stalled due to an error it can not recover from without human intervention.\nConditions ComponentSubscription has various states during its lifecycle, reflected as Kubernetes Conditions. These are as follows:\nreconciling signature verification ready failed reconciling Last Applied Version The LastAppliedVersion field holds information regarding the most up-to-date version that has been successfully replicated to the destination repository.\nReplicated Repository URL ReplicatedRepositoryURL holds information regarding the repository\u0026rsquo;s URL into which the last applied version has been replicated.\n","date":"2023-07-11","id":26,"permalink":"/docs/controller/controller-reference/replication-controller/component-subscription/","summary":"\u003cp\u003eThe \u003ccode\u003eComponentSubscription\u003c/code\u003e API produces component descriptors for a specific component version.\u003c/p\u003e\n\u003ch2 id=\"example\"\u003eExample\u003c/h2\u003e\n\u003cp\u003eThe following is an example of a ComponentSubscription:\u003c/p\u003e","tags":[],"title":"Component Subscription"},{"content":"","date":"2020-10-06","id":27,"permalink":"/docs/tutorials/","summary":"","tags":[],"title":"Tutorials"},{"content":"Introduction In this guide, we will show you how the tools provided by OCM make it possible to automate your air-gapped deployments.\nAir-gapped can mean different things depending on the context. For this guide, we\u0026rsquo;ll assume it means your deployment artifacts are stored in a private registry protected by the security controls at your organization. Your applications only have access to this private registry and little to no public internet access.\nWe\u0026rsquo;ll take the same podinfo component that we deployed in the Deploy Applications with OCM \u0026amp; GitOps guide but this time we will use the OCM CLI to transfer the component to our own registry. The application will then be deployed from this \u0026ldquo;private\u0026rdquo; registry. This, of course, mimics a real-world air-gap scenario. In practice, there could be many layers of security between the two registries; however, the mechanics are ultimately the same.\nTable of Contents Introduction Table of Contents Requirements Component Content Component Transfer GitOps \u0026amp; Localization Verification To Be Continued Conclusion Requirements OCM command line tool kubectl git gh kind flux Component Content The podinfo component contains three resources:\na container image for podinfo a kubernetes deployment manifest for podinfo a configuration file read by the ocm-controller We can list these resources using the ocm CLI:\nocm get resources ghcr.io/phoban01//phoban.io/podinfo -c v6.3.5 NAME VERSION IDENTITY TYPE RELATION config 6.3.5 PlainText local deployment 6.3.5 Directory local image 6.3.5 ociImage external\rIf we examine the config file, we will see a section named localization:\nocm download resource ghcr.io/phoban01//phoban.io/podinfo -c v6.3.5 config -O - apiVersion: config.ocm.software/v1alpha1 kind: ConfigData metadata: name: ocm-config ... localization: - name: image # rule name file: deployment.yaml # target file for substitution image: spec.template.spec.containers[0].image # path in file to insert image name resource: # ocm resource from which to resolve the image location name: image\rThe localization section contains a list of rules that describe the substitutions the ocm-controller needs to perform to ensure that the Local copy of our image is deployed. OCM provides an identifier for each resource which can always be resolved to a specific storage location at which the resource can be accessed. This secret sauce makes it possible to automate air-gapped deployments using OCM.\nWe can examine the image resource to see precisely where the image can be accessed:\nocm get resources ghcr.io/phoban01//phoban.io/podinfo -c 6.3.5 image -owide NAME VERSION IDENTITY TYPE RELATION ACCESSTYPE ACCESSSPEC image 6.3.5 ociImage external ociArtifact {\u0026#34;imageReference\u0026#34;:\u0026#34;ghcr.io/stefanprodan/podinfo:6.3.5\u0026#34;}\rComponent Transfer We can use the ocm CLI to transfer this public component into our \u0026ldquo;private\u0026rdquo; registry. Because we are simulating an air-gapped install, we instruct the ocm CLI to copy the resources along with the component metadata:\nAIR_GAPPED_REGISTRY=ghcr.io/phoban01/air-gapped ocm transfer component --copy-resources ghcr.io/phoban01//phoban.io/podinfo $AIR_GAPPED_REGISTRY\rIt will take few moments to complete the transfer. Once it is complete we can view the component in the air-gapped registry:\nocm get component ghcr.io/phoban01/air-gapped//phoban.io/podinfo COMPONENT VERSION PROVIDER phoban.io/podinfo 6.2.3 phoban.io phoban.io/podinfo 6.3.5 phoban.io\rLet\u0026rsquo;s examine the image resource on the component in our private registry:\nocm get resources $AIR_GAPPED_REGISTRY//phoban.io/podinfo -c 6.3.5 image -owide NAME VERSION IDENTITY TYPE RELATION ACCESSTYPE ACCESSSPEC image 6.3.5 ociImage external ociArtifact {\u0026#34;imageReference\u0026#34;:\u0026#34;ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5\u0026#34;}\rWe can see that the image reference now points to an image stored in our air-gapped registry.\nGitOps \u0026amp; Localization Now that our component has been successfully transferred, let\u0026rsquo;s deploy it using GitOps.\nWe assume you have completed the Deploy Applications with OCM \u0026amp; GitOps guide and will use that repository as the starting point for our air-gapped deployment.\nBecause our air-gapped OCM repository is private, we need to provide credentials. This will enable the ocm-controller to retrieve components from the repository.\nWe can do this using a ServiceAccount. First, create an Kubernetes Secret to hold the credentials:\nkubectl create secret docker-registry -n ocm-system ghcr-cred \\ --docker-server=ghcr.io \\ --docker-username=$GITHUB_USER \\ --docker-password=$GITHUB_TOKEN\rThen, create the ServiceAccount:\ncat \u0026gt; ./components/service_account.yaml \u0026lt;\u0026lt;EOF apiVersion: v1 kind: ServiceAccount metadata: name: air-gapped-ops namespace: ocm-system imagePullSecrets: - name: ghcr-cred EOF\rNext, let\u0026rsquo;s modify the ComponentVersion manifest so that it points to our air-gapped OCM repository and references the ServiceAccount:\napiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion metadata: name: podinfo namespace: ocm-system spec: interval: 1m0s component: phoban.io/podinfo version: semver: \u0026#34;\u0026gt;=v6.3.5\u0026#34; repository: url: ghcr.io/phoban01/air-gapped serviceAccountName: air-gapped-ops\rNow we need to tell the ocm-controller to use the Localization rules we discussed earlier. To do this, we create a Localization Custom Resource:\ncat \u0026gt; ./components/localization.yaml \u0026gt;\u0026gt;EOF apiVersion: delivery.ocm.software/v1alpha1 kind: Localization metadata: name: podinfo-deployment namespace: ocm-system spec: interval: 5m sourceRef: kind: Resource name: podinfo-deployment # this is the podinfo deployment manifest resource we created previously configRef: kind: ComponentVersion name: podinfo resourceRef: name: config # here we reference the resource containing localization rules EOF\rYou can see that we have used the existing Resource as the source for the Localization and have provided the localization rules using the spec.configRef field. The ocm-controller enables us to freely chain resources together in order to perform a sequence of transformations upon an OCM resource.\nBecause the output we want to deploy is now generated by the Localization CR rather than the Resource CR, we need to update our FluxDeployer:\napiVersion: delivery.ocm.software/v1alpha1 kind: FluxDeployer metadata: name: podinfo namespace: ocm-system spec: sourceRef: kind: Localization name: podinfo-deployment kustomizationTemplate: interval: 1m0s path: ./ prune: true targetNamespace: default\rLet\u0026rsquo;s commit, push, and reconcile these changes:\ngit add ./components git commit -m \u0026#34;move to air-gapped repository\u0026#34; git push flux reconcile source git flux-system\rVerification Flux should now be reconciling the Localized manifest with image references pointing to our private OCM repository.\nWe can easily verify this using kubectl:\nkubectl get deployment -n default podinfo -oyaml | grep image | xargs image: ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5\rTo Be Continued If we look closer, however, we will see that our application has not successfully rolled out:\nkubectl get po -n default NAME READY STATUS RESTARTS AGE podinfo-7b7d874bf8-xv75x 0/1 ImagePullBackOff 0 1m4s\rIf we filter the events we can see that Kubernetes cannot pull the image owing to missing credentials:\nkubectl get events --field-selector involvedObject.kind=Pod LAST SEEN TYPE REASON OBJECT MESSAGE 7m31s Normal Scheduled pod/podinfo-7b7d874bf8-xv75x Successfully assigned default/podinfo-7b7d874bf8-xv75x to kind-control-plane 6m7s Normal Pulling pod/podinfo-7b7d874bf8-xv75x Pulling image \u0026#34;ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5\u0026#34; 6m6s Warning Failed pod/podinfo-7b7d874bf8-xv75x Failed to pull image \u0026#34;ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5\u0026#34;: rpc error: code = Unknown desc = failed to pull and unpack image \u0026#34;ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5\u0026#34;: failed to resolve reference \u0026#34;ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5\u0026#34;: failed to authorize: failed to fetch anonymous token: unexpected status: 401 Unauthorized 6m6s Warning Failed pod/podinfo-7b7d874bf8-xv75x Error: ErrImagePull 2m31s Normal BackOff pod/podinfo-7b7d874bf8-xv75x Back-off pulling image \u0026#34;ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5\u0026#34; 5m44s Warning Failed pod/podinfo-7b7d874bf8-xv75x Error: ImagePullBackOff\rCheck out our GitOps Driven Configuration of OCM Applications guide to see how we can use the ocm-controller to configure our application at runtime and solve exactly this kind of problem!\nConclusion In this tutorial we have shown how we can automate the process of delivering software to air-gapped environments using the Open Component Model and Flux.\nWe have shown how the process of Localization is enabled via OCM and combined with GitOps delivers a seamless application deployment model suitable for any environment.\n","date":"0001-01-01","id":28,"permalink":"/docs/tutorials/ocm-and-gitops/air-gapped-gitops-with-ocm-flux/","summary":"\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eIn this guide, we will show you how the tools provided by OCM make it possible to automate your air-gapped deployments.\u003c/p\u003e","tags":[],"title":"Air-gapped GitOps with OCM \u0026 Flux"},{"content":"This chapter contains guidelines for common scenarios how to work with the Open Component Model, focusing on using CI/CD, build and publishing processes.\nUse Public Schema for Validation and Auto-Completion of Component Descriptors Separate Build and Publish Processes Separation Between Build and Publish Building Multi-Architecture Images Using Makefiles Prerequisites Templating the Resources Pipeline Integration Static and Dynamic Variable Substitution Debugging: Explain the Blobs Directory Self-Contained Transport Archives CICD Integration Use Public Schema for Validation and Auto-Completion of Component Descriptors The Open Component Model (OCM) provides a public schema to validate and offer auto-completion of component constructor files used to create component descriptors. This schema is available at https://ocm.software/schemas/configuration-schema.yaml.\nTo use this schema in your IDE, you can add the following line to your component constructor file:\n# yaml-language-server: $schema=https://ocm.software/schemas/configuration-schema.yaml\rThis line tells the YAML language server to use the OCM schema for validation and auto-completion.\nSeparate Build and Publish Processes Traditional automated builds often have unrestricted internet access, which can lead to several challenges in enterprise environments:\nLimited control over downloaded artifacts Potential unavailability of required resources Security risks associated with write permissions to external repositories Best practice: Implement a two-step process: a) Build: Create artifacts in a controlled environment, using local mirrors when possible. b) Publish: Use a separate, secured process to distribute build results.\nOCM supports this approach through filesystem-based OCM repositories, allowing you to generate Common Transport Format (CTF) archives for component versions. These archives can then be securely processed and distributed.\nSeparation Between Build and Publish Typical automated builds have access to the complete internet ecosystem. This involves downloading of content required for a build (e.g., go mod tidy), but also the upload of build results to repositories (e.g., OCI image registries).\nFor builds in enterprise environments this can lead to several challenges:\nLimited control over downloaded artifacts Potential unavailability of required resources Security risks associated with write permissions to external repositories The first problem might be acceptable, because the build results may be analyzed by scanners later to figure out what has been packaged. Triaging the results could be done in an asynchronous step later.\nThe second problem could be solved by mirroring the required artifacts and instrument the build to use the artifacts from the local mirror. Such a mirror would also offer a solution for the first problem and act as target for various scanning tools.\nThe third problem might pose severe security risks, because the build procedure as well as the downloaded artifacts may be used to catch registry credentials or at least corrupt the content of those repositories.\nThis could be avoided by establishing a contract between the build procedure of a component/project and the build system, providing the build result as a local file or file-structure. This is then taken by the build system to push content wherever it should be pushed to. This way the execution of the build procedure does not need write permissions to any repository, because it never pushes build results.\nThe Open Component Model supports such processes by supporting filesystem based OCM repositories, which are able to host any type of content, regardless of its technology. The task of the build then is to provide such a CTF archive for the OCM component versions generated by the build. This archive can then be used by the build-system to do whatever is required to make the content accessible by others.\nThe composition of such archives is described in the Getting Started section.\nTo secure further processes, a certified build-system could even sign the content with its build system certificate to enable followup-processes to verify that involved component versions are provided by accepted and well-known processes.\nBuilding Multi-Architecture Images Note: This section provides information only on on building multi-arch images. Referencing a multi-arch image does not differ from images for just one platform, see the ocm add resources command for the OCM CLI\nAt the time of writing this guide Docker is not able to build multi-architecture (multi-arch / multi-platform) images natively. Instead, the buildx plugin is used. However, this implies building and pushing images in one step to a remote container registry as the local Docker image store does not support multi-arch images (for additional information, see the Multi-arch build and images, the simple way blog post)\nThe OCM CLI has some built-in support for dealing with multi-arch images during the component version composition (ocm add resources). This allows building all artifacts locally and push them in a separate step to a container registry. This is done by building single-arch images in a first step (still using buildx for cross-platform building). In a second step all images are bundled into a multi-arch image, which is stored as local artifact in a component (CA) or common transport (CTF) archive. This archive can be processed as usual (e.g., for signing or transfer to other locations). When pushed to an image registry, multi-arch images are generated with a multi-arch-image manifest.\nThe following steps illustrate this procedure. For a simple project with a Go binary and a helm-chart assume the following file structure:\ntree . . ├── Dockerfile ├── go.mod ├── helmchart │ ├── Chart.yaml │ ├── templates │ │ ├── ... │ └── values.yaml └── main.go\rThe Dockerfile has the following content:\nFROM golang:1.19 AS builder WORKDIR /app COPY go.mod ./ COPY main.go ./ # RUN go mod download RUN go build -o /helloserver main.go # Create a new release build stage FROM gcr.io/distroless/base-debian10 # Set the working directory to the root directory path WORKDIR / # Copy over the binary built from the previous stage COPY --from=builder /helloserver /helloserver ENTRYPOINT [\u0026#34;/helloserver\u0026#34;]\rNow we want to build images for two platforms using Docker and buildx. Note the --load option for buildx to store the image in the local Docker store. Note the architecture suffix in the tag to be able to distinguish the images for the different platforms. Also note that the tag has a different syntax than the --platform argument for buildx as slashes are not allowed in tags.\n$ TAG_PREFIX=eu.gcr.io/my-project/acme # path to you OCI registry $ PLATFORM=linux/amd64 $ VERSION=0.1.0 $ docker buildx build --load -t ${TAG_PREFIX}/simpleserver:0.1.0-linux-amd64 --platform linux/amd64 . [+] Building 54.4s (14/14) FINISHED =\u0026gt; [internal] load build definition from dockerfile 0.0s =\u0026gt; =\u0026gt; transferring dockerfile: 660B 0.0s =\u0026gt; [internal] load .dockerignore 0.0s =\u0026gt; =\u0026gt; transferring context: 2B 0.0s =\u0026gt; [internal] load metadata for gcr.io/distroless/base-debian10:latest 1.6s =\u0026gt; [internal] load metadata for docker.io/library/golang:1.19 1.2s =\u0026gt; [builder 1/5] FROM docker.io/library/golang:1.19@sha256:dc76ef03e54c34a00dcdca81e55c242d24b34d231637776c4bb5c1a8e851425 49.2s =\u0026gt; =\u0026gt; resolve docker.io/library/golang:1.19@sha256:dc76ef03e54c34a00dcdca81e55c242d24b34d231637776c4bb5c1a8e8514253 0.0s =\u0026gt; =\u0026gt; sha256:14a70245b07c7f5056bdd90a3d93e37417ec26542def5a37ac8f19e437562533 156B / 156B 0.2s =\u0026gt; =\u0026gt; sha256:a2b47720d601b6c6c6e7763b4851e25475118d80a76be466ef3aa388abf2defd 148.91MB / 148.91MB 46.3s =\u0026gt; =\u0026gt; sha256:52908dc1c386fab0271a2b84b6ef4d96205a98a8c8801169554767172e45d8c7 85.97MB / 85.97MB 42.9s =\u0026gt; =\u0026gt; sha256:195ea6a58ca87a18477965a6e6a8623112bde82c5b568a29c56ce4581b6e6695 54.59MB / 54.59MB 33.8s =\u0026gt; =\u0026gt; sha256:c85a0be79bfba309d1f05dc40b447aa82b604593531fed1e7e12e4bef63483a5 10.88MB / 10.88MB 3.4s =\u0026gt; =\u0026gt; sha256:e4e46864aba2e62ba7c75965e4aa33ec856ee1b1074dda6b478101c577b63abd 5.16MB / 5.16MB 1.5s =\u0026gt; =\u0026gt; sha256:a8ca11554fce00d9177da2d76307bdc06df7faeb84529755c648ac4886192ed1 55.04MB / 55.04MB 19.3s =\u0026gt; =\u0026gt; extracting sha256:a8ca11554fce00d9177da2d76307bdc06df7faeb84529755c648ac4886192ed1 1.1s =\u0026gt; =\u0026gt; extracting sha256:e4e46864aba2e62ba7c75965e4aa33ec856ee1b1074dda6b478101c577b63abd 0.1s =\u0026gt; =\u0026gt; extracting sha256:c85a0be79bfba309d1f05dc40b447aa82b604593531fed1e7e12e4bef63483a5 0.1s =\u0026gt; =\u0026gt; extracting sha256:195ea6a58ca87a18477965a6e6a8623112bde82c5b568a29c56ce4581b6e6695 1.1s =\u0026gt; =\u0026gt; extracting sha256:52908dc1c386fab0271a2b84b6ef4d96205a98a8c8801169554767172e45d8c7 1.5s =\u0026gt; =\u0026gt; extracting sha256:a2b47720d601b6c6c6e7763b4851e25475118d80a76be466ef3aa388abf2defd 2.8s =\u0026gt; =\u0026gt; extracting sha256:14a70245b07c7f5056bdd90a3d93e37417ec26542def5a37ac8f19e437562533 0.0s =\u0026gt; [stage-1 1/3] FROM gcr.io/distroless/base-debian10@sha256:101798a3b76599762d3528635113f0466dc9655ecba82e8e33d410e2bf5cd 30.7s =\u0026gt; =\u0026gt; resolve gcr.io/distroless/base-debian10@sha256:101798a3b76599762d3528635113f0466dc9655ecba82e8e33d410e2bf5cd319 0.0s =\u0026gt; =\u0026gt; sha256:f291067d32d8d06c3b996ba726b9aa93a71f6f573098880e05d16660cfc44491 8.12MB / 8.12MB 30.6s =\u0026gt; =\u0026gt; sha256:2445dbf7678f5ec17f5654ac2b7ad14d7b1ea3af638423fc68f5b38721f25fa4 657.02kB / 657.02kB 1.3s =\u0026gt; =\u0026gt; extracting sha256:2445dbf7678f5ec17f5654ac2b7ad14d7b1ea3af638423fc68f5b38721f25fa4 0.1s =\u0026gt; =\u0026gt; extracting sha256:f291067d32d8d06c3b996ba726b9aa93a71f6f573098880e05d16660cfc44491 0.1s =\u0026gt; [internal] load build context 0.1s =\u0026gt; =\u0026gt; transferring context: 575B 0.0s =\u0026gt; [builder 2/5] WORKDIR /app 0.1s =\u0026gt; [builder 3/5] COPY go.mod ./ 0.0s =\u0026gt; [builder 4/5] COPY main.go ./ 0.0s =\u0026gt; [builder 5/5] RUN go build -o /helloserver main.go 2.4s =\u0026gt; [stage-1 2/3] COPY --from=builder /helloserver /helloserver 0.0s =\u0026gt; exporting to oci image format 0.8s =\u0026gt; =\u0026gt; exporting layers 0.2s =\u0026gt; =\u0026gt; exporting manifest sha256:04d69fc3245757d327d96b1a83b7a64543d970953c61d1014ae6980ed8b3ba2a 0.0s =\u0026gt; =\u0026gt; exporting config sha256:08641d64f612661a711587b07cfeeb6d2804b97998cfad85864a392c1aabcd06 0.0s =\u0026gt; =\u0026gt; sending tarball 0.6s =\u0026gt; importing to docker\rRepeat this command for the second platform:\n$ docker buildx build --load -t ${TAG_PREFIX}/simpleserver:0.1.0-linux-arm64 --platform linux/arm64 . docker buildx build --load -t ${TAG_PREFIX}/simpleserver:0.1.0-linux-arm64 --platform linux/arm64 . [+] Building 40.1s (14/14) FINISHED =\u0026gt; [internal] load .dockerignore 0.0s =\u0026gt; =\u0026gt; transferring context: 2B 0.0s =\u0026gt; [internal] load build definition from dockerfile 0.0s =\u0026gt; =\u0026gt; transferring dockerfile: 660B 0.0s =\u0026gt; [internal] load metadata for gcr.io/distroless/base-debian10:latest 1.0s =\u0026gt; [internal] load metadata for docker.io/library/golang:1.19 1.1s =\u0026gt; [builder 1/5] FROM docker.io/library/golang:1.19@sha256:dc76ef03e54c34a00dcdca81e55c242d24b34d231637776c4bb5c1a8e851425 37.7s =\u0026gt; =\u0026gt; resolve docker.io/library/golang:1.19@sha256:dc76ef03e54c34a00dcdca81e55c242d24b34d231637776c4bb5c1a8e8514253 0.0s =\u0026gt; =\u0026gt; sha256:cd807e8b483974845eabbdbbaa4bb3a66f74facd8c061e01e923e9f1da608271 157B / 157B 0.2s =\u0026gt; =\u0026gt; sha256:fecd6ba4b3f93b6c90f4058b512f1b0a44223ccb3244f0049b16fe2c1b41cf45 115.13MB / 115.13MB 35.6s =\u0026gt; =\u0026gt; sha256:4fb255e3f99867ec7a2286dfbbef990491cde0a5d226d92be30bad4f9e917fa4 81.37MB / 81.37MB 31.8s =\u0026gt; =\u0026gt; sha256:426e8acfed2a5373bd99b22b5a968d55a148e14bc0e0f51c5cf0d779afefe291 54.68MB / 54.68MB 26.7s =\u0026gt; =\u0026gt; sha256:3d7b1480fa4dae5cbbb7d091c46ae0ae52f501418d4cfeb849b87023364e2564 10.87MB / 10.87MB 3.0s =\u0026gt; =\u0026gt; sha256:a3e29af4daf3531efcc63588162e8bdcf3434aa5d72df4eabeb5e20c6695e303 5.15MB / 5.15MB 1.3s =\u0026gt; =\u0026gt; sha256:077c13527d405646e2f6bb426e04716ae4f8dd2fdd8966dcb0194564a2b57896 53.70MB / 53.70MB 13.3s =\u0026gt; =\u0026gt; extracting sha256:077c13527d405646e2f6bb426e04716ae4f8dd2fdd8966dcb0194564a2b57896 0.9s =\u0026gt; =\u0026gt; extracting sha256:a3e29af4daf3531efcc63588162e8bdcf3434aa5d72df4eabeb5e20c6695e303 0.3s =\u0026gt; =\u0026gt; extracting sha256:3d7b1480fa4dae5cbbb7d091c46ae0ae52f501418d4cfeb849b87023364e2564 0.1s =\u0026gt; =\u0026gt; extracting sha256:426e8acfed2a5373bd99b22b5a968d55a148e14bc0e0f51c5cf0d779afefe291 1.2s =\u0026gt; =\u0026gt; extracting sha256:4fb255e3f99867ec7a2286dfbbef990491cde0a5d226d92be30bad4f9e917fa4 1.4s =\u0026gt; =\u0026gt; extracting sha256:fecd6ba4b3f93b6c90f4058b512f1b0a44223ccb3244f0049b16fe2c1b41cf45 2.0s =\u0026gt; =\u0026gt; extracting sha256:cd807e8b483974845eabbdbbaa4bb3a66f74facd8c061e01e923e9f1da608271 0.0s =\u0026gt; [stage-1 1/3] FROM gcr.io/distroless/base-debian10@sha256:101798a3b76599762d3528635113f0466dc9655ecba82e8e33d410e2bf5cd 25.7s =\u0026gt; =\u0026gt; resolve gcr.io/distroless/base-debian10@sha256:101798a3b76599762d3528635113f0466dc9655ecba82e8e33d410e2bf5cd319 0.0s =\u0026gt; =\u0026gt; sha256:21d6a6c3921f47fb0a96eb028b4c3441944a6e5a44b30cd058425ccc66279760 7.13MB / 7.13MB 25.5s =\u0026gt; =\u0026gt; sha256:7d441aeb75fe3c941ee4477191c6b19edf2ad8310bac7356a799c20df198265c 657.02kB / 657.02kB 1.3s =\u0026gt; =\u0026gt; extracting sha256:7d441aeb75fe3c941ee4477191c6b19edf2ad8310bac7356a799c20df198265c 0.1s =\u0026gt; =\u0026gt; extracting sha256:21d6a6c3921f47fb0a96eb028b4c3441944a6e5a44b30cd058425ccc66279760 0.1s =\u0026gt; [internal] load build context 0.0s =\u0026gt; =\u0026gt; transferring context: 54B 0.0s =\u0026gt; [builder 2/5] WORKDIR /app 0.2s =\u0026gt; [builder 3/5] COPY go.mod ./ 0.0s =\u0026gt; [builder 4/5] COPY main.go ./ 0.0s =\u0026gt; [builder 5/5] RUN go build -o /helloserver main.go 0.3s =\u0026gt; [stage-1 2/3] COPY --from=builder /helloserver /helloserver 0.0s =\u0026gt; exporting to oci image format 0.5s =\u0026gt; =\u0026gt; exporting layers 0.2s =\u0026gt; =\u0026gt; exporting manifest sha256:267ed1266b2b0ed74966e72d4ae8a2dfcf77777425d32a9a46f0938c962d9600 0.0s =\u0026gt; =\u0026gt; exporting config sha256:67102364e254bf5a8e58fa21ea56eb40645851d844f5c4d9651b4af7a40be780 0.0s =\u0026gt; =\u0026gt; sending tarball 0.3s =\u0026gt; importing to docker\rCheck that the images were created correctly:\n$ docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE eu.gcr.io/acme/simpleserver 0.1.0-linux-arm64 67102364e254 6 seconds ago 22.4MB eu.gcr.io/acme/simpleserver 0.1.0-linux-amd64 08641d64f612 About a minute ago 25.7MB\rIn the next step we create a component archive and a transport archive\nPROVIDER=acme COMPONENT=github.com/$(PROVIDER)/simpleserver VERSION=0.1.0 mkdir gen ocm create ca ${COMPONENT} ${VERSION} --provider ${PROVIDER} --file gen/ca\rCreate the file resources.yaml. Note the variants in the image input and the type dockermulti:\n--- name: chart type: helmChart input: type: helm path: helmchart --- name: image type: ociImage version: 0.1.0 input: type: dockermulti repository: eu.gcr.io/acme/simpleserver variants: - \u0026#34;eu.gcr.io/acme/simpleserver:0.1.0-linux-amd64\u0026#34; - \u0026#34;eu.gcr.io/acme/simpleserver:0.1.0-linux-arm64\u0026#34;\rThe input type dockermulti adds a multi-arch image composed by the given dedicated images from the local Docker image store as local artifact to the component archive.\nAdd the described resources to your component archive:\n$ ocm add resources ./gen/ca resources.yaml processing resources.yaml... processing document 1... processing index 1 processing document 2... processing index 1 found 2 resources adding resource helmChart: \u0026#34;name\u0026#34;=\u0026#34;chart\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;\u0026lt;componentversion\u0026gt;\u0026#34;... adding resource ociImage: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;0.1.0\u0026#34;... image 0: eu.gcr.io/acme/simpleserver:0.1.0-linux-amd64 image 1: eu.gcr.io/acme/simpleserver:0.1.0-linux-arm64 image 2: INDEX locator: github.com/acme/simpleserver, repo: eu.gcr.io/acme/simpleserver, version 0.1.0\rWhat happened? The input type dockermulti is used to compose a multi-arch image on-the fly. Like the input type docker it reads images from the local Docker daemon. In contrast to this command you can list multiple images, created for different platforms, for which an OCI index manifest is created to describe a multi-arch image. The complete set of blobs is then packaged as artifact set archive and put as single resource into the component version.\nThe resulting component-descriptor.yaml in gen/ca is:\ncomponent: componentReferences: [] name: github.com/acme/simpleserver provider: acme repositoryContexts: [] resources: - access: localReference: sha256.9dd0f2cbae3b8e6eb07fa947c05666d544c0419a6e44bd607e9071723186333b mediaType: application/vnd.oci.image.manifest.v1+tar+gzip referenceName: github.com/acme/simpleserver/helloserver:0.1.0 type: localBlob name: chart relation: local type: helmChart version: 0.1.0 - access: localReference: sha256.4e26c7dd46e13c9b1672e4b28a138bdcb086e9b9857b96c21e12839827b48c0c mediaType: application/vnd.oci.image.index.v1+tar+gzip referenceName: github.com/acme/simpleserver/eu.gcr.io/acme/simpleserver:0.1.0 type: localBlob name: image relation: local type: ociImage version: 0.1.0 sources: [] version: 0.1.0 meta: schemaVersion: v2\rNote that there is only one resource of type image with media-type application/vnd.oci.image.index.v1+tar+gzip which is the standard media type for multi-arch images.\n$ ls -l gen/ca/blobs total 24M -rw-r--r-- 1 d058463 staff 24M Dec 1 09:50 sha256.4e26c7dd46e13c9b1672e4b28a138bdcb086e9b9857b96c21e12839827b48c0c -rw-r--r-- 1 d058463 staff 4.7K Dec 1 09:50 sha256.9dd0f2cbae3b8e6eb07fa947c05666d544c0419a6e44bd607e9071723186333b\rThe file sha256.4e26\u0026hellip; contains the multi-arch image packaged as OCI artifact set:\n$ tar tvf gen/ca/blobs/sha256.4e26c7dd46e13c9b1672e4b28a138bdcb086e9b9857b96c21e12839827b48c0c -rw-r--r-- 0 0 0 741 Jan 1 2022 index.json -rw-r--r-- 0 0 0 38 Jan 1 2022 oci-layout drwxr-xr-x 0 0 0 0 Jan 1 2022 blobs -rw-r--r-- 0 0 0 3051520 Jan 1 2022 blobs/sha256.05ef21d763159987b9ec5cfb3377a61c677809552dcac3301c0bde4e9fd41bbb -rw-r--r-- 0 0 0 723 Jan 1 2022 blobs/sha256.117f12f0012875471168250f265af9872d7de23e19f0d4ef05fbe99a1c9a6eb3 -rw-r--r-- 0 0 0 6264832 Jan 1 2022 blobs/sha256.1496e46acd50a8a67ce65bac7e7287440071ad8d69caa80bcf144892331a95d3 -rw-r--r-- 0 0 0 6507520 Jan 1 2022 blobs/sha256.66817c8096ad97c6039297dc984ebc17c5ac9325200bfa9ddb555821912adbe4 -rw-r--r-- 0 0 0 491 Jan 1 2022 blobs/sha256.75a096351fe96e8be1847a8321bd66535769c16b2cf47ac03191338323349355 -rw-r--r-- 0 0 0 3051520 Jan 1 2022 blobs/sha256.77192cf194ddc77d69087b86b763c47c7f2b0f215d0e4bf4752565cae5ce728d -rw-r--r-- 0 0 0 1138 Jan 1 2022 blobs/sha256.91018e67a671bbbd7ab875c71ca6917484ce76cde6a656351187c0e0e19fe139 -rw-r--r-- 0 0 0 17807360 Jan 1 2022 blobs/sha256.91f7bcfdfda81b6c6e51b8e1da58b48759351fa4fae9e6841dd6031528f63b4a -rw-r--r-- 0 0 0 1138 Jan 1 2022 blobs/sha256.992b3b72df9922293c05f156f0e460a220bf601fa46158269ce6b7d61714a084 -rw-r--r-- 0 0 0 14755840 Jan 1 2022 blobs/sha256.a83c9b56bbe0f6c26c4b1d86e6de3a4862755d208c9dfae764f64b210eafa58c -rw-r--r-- 0 0 0 723 Jan 1 2022 blobs/sha256.e624040295fb78a81f4b4b08b43b4de419f31f21074007df8feafc10dfb654e6 $ tar xvf gen/ca/blobs/sha256.4e26c7dd46e13c9b1672e4b28a138bdcb086e9b9857b96c21e12839827b48c0c -O - index.json | jq . x index.json { \u0026#34;schemaVersion\u0026#34;: 2, \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.index.v1+json\u0026#34;, \u0026#34;manifests\u0026#34;: [ { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.manifest.v1+json\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:e624040295fb78a81f4b4b08b43b4de419f31f21074007df8feafc10dfb654e6\u0026#34;, \u0026#34;size\u0026#34;: 723 }, { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.manifest.v1+json\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:117f12f0012875471168250f265af9872d7de23e19f0d4ef05fbe99a1c9a6eb3\u0026#34;, \u0026#34;size\u0026#34;: 723 }, { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.index.v1+json\u0026#34;, \u0026#34;digest\u0026#34;: \u0026#34;sha256:75a096351fe96e8be1847a8321bd66535769c16b2cf47ac03191338323349355\u0026#34;, \u0026#34;size\u0026#34;: 491, \u0026#34;annotations\u0026#34;: { \u0026#34;org.opencontainers.image.ref.name\u0026#34;: \u0026#34;0.1.0\u0026#34;, \u0026#34;software.ocm/tags\u0026#34;: \u0026#34;0.1.0\u0026#34; } } ], \u0026#34;annotations\u0026#34;: { \u0026#34;software.ocm/main\u0026#34;: \u0026#34;sha256:75a096351fe96e8be1847a8321bd66535769c16b2cf47ac03191338323349355\u0026#34; } }\rYou can create a common transport archive from the component archive.\ncm transfer ca gen/ca gen/ctf transferring version \u0026#34;github.com/acme/simpleserver:0.1.0\u0026#34;... ...resource 0(github.com/acme/simpleserver/helloserver:0.1.0)... ...resource 1(github.com/acme/simpleserver/eu.gcr.io/acme/simpleserver:0.1.0)... ...adding component version...\rOr you can push it directly to the OCM repository:\n$ OCMREPO=ghcr.io/${PROVIDER} $ ocm transfer ca gen/ca $OCMREPO transferring version \u0026#34;github.com/acme/simpleserver:0.1.0\u0026#34;... ...resource 0(github.com/acme/simpleserver/helloserver:0.1.0)... ...resource 1(github.com/acme/simpleserver/eu.gcr.io/acme/simpleserver:0.1.0)... ...adding component version...\rThe repository now should contain three additional artifacts. Depending on the OCI registry and the corresponding UI you may see that the uploaded OCI image is a multi-arch-image. For example on GitHub packages under the attribute OS/Arch you can see two platforms, linux/amd64 and linux/arm64\nFor automation and reuse purposes you may consider templating resource files and Makefiles (see below).\nUsing Makefiles Developing with the Open Component Model usually is an iterative process of building artifacts, generating component descriptors, analyzing and finally publishing them. To simplify and speed up this process it should be automated using a build tool. One option is to use a Makefile. The following example can be used as a starting point and can be modified according to your needs.\nIn this example we will automate the same example as in the sections before:\nCreating a multi-arch image from Go sources from a Git repository using the Docker CLI Packaging the image and a Helm chart into a common transport archive Signing and publishing the build result Prerequisites The OCM CLI must be installed and be available in your PATH The Makefile is located in the top-level folder of a Git project Operating system is Unix/Linux A sub-directory local can be used for local settings e.g. environment varibles, RSA keys, \u0026hellip; A sub-directory gen will be used for generated artifacts from the make buildcommand It is recommended to add local/ and gen/ to the .gitignore file We use the following file system layout for the example:\n$ tree . . ├── Dockerfile ├── LICENSE ├── Makefile ├── README.md ├── go.mod ├── helmchart │ ├── Chart.yaml │ ├── templates │ │ ├── NOTES.txt │ │ ├── _helpers.tpl │ │ ├── deployment.yaml │ │ ├── hpa.yaml │ │ ├── ingress.yaml │ │ ├── service.yaml │ │ ├── serviceaccount.yaml │ │ └── tests │ │ └── test-connection.yaml │ └── values.yaml ├── local │ └── env.sh ├── main.go ├── resources.yaml └── VERSION\rThis Makefile can be used NAME ?= simpleserver PROVIDER ?= acme.org GITHUBORG ?= acme IMAGE = ghcr.io/$(GITHUBORG)/demo/$(NAME) COMPONENT = $(PROVIDER)/demo/$(NAME) OCMREPO ?= ghcr.io/$(GITHUBORG)/ocm MULTI ?= true PLATFORMS ?= linux/amd64 linux/arm64 REPO_ROOT = . VERSION = $(shell git describe --tags --exact-match 2\u0026gt;/dev/null|| echo \u0026#34;$$(cat $(REPO_ROOT)/VERSION)\u0026#34;) COMMIT = $(shell git rev-parse HEAD) EFFECTIVE_VERSION = $(VERSION)-$(COMMIT) GIT_TREE_STATE := $(shell [ -z \u0026#34;$(git status --porcelain 2\u0026gt;/dev/null)\u0026#34; ] \u0026amp;\u0026amp; echo clean || echo dirty) GEN = ./gen OCM = ocm CHART_SRCS=$(shell find helmchart -type f) GO_SRCS=$(shell find . -name \\*.go -type f) ifeq ($(MULTI),true) FLAGSUF = .multi endif .PHONY: build build: $(GEN)/build .PHONY: version version: @echo $(VERSION) .PHONY: ca ca: $(GEN)/ca $(GEN)/ca: $(GEN)/.exists $(GEN)/image.$(NAME)$(FLAGSUF) resources.yaml $(CHART_SRCS) $(OCM) create ca -f $(COMPONENT) \u0026#34;$(VERSION)\u0026#34; --provider $(PROVIDER) --file $(GEN)/ca $(OCM) add resources --templater spiff $(GEN)/ca COMMIT=\u0026#34;$(COMMIT)\u0026#34; VERSION=\u0026#34;$(VERSION)\u0026#34; \\ IMAGE=\u0026#34;$(IMAGE):$(VERSION)\u0026#34; PLATFORMS=\u0026#34;$(PLATFORMS)\u0026#34; MULTI=$(MULTI) resources.yaml @touch $(GEN)/ca $(GEN)/build: $(GO_SRCS) go build . @touch $(GEN)/build .PHONY: image image: $(GEN)/image.$(NAME) $(GEN)/image.$(NAME): $(GEN)/.exists Dockerfile $(OCMSRCS) docker build -t $(IMAGE):$(VERSION) --file Dockerfile $(COMPONENT_ROOT) .; @touch $(GEN)/image.$(NAME) .PHONY: multi multi: $(GEN)/image.$(NAME).multi $(GEN)/image.$(NAME).multi: $(GEN)/.exists Dockerfile $(GO_SRCS) echo \u0026#34;Building Multi $(PLATFORMS)\u0026#34; for i in $(PLATFORMS); do \\ tag=$$(echo $$i | sed -e s:/:-:g); \\ echo \u0026#34;Building platform $$i with tag: $$tag\u0026#34;; \\ docker buildx build --load -t $(IMAGE):$(VERSION)-$$tag --platform $$i .; \\ done @touch $(GEN)/image.$(NAME).multi .PHONY: ctf ctf: $(GEN)/ctf $(GEN)/ctf: $(GEN)/ca @rm -rf $(GEN)/ctf $(OCM) transfer ca $(GEN)/ca $(GEN)/ctf touch $(GEN)/ctf .PHONY: push push: $(GEN)/ctf $(GEN)/push.$(NAME) $(GEN)/push.$(NAME): $(GEN)/ctf $(OCM) transfer ctf -f $(GEN)/ctf $(OCMREPO) @touch $(GEN)/push.$(NAME) .PHONY: transport transport: ifneq ($(TARGETREPO),) $(OCM) transfer component -Vc $(OCMREPO)//$(COMPONENT):$(VERSION) $(TARGETREPO) else @echo \u0026#34;Cannot transport no TARGETREPO defined as destination\u0026#34; \u0026amp;\u0026amp; exit 1 endif $(GEN)/.exists: @mkdir -p $(GEN) @touch $@ .PHONY: info info: @echo \u0026#34;VERSION: $(VERSION)\u0026#34; @echo \u0026#34;COMMIT: $(COMMIT)\u0026#34; @echo \u0026#34;TREESTATE: $(GIT_TREE_STATE)\u0026#34; .PHONY: describe describe: $(GEN)/ctf ocm get resources --lookup $(OCMREPO) -r -o treewide $(GEN)/ctf .PHONY: descriptor descriptor: $(GEN)/ctf ocm get component -S v3alpha1 -o yaml $(GEN)/ctf .PHONY: clean clean: rm -rf $(GEN) The Makefile supports the following targets:\nbuild (default) simple Go build version show current VERSION of Github repository image build a local Docker image multi build multi-arch images with Docker ca execute build and create a component archive ctf create a common transport format archive push push the common transport archive to an OCI registry info show variables used in Makefile (version, commit, etc.) describe display the component version in a tree-form descriptor show the component descriptor of the component version transport transport the component from the upload repository into another OCM repository clean delete all generated files (but does not delete Docker images) The variables assigned with ?= at the beginning can be set from outside and override the default declared in the Makefile. Use either an environment variable or an argument when calling make.\nExample:\nPROVIDER=foo make ca\rTemplating the Resources The Makefile uses a dynamic list of generated platforms for the images. You can just set the PLATFORMS variable:\nMULTI ?= true PLATFORMS ?= linux/amd64 linux/arm64 If MULTI is set to true, the variable PLATFORMS will be evaluated to decide which image variants will be built. This has to be reflected in the resources.yaml. It has to use the input type dockermulti and list all the variants which should be packaged into a multi-arch image. This list depends on the content of the Make variable.\nThe OCM CLI supports this by enabling templating mechanisms for the content by selecting a templater using the option --templater .... The example uses the Spiff templater.\n$(GEN)/ca: $(GEN)/.exists $(GEN)/image.$(NAME)$(FLAGSUF) resources.yaml $(CHART_SRCS) $(OCM) create ca -f $(COMPONENT) \u0026#34;$(VERSION)\u0026#34; --provider $(PROVIDER) --file $(GEN)/ca $(OCM) add resources --templater spiff $(GEN)/ca COMMIT=\u0026#34;$(COMMIT)\u0026#34; VERSION=\u0026#34;$(VERSION)\u0026#34; \\ IMAGE=\u0026#34;$(IMAGE):$(VERSION)\u0026#34; PLATFORMS=\u0026#34;$(PLATFORMS)\u0026#34; MULTI=$(MULTI) resources.yaml @touch $(GEN)/ca The variables given to the add resources command are passed to the templater. The template looks like:\nname: image type: ociImage version: (( values.VERSION )) input: type: (( bool(values.MULTI) ? \u0026#34;dockermulti\u0026#34; :\u0026#34;docker\u0026#34; )) repository: (( index(values.IMAGE, \u0026#34;:\u0026#34;) \u0026gt;= 0 ? substr(values.IMAGE,0,index(values.IMAGE,\u0026#34;:\u0026#34;)) :values.IMAGE )) variants: (( bool(values.MULTI) ? map[split(\u0026#34; \u0026#34;, values.PLATFORMS)|v|-\u0026gt; values.IMAGE \u0026#34;-\u0026#34; replace(v,\u0026#34;/\u0026#34;,\u0026#34;-\u0026#34;)] :~~ )) path: (( bool(values.MULTI) ? ~~ :values.IMAGE ))\rBy using a variable values.MULTI, the command distinguishes between a single Docker image and a multi-arch image. With map[], the platform list from the Makefile is mapped to a list of tags created by the docker buildx command used in the Makefile. The value ~~ is used to undefine the yaml fields not required for the selected case (the template can be used for multi- and single-arch builds).\n$(GEN)/image.$(NAME).multi: $(GEN)/.exists Dockerfile $(GO_SRCS) echo \u0026#34;Building Multi $(PLATFORMS)\u0026#34; for i in $(PLATFORMS); do \\ tag=$$(echo $$i | sed -e s:/:-:g); \\ echo \u0026#34;Building platform $$i with tag: $$tag\u0026#34;; \\ docker buildx build --load -t $(IMAGE):$(VERSION)-$$tag --platform $$i .; \\ done @touch $(GEN)/image.$(NAME).multi Pipeline Integration Pipeline infrastructures are heterogenous, so there is no universal answer how to integrate a build pipeline with OCM. Usually, the simplest way is using the OCM command line interface. Following you will find an example using GitHub actions.\nThere are two repositories dealing with GitHub actions: The first one provides various actions that can be called from a workflow. The second one provides the required installations of the OCM parts into the container.\nAn typical workflow for a build step will create a component version and a transport archive:\njobs: create-ocm: runs-on: ubuntu-latest steps: ... - name: setup OCM uses: open-component-model/ocm-setup-action@main ... - name: create OCM component version uses: open-component-model/ocm-action@main with: action: create_component component: acme.org/demo/simpleserver provider: ${{ env.PROVIDER }} version: github.com/jensh007 ...\rThis creates a component version for the current build. Additionally, a transport archive may be created or the component version along with the built container images may be uploaded to an OCI registry, etc.\nMore documentation is available here. A full example can be found in the sample Github repository.\nStatic and Dynamic Variable Substitution Looking at the settings file shows that some variables like the version or the commit change with every build or release. In many cases, these variables will be auto-generated during the build.\nOther variables like the version of 3rd-party components will just change from time to time and are often set manually by an engineer or release manager. It is useful to separate between static and dynamic variables. Static files can be checked-in into the source control system and are maintained manually. Dynamic variables can be generated during build.\nExample: manually maintained:\nNAME: microblog COMPONENT_NAME_PREFIX: github.com/acme.org/microblog PROVIDER: ocm.software ELASTIC_VERSION: 8.5.1 MARIADB_VERSION: 10.6.11 MARIADB_CHART_VERSION: 11.4.2 NGINX_VERSION: 1.5.1 NGINX_CHART_VERSION: 4.4.2\rauto-generated from a build script:\nVERSION: 0.23.1 COMMIT: 5f03021059c7dbe760ac820a014a8a84166ef8b4\rocm add componentversions --create --file ../gen/ctf --settings ../gen/dynamic_settings.yaml --settings static_settings.yaml component-constructor.yaml\rDebugging: Explain the Blobs Directory For analyzing and debugging the content of a transport archive, there are some supportive commands to analyze what is contained in the archive and what is stored in which blob:\ntree ../gen/ctf ../gen/ctf ├── artifact-index.json └── blobs ├── ... ├── sha256.59ff88331c53a2a94cdd98df58bc6952f056e4b2efc8120095fbc0a870eb0b67 ├── ...\rocm get resources -r -o wide ../gen/ctf ... --- REFERENCEPATH: github.com/acme.org/microblog/nginx-controller:1.5.1 NAME : nginx-controller-chart VERSION : 1.5.1 IDENTITY : TYPE : helmChart RELATION : local ACCESSTYPE : localBlob ACCESSSPEC : {\u0026#34;localReference\u0026#34;:\u0026#34;sha256:59ff88331c53a2a94cdd98df58bc6952f056e4b2efc8120095fbc0a870eb0b67\u0026#34;,\u0026#34;mediaType\u0026#34;:\u0026#34;application/vnd.oci.image.manifest.v1+tar+gzip\u0026#34;,\u0026#34;referenceName\u0026#34;:\u0026#34;github.com/acme.org/microblog/nginx-controller/ingress-nginx:4.4.2\u0026#34;} ...\rSelf-Contained Transport Archives The transport archive created from a component-constructor file, using the command ocm add componentversions --create ..., does not automatically resolve image references to external OCI registries and stores them in the archive. If you want to create a self-contained transport archive with all images stored as local artifacts, you need to use the --copy-resources option of the ocm transfer ctf command. This will copy all external images to the blobs directory of the archive.\nocm transfer ctf --copy-resources \u0026lt;ctf-dir\u0026gt; \u0026lt;new-ctf-dir-or-oci-repo-url\u0026gt;\rNote that this archive can become huge if there an many external images involved!\nCICD Integration Configure rarely changing variables in a static file and generate dynamic variables during the build from the environment. See the Static and Dynamic Variable Substitution section above.\n","date":"2023-03-13","id":29,"permalink":"/docs/tutorials/best-practices/","summary":"\u003cp\u003eThis chapter contains guidelines for common scenarios how to work with the Open Component Model, focusing on using CI/CD, build and publishing processes.\u003c/p\u003e","tags":[],"title":"Best Practices"},{"content":"Introduction Let\u0026rsquo;s illustrate a very simple \u0026ldquo;Hello World\u0026rdquo; example application and show how to leverage OCM to build an application component containing a Helm Chart and an OCI Image and deploy it to a local kind k8s cluster. The topics ocm localization and configuration are NOT part of this very simple example, but is covered in other tutorials.\nAs base we use the podinfo application from Stefan Prodan\u0026rsquo;s Github repo. All files can be found here.\nAt the end of the tutorial you will have created one OCM component for your business application podinfo. This component will be composed using the OCM guidelines and consist of multiple resources, alongside an OCI image and a Helm chart.\nFor building multiple components in one shot the \u0026ldquo;all-in-one\u0026rdquo; mechanism becomes handy.\nRequirements OCM command line tool kubectl git kind flux Building the Application Component Using OCM First we build an OCM component which contains Helm Charts in different kind of formats. This 101 guide explains all possible formats a HelmChart resource can have in OCM, but in reality you\u0026rsquo;ll just pick the one most appropriate to you.\nPrepare Helm Charts We are leveraging Kubernetes deployments which often use Helm charts. The OCM specification supports Helm charts as artifact type. For this simple example, we will re-use existing open source community Helm charts.\nThe OCM CLI supports referencing Helm charts stored in an OCI registry or Helm chart repositories, as well as local archives or folders. The preferred option is to store Helm charts in an OCI registry or Helm repository, as this allows for easy sharing and versioning of the Helm charts.\nHelm charts can be embedded in the component archive in four different ways:\nreferenced in OCI registry referenced in Helm repository as local *.tgz file as local folder containing a Helm Chart file To demonstrate No. 3. and 4. we need a Helm chart on our local machine. For the sake of the this simplified guide, we download and unpack an already existing open source Helm chart for podinfo. In a real world application, this would be your own Helm chart. You will most likely store your own Helm charts within a git repository and leverage a CI/CD pipeline to build *.tgz Helm chart files in order to push them to your OCI registry or Helm repository.\nDownloading Helm charts can easily be achieved using the Helm CLI:\nhelm repo add \u0026lt;repo-name\u0026gt; \u0026lt;helm-chart-repo-url\u0026gt; helm pull --destination \u0026lt;target-dir\u0026gt; \u0026lt;repo-name/chart-name\u0026gt;\rFor the podinfo example:\nhelm repo add podinfo https://stefanprodan.github.io/podinfo helm pull --destination . podinfo/podinfo\rThe Helm chart is then stored in the current working directory as podinfo-6.7.0.tgz and can be referenced as path from there in the component-constructor.yaml file (see below).\nUnpack podinfo-6.7.0.tgz to simulate the process as if this helm chart is our own and not downloaded from a public repository:\ntar -xzf podinfo-6.7.0.tgz\rInput Specification The corresponding input file for building our component version (component-constructor.yaml) looks like:\n# specify a schema to validate the configuration and get auto-completion in your editor # yaml-language-server: $schema=https://ocm.software/schemas/configuration-schema.yaml components: # podinfo component - name: ${COMPONENT_NAME_PREFIX}/podinfo labels: - name: \u0026#34;org.opencontainers.image.source\u0026#34; value: \u0026#34;https://github.com/stb1337/ocm-hello-world-v1\u0026#34; version: ${PODINFO_VERSION} provider: name: ${PROVIDER} resources: # Helm chart in OCI registry - name: helm-chart-external-oci type: helmChart version: ${PODINFO_VERSION} access: type: ociArtifact imageReference: ghcr.io/stefanprodan/charts/podinfo:${PODINFO_VERSION} # Helm Chart in Helm repository - name: helm-chart-external-helm-repo type: helmChart version: ${PODINFO_VERSION} access: type: helm helmChart: podinfo:${PODINFO_CHART_VERSION} helmRepository: https://stefanprodan.github.io/podinfo # Helm chart as local tgz file - name: helm-chart-local-tgz type: helmChart input: type: helm path: podinfo-${PODINFO_CHART_VERSION}.tgz # Helm chart as local folder - name: helm-chart-local-folder type: helmChart version: ${PODINFO_VERSION} input: type: dir path: ./podinfo/ # Image referenced in the Helm chart - name: image type: ociImage version: ${PODINFO_VERSION} access: type: ociArtifact repository: ocm/ocm.software/podinfo/image imageReference: ghcr.io/stefanprodan/podinfo:${PODINFO_VERSION}\rSome frequently changing parameters have been extracted as variables. The OCM CLI uses templating to fill them with values. The templating mechanism is described here. For this example we use the default template engine type subst.\nNote the differences between the various components:\nBuilding the Common Transport Archive (CTF) From the input file component-constructor.yaml the common transport archive can be created with the OCM CLI. We need to provide values for all variables, which can be passed in the command line or stored in a file. For many variables, having a values file is more convenient. The corresponding file settings.yaml may look like this:\nVERSION: 0.0.1 NAME: ocm-hello-world-v1 COMPONENT_NAME_PREFIX: ocm.software PROVIDER: stb1337 PODINFO_VERSION: 6.7.0 PODINFO_CHART_VERSION: 6.7.0\rCreate the transport archive with the following commands:\nocm add componentversions --create --file \u0026lt;ctf-target-dir\u0026gt; --settings settings.yaml component-constructor.yaml\rocm add componentversions --create --file ocm-hello-world --settings settings.yaml component-constructor.yaml processing component-constructor.yaml... processing document 1... processing index 1 found 1 component adding component ocm.software/podinfo:6.7.0... adding resource helmChart: \u0026#34;name\u0026#34;=\u0026#34;helm-chart-external-oci\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;6.7.0\u0026#34;... adding resource helmChart: \u0026#34;name\u0026#34;=\u0026#34;helm-chart-external-helm-repo\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;6.7.0\u0026#34;... adding resource helmChart: \u0026#34;name\u0026#34;=\u0026#34;helm-chart-local-tgz\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;\u0026lt;componentversion\u0026gt;\u0026#34;... adding resource helmChart: \u0026#34;name\u0026#34;=\u0026#34;helm-chart-local-folder\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;6.7.0\u0026#34;... adding resource ociImage: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;6.7.0\u0026#34;...\rYou can view all component versions in a transport archive using the command:\nocm get componentversion -o yaml \u0026lt;ctf-target-dir\u0026gt;\rocm get componentversion ./ocm-hello-world COMPONENT VERSION PROVIDER ocm.software/podinfo 6.7.0 stb1337\rYou can store the transport archive in an OCI registry (this step needs a proper configuration of credentials for the OCM CLI):\nocm transfer ctf -f \u0026lt;ctf-target-dir\u0026gt; \u0026lt;oci-repo-url\u0026gt;\rUsing the --copy-resources flag the OCM CLI will copy also copy all referenced resources to the OCI registry, making the resources part of the OCM component version, creating a self-contained component version.\nocm transfer ctf --copy-resources --enforce --overwrite ./ocm-hello-world OCIRegistry::ghcr.io/stb1337/ocm-hello-world-v1 transferring component \u0026#34;ocm.software/podinfo\u0026#34;... transferring version \u0026#34;ocm.software/podinfo:6.7.0\u0026#34;... ...resource 0 helm-chart-external-oci[helmChart](stefanprodan/charts/podinfo:6.7.0)... ...resource 1 helm-chart-external-helm-repo[helmChart]... ...resource 2 helm-chart-local-tgz[helmChart](ocm.software/podinfo/podinfo:6.7.0)... ...resource 3 helm-chart-local-folder[helmChart]... ...resource 4 image[ociImage](stefanprodan/podinfo:6.7.0)... ...adding component version...\rNote: Be careful with the -f or --overwrite flag. This will replace existing component versions in the OCI registry. During development it is useful being able to overwrite existing component versions until something is ready for release. For released versions you should never use this flag! Released component versions should be immutable and should never be overwritten. They serve as source of truth for what the release is made of and should never be changed.\nPackage Navigate to the overview of your OCI repository, which should list the following items:\nDeploying the OCM Software Artifact By this step we have created a transport archive containing all required parts (images and Helm charts) for installing the application. This archive is self-contained and can be transferred to an OCI registry with a single command from the OCM tooling. After pushing this archive to an OCI registry we have a shared location that can be used as a source of deployment without any external references. As an alternative, you can transport the archive using offline mechanisms (file transfer, USB-stick) and push it on a target location in an OCI registry.\nTo actually deploy the application we need to get access to the Helm charts contained in the archive. We can use the OCM CLI to retrieve their location. See the example below.\nSetup Local Kind Cluster Create local kind cluster on your local machine:\nkind create cluster -n ocm-hello-world Creating cluster \u0026#34;ocm-hello-world\u0026#34; ... ✓ Ensuring node image (kindest/node:v1.29.2) 🖼 ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹️ ✓ Installing CNI 🔌 ✓ Installing StorageClass 💾 Set kubectl context to \u0026#34;kind-ocm-hello-world\u0026#34; You can now use your cluster with: kubectl cluster-info --context kind-ocm-hello-world Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community 🙂\rMake sure that your current kubectl context is set to \u0026ldquo;kind-ocm-hello-world\u0026rdquo;:\nkind export kubeconfig -n ocm-hello-world Set kubectl context to \u0026#34;kind-ocm-hello-world\u0026#34; kubectl cluster-info Kubernetes control plane is running at https://127.0.0.1:52112 CoreDNS is running at https://127.0.0.1:52112/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use \u0026#39;kubectl cluster-info dump\u0026#39;.\rInstall Flux:\nflux install ✚ generating manifests ✔ manifests build completed ► installing components in flux-system namespace CustomResourceDefinition/alerts.notification.toolkit.fluxcd.io created CustomResourceDefinition/buckets.source.toolkit.fluxcd.io created CustomResourceDefinition/gitrepositories.source.toolkit.fluxcd.io created CustomResourceDefinition/helmcharts.source.toolkit.fluxcd.io created CustomResourceDefinition/helmreleases.helm.toolkit.fluxcd.io created CustomResourceDefinition/helmrepositories.source.toolkit.fluxcd.io created CustomResourceDefinition/kustomizations.kustomize.toolkit.fluxcd.io created CustomResourceDefinition/ocirepositories.source.toolkit.fluxcd.io created CustomResourceDefinition/providers.notification.toolkit.fluxcd.io created CustomResourceDefinition/receivers.notification.toolkit.fluxcd.io created Namespace/flux-system created ResourceQuota/flux-system/critical-pods-flux-system created ServiceAccount/flux-system/helm-controller created ServiceAccount/flux-system/kustomize-controller created ServiceAccount/flux-system/notification-controller created ServiceAccount/flux-system/source-controller created ClusterRole/crd-controller-flux-system created ClusterRole/flux-edit-flux-system created ClusterRole/flux-view-flux-system created ClusterRoleBinding/cluster-reconciler-flux-system created ClusterRoleBinding/crd-controller-flux-system created Service/flux-system/notification-controller created Service/flux-system/source-controller created Service/flux-system/webhook-receiver created Deployment/flux-system/helm-controller created Deployment/flux-system/kustomize-controller created Deployment/flux-system/notification-controller created Deployment/flux-system/source-controller created NetworkPolicy/flux-system/allow-egress created NetworkPolicy/flux-system/allow-scraping created NetworkPolicy/flux-system/allow-webhooks created ◎ verifying installation ✔ helm-controller: deployment ready ✔ kustomize-controller: deployment ready ✔ notification-controller: deployment ready ✔ source-controller: deployment ready ✔ install finished\rInstall OCM controller:\nocm controller install ► running pre-install check ► installing prerequisites ► installing cert-manager with version v1.13.2 ✔ successfully fetched install file ► applying to cluster... ► waiting for ocm deployment to be ready ✔ cert-manager successfully installed ► creating certificate for internal registry ✔ successfully installed prerequisites ► installing ocm-controller with version latest ► got latest version \u0026#34;v0.18.1\u0026#34; ✔ successfully fetched install file ► applying to cluster... ► waiting for ocm deployment to be ready ✔ ocm-controller successfully installed\rInspect Component Descriptor Let\u0026rsquo;s assume that we have pushed the transport archive to an OCI registry. We need the identity of the component version and the location of the component-descriptors in the OCI registry:\nComponentVersion: name: ocm.software/podinfo version: 6.7.0\nURL of OCI registry: ghcr.io/stb1337/ocm-hello-world-v1\nIt is convenient to put this into an environment variable:\nexport OCM_REPO=ghcr.io/stb1337/ocm-hello-world-v1\rGetting the component version 6.7.0 of the application with the OCM CLI:\nocm get componentversion --repo OCIRegistry::${OCM_REPO} ocm.software/podinfo:6.7.0 -o yaml\r--- component: componentReferences: [] creationTime: \u0026#34;2024-03-21T15:55:18Z\u0026#34; labels: - name: org.opencontainers.image.source value: https://github.com/stb1337/ocm-hello-world-v1 name: ocm.software/podinfo provider: stb1337 repositoryContexts: - baseUrl: ghcr.io componentNameMapping: urlPath subPath: stb1337/ocm-hello-world-v1 type: OCIRegistry resources: - access: localReference: sha256:cf9318c4944f733f8ce925ca0b818cdae638dce4107a13c3395984bb86306c4b mediaType: application/vnd.cncf.helm.chart.content.v1.tar+gzip type: localBlob digest: hashAlgorithm: SHA-256 normalisationAlgorithm: genericBlobDigest/v1 value: cf9318c4944f733f8ce925ca0b818cdae638dce4107a13c3395984bb86306c4b name: helm-chart-external relation: external type: helmChart version: 6.7.0 - access: imageReference: ghcr.io/stb1337/ocm-hello-world-v1/ocm.software/podinfo/podinfo:6.7.0 type: ociArtifact digest: hashAlgorithm: SHA-256 normalisationAlgorithm: ociArtifactDigest/v1 value: fa473086ce82810801785ec4ab70763fa81fcd971082035906a1695b9014c019 name: helm-chart-local-tgz relation: local type: helmChart version: 6.7.0 - access: localReference: sha256:8ff0604bfaebe6791ac4285c38a9f02771452497530367eeae49f1cf8594ca4c mediaType: application/x-tar type: localBlob digest: hashAlgorithm: SHA-256 normalisationAlgorithm: genericBlobDigest/v1 value: 8ff0604bfaebe6791ac4285c38a9f02771452497530367eeae49f1cf8594ca4c name: helm-chart-local-folder relation: local type: helmChart version: 6.7.0 - access: localReference: sha256:4a05cbc915a171301efdaad863d7d1bb0bc9193730767eca9385c49361956863 mediaType: application/x-tgz type: localBlob digest: hashAlgorithm: SHA-256 normalisationAlgorithm: genericBlobDigest/v1 value: 4a05cbc915a171301efdaad863d7d1bb0bc9193730767eca9385c49361956863 name: manifests relation: local type: dir version: 6.7.0 - access: imageReference: ghcr.io/stb1337/ocm-hello-world-v1/stefanprodan/podinfo:6.7.0 type: ociArtifact digest: hashAlgorithm: SHA-256 normalisationAlgorithm: ociArtifactDigest/v1 value: c04843c796025fbaa2574344994cb2461041b5e1d6b7a0de76b2b9fa46318e08 name: image relation: external type: ociImage version: 6.7.0 sources: [] version: 6.7.0 meta: schemaVersion: v2\rWith this we can drill down to the installable Helm charts and the container images:\nocm get resource --repo OCIRegistry::${OCM_REPO} ocm.software/podinfo:6.7.0 -o wide NAME VERSION IDENTITY TYPE RELATION ACCESSTYPE ACCESSSPEC helm-chart-external 6.7.0 helmChart external localBlob {\u0026#34;localReference\u0026#34;:\u0026#34;sha256:cf9318c4944f733f8ce925ca0b818cdae638dce4107a13c3395984bb86306c4b\u0026#34;,\u0026#34;mediaType\u0026#34;:\u0026#34;application/vnd.cncf.helm.chart.content.v1.tar+gzip\u0026#34;} helm-chart-local-folder 6.7.0 helmChart local localBlob {\u0026#34;localReference\u0026#34;:\u0026#34;sha256:8ff0604bfaebe6791ac4285c38a9f02771452497530367eeae49f1cf8594ca4c\u0026#34;,\u0026#34;mediaType\u0026#34;:\u0026#34;application/x-tar\u0026#34;} helm-chart-local-tgz 6.7.0 helmChart local ociArtifact {\u0026#34;imageReference\u0026#34;:\u0026#34;ghcr.io/stb1337/ocm-hello-world-v1/ocm.software/podinfo/podinfo:6.7.0\u0026#34;} image 6.7.0 ociImage external ociArtifact {\u0026#34;imageReference\u0026#34;:\u0026#34;ghcr.io/stb1337/ocm-hello-world-v1/stefanprodan/podinfo:6.7.0\u0026#34;}\rApply Kubernetes Manifest Create file k8s-component-version/01-pod-info-kind.yaml with the following content:\n#k8s-component-version/01-pod-info-kind.yaml apiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion metadata: name: ocm-hello-world-podinfo namespace: ocm-system spec: component: ocm.software/podinfo interval: 10s repository: url: ghcr.io/stb1337/ocm-hello-world-v1 secretRef: name: ghcr-pull-secret version: semver: \u0026#34;6.7.0\u0026#34; --- apiVersion: delivery.ocm.software/v1alpha1 kind: Resource metadata: name: ocm-hello-world-podinfo-helm-chart-external namespace: ocm-system spec: interval: 10s sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion name: ocm-hello-world-podinfo namespace: ocm-system resourceRef: name: helm-chart-external-helm-repo version: \u0026#34;6.7.0\u0026#34; --- apiVersion: delivery.ocm.software/v1alpha1 kind: FluxDeployer metadata: name: ocm-hello-world-podinfo-helm-chart-external namespace: ocm-system spec: interval: 10s sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: Resource name: ocm-hello-world-podinfo-helm-chart-external helmReleaseTemplate: values: replicaCount: 3 image: repository: ghcr.io/stb1337/ocm-hello-world-v1/stefanprodan/podinfo ui: color: \u0026#34;#8F00FF\u0026#34; message: \u0026#34;Hello from remote referenced Helm Chart\u0026#34; serviceAccount: enabled: true name: \u0026#34;sa-podinfo-ghcr-io-1\u0026#34; imagePullSecrets: - name: pull-secret interval: 10s releaseName: \u0026#34;podinfo-helm-chart-external\u0026#34; targetNamespace: default --- apiVersion: delivery.ocm.software/v1alpha1 kind: Resource metadata: name: ocm-hello-world-podinfo-helm-chart-local-tgz namespace: ocm-system spec: interval: 10s sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion name: ocm-hello-world-podinfo namespace: ocm-system resourceRef: name: helm-chart-local-tgz version: \u0026#34;6.7.0\u0026#34; --- apiVersion: delivery.ocm.software/v1alpha1 kind: FluxDeployer metadata: name: ocm-hello-world-podinfo-helm-chart-local-tgz namespace: ocm-system spec: interval: 10s sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: Resource name: ocm-hello-world-podinfo-helm-chart-local-tgz helmReleaseTemplate: values: replicaCount: 2 image: repository: ghcr.io/stb1337/ocm-hello-world-v1/stefanprodan/podinfo ui: color: \u0026#34;#FFC0CB\u0026#34; message: \u0026#34;Hello from local .tar file Helm Chart\u0026#34; serviceAccount: enabled: true name: \u0026#34;sa-podinfo-ghcr-io-2\u0026#34; imagePullSecrets: - name: pull-secret interval: 10s releaseName: \u0026#34;podinfo-helm-chart-local-tgz\u0026#34; targetNamespace: default --- apiVersion: delivery.ocm.software/v1alpha1 kind: Resource metadata: name: ocm-hello-world-podinfo-image namespace: ocm-system spec: interval: 10s sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion name: ocm-hello-world-podinfo namespace: ocm-system resourceRef: name: image version: \u0026#34;6.7.0\u0026#34;\rCreate two Kubernetes secrets in order for OCM and Kubernetes to pull from your private OCI registry:\nexport GITHUB_USER=.. \u0026amp;\u0026amp; export GITHUB_TOKEN=ghp_.... \u0026amp;\u0026amp; export GITHUB_USER_EMAIL=steffen.... kubectl create secret docker-registry pull-secret -n default \\ --docker-server=ghcr.io \\ --docker-username=$GITHUB_USER \\ --docker-password=$GITHUB_TOKEN \\ --docker-email=$GITHUB_USER_EMAIL kubectl create secret generic ghcr-pull-secret -n ocm-system \\ --from-literal=username=$GITHUB_USER \\ --from-literal=password=$GITHUB_TOKEN\rApply the manifest to your local kind cluster:\nk apply -f k8s-component-version/01-pod-info-kind.yaml componentversion.delivery.ocm.software/ocm-hello-world-podinfo created resource.delivery.ocm.software/ocm-hello-world-podinfo-helm-chart-external created fluxdeployer.delivery.ocm.software/ocm-hello-world-podinfo-helm-chart-external created resource.delivery.ocm.software/ocm-hello-world-podinfo-helm-chart-local-tgz created fluxdeployer.delivery.ocm.software/ocm-hello-world-podinfo-helm-chart-local-tgz created resource.delivery.ocm.software/ocm-hello-world-podinfo-image created\rkubectl port-forward service/podinfo-helm-chart-external -n default 9898:9898 Forwarding from 127.0.0.1:9898 -\u0026gt; 9898 Forwarding from [::1]:9898 -\u0026gt; 9898 Handling connection for 9898\rkubectl port-forward service/podinfo-helm-chart-local-tgz -n default 9898:9898 Forwarding from 127.0.0.1:9898 -\u0026gt; 9898 Forwarding from [::1]:9898 -\u0026gt; 9898 Handling connection for 9898\r","date":"2024-03-19","id":30,"permalink":"/docs/tutorials/build-deploy-infrastructure-via-helm-charts-with-ocm/","summary":"\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eLet\u0026rsquo;s illustrate a very simple \u0026ldquo;Hello World\u0026rdquo; example application and show how to leverage OCM to build an application component containing a Helm Chart and an OCI Image and deploy it to a local \u003ccode\u003ekind\u003c/code\u003e k8s cluster.\nThe topics \u003ccode\u003eocm\u003c/code\u003e \u003ca href=\"/docs/tutorials/structuring-and-deploying-software-products-with-ocm/#localization\"\u003e\u003ccode\u003elocalization\u003c/code\u003e\u003c/a\u003e and \u003ca href=\"/docs/tutorials/structuring-and-deploying-software-products-with-ocm/#configuration\"\u003e\u003ccode\u003econfiguration\u003c/code\u003e\u003c/a\u003e are NOT part of this very simple example, but is covered in other tutorials.\u003c/p\u003e","tags":[],"title":"Build \u0026 Deploy Infrastructure via Helm Charts with OCM"},{"content":"Introduction In this specification software products are comprised of logical units called components. A component version consists of a set of technical artifacts (e.g., Docker images, Helm charts, binaries, configuration data, etc.). Such artifacts are called resources in this specification. Resources are usually built from something, e.g., code in a git repo. Those are named sources in this specification.\nOCM introduces a Component Descriptor for every component version that describes the resources, sources, and other component versions belonging to a particular component version and how to access them.\nUsually, however, real-life applications are composed of multiple components. For example, an application might consist of a frontend, a backend, a database, and a web server. During the software development process new component versions are created and third-party components might be consumed from a public registry and updated from time to time.\nNot all component version combinations of frontend, backend, database, etc. are compatible and form a valid product version. In order to define reasonable version combinations for the software product, we could use another feature of the Component Descriptor, called a Component Reference (or reference in short), which allows the aggregation of component versions.\nFor each component and each version in use, there is a Component Descriptor. For the entire application, we introduce a new component that describes the overall software product referencing all components. This describes the entire application.\nA particular version of this application is again described by a Component Descriptor, which contains references to the Component Descriptors of its components in their version in use. You are not restricted to this approach. It is, e.g., possible to create multi-level hierarchies or you could just maintain a list of component version combinations which build a valid product release.\nIn a nutshell, OCM provides a simple approach to specify what belongs to a product version. Starting with the Component Descriptor for a product version and following the component references, you could collect all artifacts belonging to this product version.\nPrerequisites We assume that you have already read the guides in the Getting Started section, as this guide discusses a more complex scenario using plain Localizations and Configurations without the use of Unpacker.\nConstructing the Component We are going to use podinfo in microservices mode. This enables us to deploy several components and configure them individually.\npodinfo has three services which we are going to model using individual component descriptors:\nbackend frontend cache (redis) We will use the following example application to demonstrate a multi-component structure using podinfo: Podinfo Component.\nThis repository contains the following items:\nComponent File The following component file describes four components: three components that represent the podinfo microservices and one aggregate component that brings together the podinfo components using references. We refer to the aggregate component as the product component.\n# specify a schema to validate the configuration and get auto-completion in your editor # yaml-language-server: $schema=https://ocm.software/schemas/configuration-schema.yaml components: # -- product component - name: ocm.software/podinfo version: 1.0.2 labels: - name: ocm.software/labels/podinfo/purpose value: - kind: test type: manual provider: name: open-component-model componentReferences: - name: backend componentName: ocm.software/podinfo/backend version: 1.0.0 - name: frontend componentName: ocm.software/podinfo/frontend version: 1.0.0 - name: redis componentName: ocm.software/redis version: 1.0.0 sources: - access: commit: ac0afafcf4aa333546634cba631f0090a0a4cbe3 ref: refs/heads/main repoUrl: https://github.com/open-component-model/podinfo type: github name: github_com_open_component_model_podinfo type: git version: 1.0.0 # -- backend component - name: ocm.software/podinfo/backend version: 1.0.0 provider: name: open-component-model labels: - name: ocm.software/labels/podinfo/service value: backend resources: - name: config type: configdata.ocm.software input: type: file mediaType: application/yaml path: backend/config.yaml compress: true - name: image relation: external type: ociImage version: 6.2.0 access: type: ociArtifact imageReference: ghcr.io/stefanprodan/podinfo:6.2.0 - name: manifests type: kustomize.ocm.fluxcd.io input: type: dir path: backend/manifests compress: true sources: - access: commit: 9d294e85d8d3fe7803d1eccbf009619078d30cb9 ref: refs/heads/main repoUrl: https://github.com/open-component-model/podinfo type: github name: github_com_open_component_model_podinfo type: git version: 1.0.0 # -- frontend component - name: ocm.software/podinfo/frontend version: 1.0.0 provider: name: open-component-model labels: - name: ocm.software/labels/podinfo/service value: frontend resources: - name: config type: configdata.ocm.software input: type: file mediaType: application/yaml path: frontend/config.yaml compress: true - name: image relation: external type: ociImage version: 6.2.0 access: type: ociArtifact imageReference: ghcr.io/stefanprodan/podinfo:6.2.0 - name: manifests type: kustomize.ocm.fluxcd.io input: type: dir path: frontend/manifests compress: true sources: - access: commit: 9d294e85d8d3fe7803d1eccbf009619078d30cb9 ref: refs/heads/main repoUrl: https://github.com/open-component-model/podinfo type: github name: github_com_open_component_model_podinfo type: git version: 1.0.0 # -- redis component - name: ocm.software/redis version: 1.0.0 provider: name: open-component-model labels: - name: ocm.software/labels/podinfo/service value: redis resources: - name: config type: configdata.ocm.software input: type: file mediaType: application/yaml path: redis/config.yaml compress: true - name: image relation: external type: ociImage version: 6.0.1 access: type: ociArtifact imageReference: redis:6.0.1 - name: manifests type: kustomize.ocm.fluxcd.io input: type: dir path: redis/manifests compress: true sources: - access: commit: 9d294e85d8d3fe7803d1eccbf009619078d30cb9 ref: refs/heads/main repoUrl: https://github.com/open-component-model/podinfo type: github name: github_com_open_component_model_podinfo type: git version: 1.0.0\rWith the components modeled we can start to build a component archive using the ocm cli:\nocm add componentversions --create --file component-archive component-constructor.yaml processing component-constructor.yaml... processing document 1... processing index 1 processing index 2 processing index 3 processing index 4 found 4 components adding component ocm.software/podinfo:1.0.2... adding reference ocm.software/podinfo/backend: \u0026#34;name\u0026#34;=\u0026#34;backend\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;1.0.0\u0026#34;... adding reference ocm.software/podinfo/frontend: \u0026#34;name\u0026#34;=\u0026#34;frontend\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;1.0.0\u0026#34;... adding reference ocm.software/redis: \u0026#34;name\u0026#34;=\u0026#34;redis\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;1.0.0\u0026#34;... adding component ocm.software/podinfo/backend:1.0.0... adding resource configdata.ocm.software: \u0026#34;name\u0026#34;=\u0026#34;config\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;\u0026lt;componentversion\u0026gt;\u0026#34;... adding resource ociImage: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;6.2.0\u0026#34;... adding resource kustomize.ocm.fluxcd.io: \u0026#34;name\u0026#34;=\u0026#34;manifests\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;\u0026lt;componentversion\u0026gt;\u0026#34;... adding component ocm.software/podinfo/frontend:1.0.0... adding resource configdata.ocm.software: \u0026#34;name\u0026#34;=\u0026#34;config\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;\u0026lt;componentversion\u0026gt;\u0026#34;... adding resource ociImage: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;6.2.0\u0026#34;... adding resource kustomize.ocm.fluxcd.io: \u0026#34;name\u0026#34;=\u0026#34;manifests\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;\u0026lt;componentversion\u0026gt;\u0026#34;... adding component ocm.software/redis:1.0.0... adding resource configdata.ocm.software: \u0026#34;name\u0026#34;=\u0026#34;config\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;\u0026lt;componentversion\u0026gt;\u0026#34;... adding resource ociImage: \u0026#34;name\u0026#34;=\u0026#34;image\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;6.0.1\u0026#34;... adding resource kustomize.ocm.fluxcd.io: \u0026#34;name\u0026#34;=\u0026#34;manifests\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;\u0026lt;componentversion\u0026gt;\u0026#34;...\rThis will create a folder called component-archive. The structure of that should look something like this:\ntree . . ├── artifact-index.json └── blobs ├── sha256.03ac3a7611e118d08fcf70e9b7be263c4a7082066f9763f71d8901d7fa2afc9d ├── sha256.118b6e8282ee1d335b1638a76a20022b6acc319177dbbce3089700da835afb6a ├── sha256.12073781e4fba95f19f046c51c90f0c4e1338d47afe4795bf6fcca163ae46eb8 ├── sha256.1f239399104ec0cc7680956eb60960d212b3368609feb83dac2c95040d24b480 ├── sha256.3c9c902ce013ca070a29634e4603c90063c96df632ef2c8e6b4447aaeb70b67e ├── sha256.3dc6209959eb782fa6f5f44892f66e9657276735bfb40407bd00ddca30d0a9d1 ├── sha256.654debd65dbadbcee73e55b675980865ddf22acffcec166c59a5e48a213e4dd5 ├── sha256.699ea8628e39256048cd1687c496fe64999a41f16f200ef5ce938ee9f19c37f0 ├── sha256.70a47378c043721e3099801dec02c44b1dd9cdef0ebf79c55784eb4666bdbc29 ├── sha256.773b28fb63f1195ff73e328744639ddc1c574d58c1e723d6e386fcd66b45bd9c ├── sha256.893be914eebd8230ef848ea82b3433c6201152f5d9925e7b5b8d68e0cec7133e ├── sha256.92991cf391167c928f3afe6891001f3dd325b64ce800cf34fad4c038141fc57f ├── sha256.98ca4d46130f5c09a704b3d8ee9af94de3c0ac73d7e990df53e64606c418fea8 ├── sha256.a779270c2fea310835d3125de90e089e423c9730a98f1acdda328470d21fced0 ├── sha256.a7dd532f80e8417ed33cf0c97328582847017895fc5146e499bdf4c94a9d17b5 ├── sha256.cae4365f264251c616210707aa4765bd95f23fd22f98abc68bae9f58d6e4506d ├── sha256.ee79c92bbcce9e7a98f07c6577fd56dd45cf6f7c2d3115216ee249f42119030e └── sha256.f6a82a23220752c232e5f66ce46f0be28b27a5af19474072c77dac6d1feb0c16 2 directories, 19 files\rThese blobs contain the resources we described when modelling our podinfo application. If we cat a random blob we get something like this:\ncat sha256.3c9c902ce013ca070a29634e4603c90063c96df632ef2c8e6b4447aaeb70b67e {\u0026#34;componentDescriptorLayer\u0026#34;:{\u0026#34;mediaType\u0026#34;:\u0026#34;application/vnd.ocm.software.component-descriptor.v2+yaml+tar\u0026#34;,\u0026#34;digest\u0026#34;:\u0026#34;sha256:699ea8628e39256048cd1687c496fe64999a41f16f200ef5ce938ee9f19c37f0\u0026#34;,\u0026#34;size\u0026#34;:2560}}%\rNext, we transfer this component to a location of your choice. Here \u0026lt;your-location\u0026gt; for me was ghcr.io/skarlso/demo-component.\nocm transfer component ./component-archive \u0026lt;your-location\u0026gt; transferring version \u0026#34;ocm.software/podinfo:1.0.2\u0026#34;... ...adding component version... transferring version \u0026#34;ocm.software/podinfo/backend:1.0.0\u0026#34;... ...resource 0... ...resource 2... ...adding component version... transferring version \u0026#34;ocm.software/podinfo/frontend:1.0.0\u0026#34;... ...resource 0... ...resource 2... ...adding component version... transferring version \u0026#34;ocm.software/redis:1.0.0\u0026#34;... ...resource 0... ...resource 2... ...adding component version... 4 versions transferred\rWith the transfer completed, we now have a component version that we can use and deploy throughout this example.\nPodinfo Components Backend The backend files contain the following relevant data:\nmanifests configmap.yaml\ncontains configuration options such as PODINFO_UI_COLOR deploy.yaml\nthe deployment configuration. Note that this deployment yaml contains an attribute image that will be configured using the config.yaml explained below.\nspec: containers: - name: backend image: not-an-image\rkustomization.yaml makes sure only the relevant files are applied\nservice.yaml to expose the service endpoint and make discoverable\nconfig.yaml contains the configuration and localization rules which will be applied to the deployment file. Localization will use an image resource to replace the above value for the atribute image with the correct one Configuration will use the config information to configure some default values for those values such as color and message. Frontend Frontend contains the same file structure as backend. The only differences are the deployed services.\nCache The cache contains the same resources as backend. The only differences are the values of those deployments.\nConstructing the Kubernetes Objects ComponentVersion We start by creating an image pull secret since the component that we just transferred was placed in a private OCI registry. The pull secret will be used by the OCM client or OCM controller to access this package in ghcr. To create the secret, run:\nkubectl create secret docker-registry pull-secret -n ocm-system \\ --docker-server=ghcr.io \\ --docker-username=$GITHUB_USER \\ --docker-password=$GITHUB_TOKEN \\ --docker-email=$GITHUB_EMAIL\rNow we create a ComponentVersion custom resource that will trigger a reconcile of the podinfo component.\napiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion metadata: name: podinfocomponent-version namespace: ocm-system spec: component: ocm.software/podinfo interval: 10m0s repository: url: \u0026lt;your-location\u0026gt; # this is where you transferred the component to secretRef: name: pull-secret version: semver: 1.0.2\rThis will reconcile the ComponentDescriptor for the specific version, making the component metadata available for other Kubernetes resources to consume. If everything was successful, we can inspect the created component version:\nkubectl describe componentversion -n ocm-system podinfocomponent-version\rapiVersion: delivery.ocm.software/v3alpha1 kind: ComponentVersion metadata: name: podinfocomponent-version namespace: ocm-system spec: component: ocm.software/podinfo interval: 10m0s repository: url: \u0026lt;your-location\u0026gt; serviceAccountName: admin-account version: semver: 1.0.2 status: componentDescriptor: componentDescriptorRef: name: ocm.software-podinfo-1.0.2-2456627037531301773 namespace: ocm-system name: ocm.software/podinfo references: - componentDescriptorRef: name: ocm.software-podinfo-backend-1.0.0-3945706267509967991 namespace: ocm-system name: backend version: 1.0.0 - componentDescriptorRef: name: ocm.software-podinfo-frontend-1.0.8-11612684200430752646 namespace: ocm-system name: frontend version: 1.0.8 - componentDescriptorRef: name: ocm.software-redis-1.0.0-6199010409340612397 namespace: ocm-system name: redis version: 1.0.0 version: 1.0.2 conditions: - lastTransitionTime: \u0026#34;2023-06-21T10:59:22Z\u0026#34; message: \u0026#39;Applied version: \u0026#39; observedGeneration: 1 reason: Succeeded status: \u0026#34;True\u0026#34; type: Ready observedGeneration: 1 reconciledVersion: 1.0.2\rThe important bits here are the references. These are all the components that the top component contains. These references are used to fetch and identify component dependencies. This component will also contain which version was last reconciled.\nComponentDescriptor We can also examine the component descriptors using the following command:\nkubectl get componentdescriptors\rapiVersion: delivery.ocm.software/v1alpha1 kind: ComponentDescriptor metadata: name: ocm.software-podinfo-backend-1.0.0-3945706267509967991 namespace: ocm-system spec: resources: - access: globalAccess: digest: sha256:4a9fd7d9d861aff437746c170b199d15539044405f1b822e316ef49ac5f99db8 mediaType: application/yaml ref: ghcr.io/skarlso/podify/component-descriptors/ocm.software/podinfo/backend size: 354 type: ociBlob localReference: sha256:4a9fd7d9d861aff437746c170b199d15539044405f1b822e316ef49ac5f99db8 mediaType: application/yaml type: localBlob name: config relation: local type: configdata.ocm.software version: 1.0.0 - access: imageReference: ghcr.io/stefanprodan/podinfo:6.2.0 type: ociArtifact name: image relation: external type: ociImage version: 6.2.0 - access: globalAccess: digest: sha256:c61bc74d0b5ecfcca20b447c10d97d07a3cec649e1fc57a25f08fc93fcf42fde mediaType: application/x-tgz ref: ghcr.io/skarlso/podify/component-descriptors/ocm.software/podinfo/backend size: 963 type: ociBlob localReference: sha256:c61bc74d0b5ecfcca20b447c10d97d07a3cec649e1fc57a25f08fc93fcf42fde mediaType: application/x-tgz type: localBlob name: manifests relation: local type: kustomize.ocm.fluxcd.io version: 1.0.0 version: 1.0.0\rThis descriptor specifies the location of the component\u0026rsquo;s resource based on the current context (globalAccess). We can use this information to retrieve the resource from a storage layer that is accessible within our current environment.\nLocalizations, Configurations and FluxDeployer Here, we will create the localization and configuration YAML by hand and then apply it to the cluster.\nWe have to create three of each of these components. Localization, Configuration and a FluxDeployer. One for each component version.\nBackend Both, localization and configuration, are in the ConfigData object. So we point to that. The controller will use the image resource to localize the backend image. This is how it\u0026rsquo;s defined in the localizations rule:\nlocalization: - resource: name: image file: deploy.yaml image: spec.template.spec.containers[0].image\rNow, let\u0026rsquo;s construct these objects:\n# Localization apiVersion: delivery.ocm.software/v1alpha1 kind: Localization metadata: name: backend-localization namespace: ocm-system spec: configRef: kind: ComponentVersion name: podinfocomponent-version namespace: ocm-system resourceRef: name: config referencePath: - name: backend version: 1.0.0 interval: 10m0s sourceRef: kind: ComponentVersion name: podinfocomponent-version namespace: ocm-system resourceRef: name: manifests referencePath: - name: backend version: 1.0.0\r# Configuration apiVersion: delivery.ocm.software/v1alpha1 kind: Configuration metadata: name: backend-configuration namespace: ocm-system spec: configRef: kind: ComponentVersion name: podinfocomponent-version namespace: ocm-system resourceRef: name: config referencePath: - name: backend version: 1.0.0 interval: 10m0s sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: Localization name: backend-localization namespace: ocm-system\rFinally, let\u0026rsquo;s add the FluxDeployer too, which makes sure that this component is deployed to the target location.\n# FluxDeployer apiVersion: delivery.ocm.software/v1alpha1 kind: FluxDeployer metadata: name: backend-kustomization namespace: ocm-system spec: kustomizationTemplate: prune: true targetNamespace: default sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: Configuration name: backend-configuration namespace: ocm-system\rAnd that\u0026rsquo;s it.\nThe components can be found under podinfo/backend/components.\nTo apply them, simply run the following command from the podinfo root:\nkubectl apply -f backend/components\rFrontend We do the same for the Frontend component:\napiVersion: delivery.ocm.software/v1alpha1 kind: Localization metadata: name: frontend-localization namespace: ocm-system spec: configRef: kind: ComponentVersion name: podinfocomponent-version namespace: ocm-system resourceRef: name: config referencePath: - name: frontend version: 1.0.0 interval: 10m0s sourceRef: kind: ComponentVersion name: podinfocomponent-version namespace: ocm-system resourceRef: name: manifests referencePath: - name: frontend version: 1.0.0\rapiVersion: delivery.ocm.software/v1alpha1 kind: Configuration metadata: name: frontend-configuration namespace: ocm-system spec: configRef: kind: ComponentVersion name: podinfocomponent-version namespace: ocm-system resourceRef: name: config referencePath: - name: frontend version: 1.0.0 interval: 10m0s sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: Localization name: frontend-localization namespace: ocm-system\rapiVersion: delivery.ocm.software/v1alpha1 kind: FluxDeployer metadata: name: frontend-kustomization namespace: ocm-system spec: kustomizationTemplate: prune: true targetNamespace: default sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: Configuration name: frontend-configuration namespace: ocm-system\rTo apply them, simply run this command from the podinfo root:\nkubectl apply -f frontend/components\rRedis Redis is exactly the same as the above two. Just with different names and pointing to the redis resource. Try creating these yourself to see if you understood the structure. If you get stuck, you can always take a peek under podinfo/redis/components.\nTo apply them, simply run this command from the podinfo root:\nkubectl apply -f redis/components\rUnderstanding the moving parts How does the whole flow work?\nThe ocm-controller creates ComponentDescriptor resources for each referenced component version. Those component descriptors contain all the resources that those versions have, such as manifest files, configuration files, deployment files, etc.\nIt will use this dependency graph to lookup resource data in the right component version.\nLet\u0026rsquo;s take a look at each object in the cluster next.\nkubectl get localizations -A NAMESPACE NAME READY SOURCE VERSION CONFIG VERSION AGE ocm-system backend-localization True 1.0.16 1.0.16 5m ocm-system cache-localization True 1.0.16 1.0.16 5m ocm-system frontend-localization True 1.0.16 1.0.16 5m ➜ k get configuration -A NAMESPACE NAME READY SOURCE VERSION CONFIG VERSION AGE ocm-system backend-configuration True 1.0.16 1.0.16 4m25s ocm-system cache-configuration True 1.0.16 1.0.16 4m25s ocm-system frontend-configuration True 1.0.16 1.0.16 4m25s ➜ k get fluxdeployer -A NAMESPACE NAME READY AGE ocm-system backend-kustomization True 3m55s ocm-system cache-kustomization True 3m45s ocm-system frontend-kustomization True 3m35s ➜ k get snapshot -A NAMESPACE NAME READY STATUS ocm-system backend-configuration-v5l2oag True Snapshot with name \u0026#39;backend-configuration-v5l2oag\u0026#39; is ready ocm-system backend-localization-uvnrzql True Snapshot with name \u0026#39;backend-localization-uvnrzql\u0026#39; is ready ocm-system cache-configuration-kcjiqzy True Snapshot with name \u0026#39;cache-configuration-kcjiqzy\u0026#39; is ready ocm-system cache-localization-u2h3old True Snapshot with name \u0026#39;cache-localization-u2h3old\u0026#39; is ready ocm-system frontend-configuration-ut3u6pm True Snapshot with name \u0026#39;frontend-configuration-ut3u6pm\u0026#39; is ready ocm-system frontend-localization-tgqfwwk True Snapshot with name \u0026#39;frontend-localization-tgqfwwk\u0026#39; is ready ➜ k get componentversion -A NAMESPACE NAME READY VERSION AGE STATUS ocm-system podinfocomponent-version True 1.0.16 9m8s Applied version: 1.0.16 ➜ k get componentdescriptor -A NAMESPACE NAME AGE ocm-system ocm.software-podinfo-1.0.16-2456627037531301773 9m27s ocm-system ocm.software-podinfo-backend-1.0.0-3945706267509967991 9m25s ocm-system ocm.software-podinfo-frontend-1.0.8-11612684200430752646 9m23s ocm-system ocm.software-redis-1.0.0-6199010409340612397 9m21s\rAll of the components should have their Localization, Configuration, and FluxDeployer.\nLocalization A localization should look something like this:\napiVersion: delivery.ocm.software/v1alpha1 kind: Localization metadata: name: backend-localization namespace: ocm-system spec: configRef: kind: ComponentVersion name: podinfocomponent-version namespace: ocm-system resourceRef: name: config referencePath: - name: backend version: 1.0.0 interval: 10m0s sourceRef: kind: ComponentVersion name: podinfocomponent-version namespace: ocm-system resourceRef: name: manifests referencePath: - name: backend version: 1.0.0 status: conditions: - lastTransitionTime: \u0026#34;2023-06-20T12:28:47Z\u0026#34; message: Reconciliation success observedGeneration: 1 reason: Succeeded status: \u0026#34;True\u0026#34; type: Ready latestConfigVersion: 1.0.16 latestSourceVersion: 1.0.16 observedGeneration: 1 snapshotName: backend-localization-uvnrzql\rThe important fields are configRef and sourceRef. The configRef points to the resource that contains our localization rules:\nlocalization: - resource: name: image file: deploy.yaml image: spec.template.spec.containers[0].image\rThis will change the image in our deployment in the file deploy.yaml to the image resource we have in the podinfo example.\nThe sourceRef is pointing to the component version to fetch the manifests from.\nConfiguration Let\u0026rsquo;s take a look at the configuration object next (very similar to localization):\napiVersion: delivery.ocm.software/v1alpha1 kind: Configuration metadata: name: backend-configuration namespace: ocm-system spec: configRef: kind: ComponentVersion name: podinfocomponent-version namespace: ocm-system resourceRef: name: config referencePath: - name: backend version: 1.0.0 interval: 10m0s sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: Localization name: backend-localization namespace: ocm-system status: conditions: - lastTransitionTime: \u0026#34;2023-06-20T12:28:47Z\u0026#34; message: Reconciliation success observedGeneration: 2 reason: Succeeded status: \u0026#34;True\u0026#34; type: Ready latestConfigVersion: 1.0.16 latestSourceVersion: 1.0.16 observedGeneration: 2 snapshotName: backend-configuration-v5l2oag\rThe important details here are the configRef field and the sourceRef field. The configRef field defines where the configuration values are located at:\nconfiguration: defaults: message: \u0026#34;Welcome to the backend service\u0026#34; schema: type: object additionalProperties: false properties: replicas: type: string message: type: string rules: - value: (( message )) file: configmap.yaml path: data.PODINFO_UI_MESSAGE\rNote. This configuration has a source that is pointing at the Localization resource that we created. This is important because the configuration needs to work on the localized entities. Once reconciled, it will create a Snapshot. That snapshot contains the input resources that have been transformed using the supplied configuration rules.\nFluxDeployer Next, comes the FluxDeployer. The FluxDeployer will point to the last Snapshot in the chain of transformations which is the Configuration. It looks something like this:\napiVersion: delivery.ocm.software/v1alpha1 kind: FluxDeployer metadata: name: backend-kustomization namespace: ocm-system spec: kustomizationTemplate: prune: true targetNamespace: default sourceRef: apiVersion: delivery.ocm.software/v1alpha1 kind: Configuration name: backend-configuration namespace: ocm-system status: conditions: - lastTransitionTime: \u0026#34;2023-06-20T12:29:23Z\u0026#34; message: FluxDeployer \u0026#39;backend-kustomization\u0026#39; is ready observedGeneration: 2 reason: Succeeded status: \u0026#34;True\u0026#34; type: Ready kustomization: ocm-system/backend-kustomization observedGeneration: 2\rThis creates a Kustomization object. The Kustomization object is used to reconcile the created component into the target namespace. We have three of these for each component for which we would like to apply the results.\nTroubleshooting Once all objects are applied, we should see podinfo deployed in the default namespace:\nkubectl get pods NAME READY STATUS RESTARTS AGE backend-6dd8f5fbf8-xfdmq 1/1 Running 0 54m frontend-56ff5b9864-h8fgh 1/1 Running 0 54m redis-7475dd84c4-hzp2b 1/1 Running 0 54m\rNote: The pod count might vary based on the default settings in the configuration data.\nIf the deployment isn\u0026rsquo;t appearing, there are several places to check for errors:\nFlux:\nMaybe Flux didn\u0026rsquo;t kick in yet. Try to force a reconcile by running:\nflux reconcile source git flux-system -n flux-system\rEvents:\nKubernetes Events could hold some extra information. List the most recent ones with:\nkubectl events -A\rLogs:\nSometimes, you can see errors in the source-controller failing to get the right resources. Or kustomize-controller doesn\u0026rsquo;t understand something. We\u0026rsquo;ll go into getting logs in Controller Logs section.\nObject Status:\nMany of the objects have a status with the most recent error on them. The relevant objects in this case are the FluxDeployer and the OCIRepository objects. Make sure they have successful statuses.\nkubectl get ocirepositories -A NAMESPACE NAME URL READY STATUS AGE ocm-system backend-kustomization oci://registry.ocm-system.svc.cluster.local:5000/sha-3644589785534619751 True stored artifact for digest \u0026#39;2234@sha256:12100267c60d3eb5acfc564b56eb94288e33fa875c7f2191ec0a662594283ad0\u0026#39; 5m17s ocm-system cache-kustomization oci://registry.ocm-system.svc.cluster.local:5000/sha-3644589785534619751 True stored artifact for digest \u0026#39;2393@sha256:f12873dff8d8f91b5d917711f0d7d20ebc85dbfc1652bf01c8b50dc198d7f32d\u0026#39; 4m57s ocm-system frontend-kustomization oci://registry.ocm-system.svc.cluster.local:5000/sha-3644589785534619751 True stored artifact for digest \u0026#39;2539@sha256:1a37fdfbf0f109498b813bbd784a81c8b1a818d4770a49a319cc2562621dcf40\u0026#39; 4m47s\rkubectl get fluxdeployer -A NAMESPACE NAME READY AGE ocm-system backend-kustomization True 8m13s ocm-system cache-kustomization True 7m53s ocm-system frontend-kustomization True 7m43s\rController Logs There are several controllers to sift through in case something doesn\u0026rsquo;t happen the way it should.\nocm-controller To get the ocm-controller logs run:\nkubectl logs `k get pods --template \u0026#39;{{range .items}}{{.metadata.name}}{{end}}\u0026#39; --selector=app=ocm-controller -n ocm-system` -n ocm-system\rIf everything goes according to plan, there should be no errors in the logs.\nFlux controllers Flux has a couple of controllers we can check if things don\u0026rsquo;t start up (especially if we don\u0026rsquo;t see any resources in the cluster, or if we don\u0026rsquo;t see the podinfo deployment being started).\nsource-controller: This controller will contain information about the latest applied code from the repository. If there is an error here it means that the source, or rather our modifications, weren\u0026rsquo;t applied.\nkustomize-controller: This controller will contain information about reconciled objects. A Kustomization source is usually either a GitRepository or an OCIRepository. In this case, the source will be an OCIRepositoy. That repository is pointing to the in-cluster OCI repository. A snapshot creates these entries and that\u0026rsquo;s where it loads the data from.\nThe helm-controller and notification-controller aren\u0026rsquo;t relevant.\nObject statuses ComponentVersion:\nThe ComponentVersion object contains information about what components have been reconciled. We talked about that earlier at Component Version. The Status section contains any errors that could have occurred when reconciling information.\nComponentDescriptor:\nThe ComponentDescriptor holds information about each component and their resources. Read more at ComponentDescriptors.\nIf the resources section is empty in the status, there is something wrong reconciling the individual items.\nLocalization:\nThe status section contains information about the snapshot that this object created. The snapshot is used to point to the right repository in the internal OCI cache. It also contains the last applied version. The conditions section will contain any errors while reconciling the resource.\nConfiguration:\nThe status section contains information about the snapshot that this object created. The snapshot is used to point to the right repository in the internal OCI cache. It also contains the last applied version. The conditions section will contain any errors while reconciling the resource.\nSnapshots:\nThe Snapshot, most of the time, is transparent to the user. The sources are Snapshot providers. That means any object that can produce a Snapshot can be a source to a Localization, Configuration or a Resource object. A Source is a thing from which to fetch resource data such as Manifests, rules, Markdown files, descriptors, etc.\nWe can also use Snapshots to look for errors in reconciling resource data. A Snapshot\u0026rsquo;s status contains information.\napiVersion: delivery.ocm.software/v1alpha1 kind: Snapshot metadata: creationTimestamp: \u0026#34;2023-06-21T10:49:35Z\u0026#34; finalizers: - finalizers.snapshot.ocm.software generation: 2 name: backend-configuration-2agwrnt namespace: ocm-system ownerReferences: - apiVersion: delivery.ocm.software/v1alpha1 kind: Configuration name: backend-configuration uid: dfb8dede-5234-406c-8077-fc5e382ec8fd resourceVersion: \u0026#34;4591\u0026#34; uid: b8c0b983-9c27-4597-92b1-fe19aad2abca spec: digest: sha256:1f5f6173f3180c2fda00dd1267ca190628a2e8b5fa707232cebc9059f7845e29 identity: component-name: ocm.software-podinfo-1.0.16-2456627037531301773 component-version: 1.0.16 resource-name: config resource-version: 1.0.0 tag: \u0026#34;1533\u0026#34; status: conditions: - lastTransitionTime: \u0026#34;2023-06-21T10:49:35Z\u0026#34; message: Snapshot with name \u0026#39;backend-configuration-2agwrnt\u0026#39; is ready observedGeneration: 2 reason: Succeeded status: \u0026#34;True\u0026#34; type: Ready digest: sha256:1f5f6173f3180c2fda00dd1267ca190628a2e8b5fa707232cebc9059f7845e29 observedGeneration: 2 repositoryURL: http://registry.ocm-system.svc.cluster.local:5000/sha-2819236492453137798 tag: \u0026#34;1533\u0026#34;\rThis Snapshot contains a lot of information about what has been replicated in the internal registry. We can use crane to fetch it and check the generated content.\nFluxDeployer:\nFluxDeployer is used to apply the generated objects to a cluster. In the background, it\u0026rsquo;s leveraging Flux\u0026rsquo;s Kustomization object. This object\u0026rsquo;s status will contain any errors that could occur during applying generated content, like invalid data, invalid CRDs, invalid yaml, no access to the cluster, permission issues, etc. Each component has a FluxDeployer applying some kind of component data to the cluster such as, Deployments, ConfigMaps, ReplicaSets, etc.\nOCIRepository:\nThere should be one OCIRepository resource per component. The OCIRepository is created by the FluxDeployer. OCIRepository will contain any errors regarding the content of the internal registry.\nKustomization:\nKustomization objects are also created by the FluxDeployer. These objects will contain applying errors.\nCommon issues tar header invalid:\nUsually, this means that the content we are trying to sync from the OCIRepository is not a tar file. This can happen if the resource wasn\u0026rsquo;t a Directory or if the fetching of the data somehow failed.\nTo verify, we can use crane to check the content.\nTo run crane, first, expose the internal registry using port-forward like this:\nkubectl port-forward service/registry -n ocm-system 5000:5000\rThen, verify that the connection is working by running a catalog command:\ncrane catalog http://127.0.0.1:5000\rThis should list something like this:\ncrane catalog 127.0.0.1:5000 sha-10883673987458280187 sha-16809550111814969680 sha-1990151198423805921 sha-2092408510764941850 sha-2819236492453137798 sha-6687852683187729914 sha-9139473762086563639\rTo identify which of these contains our failed resource, check the failing OCIRepository object.\nkubectl get ocirepository -A NAMESPACE NAME URL READY STATUS AGE ocm-system podinfo oci://registry.ocm-system.svc.cluster.local:5000/sha-10883673987458280187 False failed to extract layer contents from artifact: tar error: archive/tar: invalid tar header 21h\rNow we know which of these contains the invalid resource. We can further identify which blob it is by either, describing the relevant snapshot, or by running a manifest command with crane.\ncrane manifest 127.0.0.1:5000/sha-10883673987458280187:1.0.0|jq { \u0026#34;schemaVersion\u0026#34;: 2, \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.docker.distribution.manifest.v2+json\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.docker.container.image.v1+json\u0026#34;, \u0026#34;size\u0026#34;: 233, \u0026#34;digest\u0026#34;: \u0026#34;sha256:6e3b5d3bfbd044c33125f20d83c2b82cd1c348b58422df4859678bc0e6c8aed5\u0026#34; }, \u0026#34;layers\u0026#34;: [ { \u0026#34;mediaType\u0026#34;: \u0026#34;application/vnd.oci.image.layer.v1.tar+gzip\u0026#34;, \u0026#34;size\u0026#34;: 1044, \u0026#34;digest\u0026#34;: \u0026#34;sha256:eae39564a446ee92d1fec8728ef0c27077995d01bbedc25e0688a1cbb7582adc\u0026#34; } ] }\rOne of these will not be what they seem. To fetch a blob run:\ncrane blob 127.0.0.1:5000/sha-10883673987458280187@sha256:eae39564a446ee92d1fec8728ef0c27077995d01bbedc25e0688a1cbb7582adc \u0026gt; temp.tar\rAnd then check what that temp.tar looks like. If the content is human-readable, there is a problem. If you encounter the component descriptor file, you can skip that. That\u0026rsquo;s not what you are looking for.\nConclusion We saw how to deploy a complex, multi-service architecture using the podinfo application.\n","date":"0001-01-01","id":31,"permalink":"/docs/tutorials/structuring-and-deploying-software-products-with-ocm/","summary":"\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eIn this specification software products are comprised of logical units called \u003ca href=\"https://github.com/open-component-model/ocm-spec/blob/main/doc/01-model/02-elements-toplevel.md#components-and-component-versions\"\u003e\u003cstrong\u003ecomponents\u003c/strong\u003e\u003c/a\u003e. A component version consists of a set of technical \u003ca href=\"https://github.com/open-component-model/ocm-spec/blob/main/doc/04-extensions/01-artifact-types/README.md\"\u003eartifacts\u003c/a\u003e (e.g., Docker images, Helm charts, binaries, configuration data, etc.). Such artifacts are called \u003cstrong\u003eresources\u003c/strong\u003e in this specification. Resources are usually built from something, e.g., code in a git repo. Those are named \u003cstrong\u003esources\u003c/strong\u003e in this specification.\u003c/p\u003e","tags":[],"title":"Structuring and Deploying Software Products with OCM"},{"content":"Introduction This tutorial will demonstrate how to get started deploying applications using the Open Component Model \u0026amp; Flux.\nIn this guide, we will leverage Flux and the ocm-controller to deploy an existing component to a Kubernetes cluster. Specifically, we will deploy the phoban.io/podinfo component that contains the resources needed to launch the podinfo application.\nHere\u0026rsquo;s a diagram showing what we\u0026rsquo;ll be building:\nAs you can see, we\u0026rsquo;ll add some manifests to a git repository that will be deployed by Flux. These will, in turn, deploy a resource from an OCM repository, in this case, a Deployment of the podinfo microservice.\nIf you\u0026rsquo;d like to learn how to build a component, then check out our Getting Started guide.\nTable of Contents Introduction Table of Contents Requirements Environment Setup Deploy the OCM Controller Deploy the Component Wrapping Up Requirements OCM command line tool kubectl git gh kind flux Environment Setup First of all, let\u0026rsquo;s create a cluster using kind:\nkind create cluster\rWith the cluster created, we can now bootstrap Flux to automate the deployment of our component. Flux can create a repository and clone it to our local environment by running the following shell command:\nexport GITHUB_REPOSITORY=podinfo-flux-repo flux bootstrap github \\ --owner $GITHUB_USER \\ --repository $GITHUB_REPOSITORY \\ --path ./clusters/kind \\ --personal\rThis command will create a GitHub repository named podinfo-flux-repo, configure Flux to use it, and deploy the resources in the ./clusters/kind directory to our Kubernetes cluster.\nLet\u0026rsquo;s now clone the repository flux has created and put in place the manifests required to deploy components:\ngh repo clone $GITHUB_REPOSITORY \u0026amp;\u0026amp; cd $GITHUB_REPOSITORY\rWe\u0026rsquo;ll add a Kustomization to the ./clusters/kind directory in order to reconcile any resources found in the ./components directory:\ncat \u0026gt; ./clusters/kind/components_kustomization.yaml \u0026lt;\u0026lt;EOF apiVersion: kustomize.toolkit.fluxcd.io/v1beta2 kind: Kustomization metadata: name: components namespace: flux-system spec: interval: 1m0s prune: true targetNamespace: ocm-system sourceRef: kind: GitRepository name: flux-system path: ./components EOF\rCommit this file, push, and then ensure Flux has reconciled the resource:\ngit add ./clusters/kind/components_kustomization.yaml git commit -m \u0026#34;add components kustomization\u0026#34; git push # trigger an immediate reconciliation of our repo flux reconcile source git flux-system # view kustomizations and their status flux get kustomizations\rDeploy the OCM Controller We can use the OCM CLI to install the controller:\nocm controller install\rDeploy the Component Now that we have flux configured and the ocm-controller installed, we can started deploying components.\nWe told flux that our component manifests will live in ./components, so let\u0026rsquo;s create that directory:\nmkdir -p ./components\rTo make the component accessible within the cluster, create the following ComponentVersion:\ncat \u0026gt; ./components/component_version.yaml \u0026lt;\u0026lt;EOF apiVersion: delivery.ocm.software/v1alpha1 kind: ComponentVersion metadata: name: podinfo namespace: ocm-system spec: interval: 1m0s component: phoban.io/podinfo version: semver: \u0026#34;\u0026gt;=v6.3.5\u0026#34; repository: url: ghcr.io/phoban01 EOF\rThen create a Resource to retrieve the deployment resource from the component:\ncat \u0026gt; ./components/resource.yaml \u0026lt;\u0026lt;EOF apiVersion: delivery.ocm.software/v1alpha1 kind: Resource metadata: name: podinfo-deployment namespace: ocm-system spec: interval: 1m0s sourceRef: kind: ComponentVersion name: podinfo resourceRef: name: deployment version: latest EOF\rFinally, create a FluxDeployer to deploy the Resource contents using Flux:\ncat \u0026gt; ./components/deployer.yaml \u0026lt;\u0026lt;EOF apiVersion: delivery.ocm.software/v1alpha1 kind: FluxDeployer metadata: name: podinfo namespace: ocm-system spec: sourceRef: kind: Resource name: podinfo-deployment kustomizationTemplate: interval: 1m0s path: ./ prune: true targetNamespace: default EOF\rAt this point we can commit these files, push to the remote repository, and tell flux to reconcile the changes:\ngit add ./components git commit -m \u0026#34;add ocm manifests\u0026#34; git push flux reconcile source git flux-system\rWithin a few moments we will see the deployment spinning up:\nkubectl get po -n default NAME READY STATUS RESTARTS AGE podinfo-84cb98c9b6-75rx5 1/1 Running 0 1m podinfo-84cb98c9b6-k4lk8 1/1 Running 0 1m\rWrapping Up That\u0026rsquo;s it! That\u0026rsquo;s how easy it is to get started using the Open Component Model and Flux.\nIf you want to know more about working with OCM and GitOps, check out these guides:\nAir-gapped GitOps with OCM \u0026amp; Flux GitOps Driven Configuration of OCM Applications ","date":"0001-01-01","id":32,"permalink":"/docs/tutorials/ocm-and-gitops/deploying-applications-with-ocm-gitops/","summary":"\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eThis tutorial will demonstrate how to get started deploying applications using the Open Component Model \u0026amp; Flux.\u003c/p\u003e\n\u003cp\u003eIn this guide, we will leverage Flux and the \u003ccode\u003eocm-controller\u003c/code\u003e to deploy an existing component to a Kubernetes cluster. Specifically, we will deploy the \u003ccode\u003ephoban.io/podinfo\u003c/code\u003e component that contains the resources needed to launch the \u003ca href=\"https://github.com/stefanprodan/podinfo\"\u003epodinfo\u003c/a\u003e application.\u003c/p\u003e","tags":[],"title":"Deploying Applications with OCM \u0026 GitOps"},{"content":"Introduction This guide is the final part of our series exploring OCM, the ocm-controller, and how to drive GitOps processes using OCM as the source of truth.\nCheck out the previous guides if you haven\u0026rsquo;t already:\nDeploy Applications with OCM \u0026amp; GitOps Air-gapped GitOps with OCM \u0026amp; Flux In this guide we will pick-up where we left off in the air-gapped example.\nWe have successfully transferred a component to our private environment and deployed it using the ocm-controller. However, the Kubernetes Deployment for podinfo is failing because it does not have permission to access our private container images.\nLet\u0026rsquo;s fix that.\nTable of Contents Introduction Table of Contents Requirements Component Content Recap GitOps \u0026amp; Configuration Verify Deployment Conclusion Requirements OCM command line tool kubectl git gh kind flux Component Content Recap We saw previously that the podinfo component contains three resources:\npodinfo container image kubernetes deployment manifest for podinfo configuration file read by the ocm-controller We can list these resources using the ocm CLI:\nocm get resources ghcr.io/phoban01//phoban.io/podinfo -c v6.3.5 NAME VERSION IDENTITY TYPE RELATION config 6.3.5 PlainText local deployment 6.3.5 Directory local image 6.3.5 ociImage external\rLet\u0026rsquo;s examine the config resource once again and this time focus on a section named configuration:\nocm download resource ghcr.io/phoban01//phoban.io/podinfo -c v6.3.5 config -O - apiVersion: config.ocm.software/v1alpha1 kind: ConfigData metadata: name: ocm-config configuration: defaults: serviceAccountName: default # this is the default value for our variable rules: - value: (( serviceAccountName )) # this variable file: deployment.yaml # will be inserted into this file path: spec.template.spec.serviceAccountName # at this path schema: # allows us to define constraints for configuration values type: object additionalProperties: false properties: serviceAccountName: type: string ...\rThe configuration section contains a set of rules, some default values, and a schema.\nThese can be used to provide configuration values, which will be inserted into our resources at runtime by the ocm-controller.\nIn the above resource we can see that there is a variable named serviceAccountName and a rule which specifies that this variable should be inserted into the path spec.template.spec.serviceAccountName in the deployment.yaml file.\nGitOps \u0026amp; Configuration Similar to how we Localized our deployment resource in the previous guide, we create another Custom Resource with the type Configuration in order to apply our configuration rules:\ncat \u0026gt; ./components/localization.yaml \u0026gt;\u0026gt;EOF apiVersion: delivery.ocm.software/v1alpha1 kind: Configuration metadata: name: podinfo-deployment namespace: ocm-system spec: interval: 1m sourceRef: kind: Localization name: podinfo-deployment # this is the podinfo deployment localization configRef: kind: ComponentVersion name: podinfo resourceRef: name: config # here we reference the configuration resource values: serviceAccountName: app-ops EOF\rYou can see that this time we have used the Localization resource as the input for the Configuration and have provided the configuration rules using the spec.configRef field. Finally, we specify our service account name in the spec.values.serviceAccountName field.\nOnce again we need to update the FluxDeployer so that it consumes the Configuration rather than the Localization:\napiVersion: delivery.ocm.software/v1alpha1 kind: FluxDeployer metadata: name: podinfo namespace: ocm-system spec: sourceRef: kind: Configuration name: podinfo-deployment kustomizationTemplate: interval: 1m0s path: ./ prune: true targetNamespace: default\rBefore we push these changes, we need to actually create the ServiceAccount and image-pull Secret in the target namespace.\nLet\u0026rsquo;s create the secret as we did previously (Note that in a real world scenario there are a number of ways to manage secrets when doing Gitops):\nkubectl create secret docker-registry -n default ghcr-cred \\ --docker-server=ghcr.io \\ --docker-username=$GITHUB_USER \\ --docker-password=$GITHUB_TOKEN\rNow let\u0026rsquo;s add the ServiceAccount:\ncat \u0026gt; ./clusters/kind/service_account.yaml \u0026lt;\u0026lt;EOF apiVersion: v1 kind: ServiceAccount metadata: name: app-ops namespace: default imagePullSecrets: - name: ghcr-cred\rFinally we are ready commit, push, and reconcile these changes:\ngit add ./components ./clusters git commit -m \u0026#34;move to air-gapped repository\u0026#34; git push flux reconcile source git flux-system\rVerify Deployment Flux should now be reconciling the Configured manifest with image references pointing to our private OCM repository and the correct ServiceAccount configured.\nWe can verify this using kubectl:\nkubectl get deployment -n default podinfo -oyaml | grep serviceAccountName | xargs serviceAccountName: app-ops\rkubectl get deployment -n default podinfo -oyaml | grep image | xargs image: ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5\rKubernetes can now retrieve the image and all pods should be happily running.\nConclusion We have shown how OCM and Flux can be combined to configure applications at runtime.\nGitOps driven configuration in tandem with the powerful Localization functionality provided by OCM offers tremendous flexibility, reliability, and scalability when deploying your applications to any kind of compute environment, be it public, private or edge.\n","date":"0001-01-01","id":33,"permalink":"/docs/tutorials/ocm-and-gitops/gitops-driven-configuration-of-ocm-applications/","summary":"\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eThis guide is the final part of our series exploring OCM, the \u003ccode\u003eocm-controller\u003c/code\u003e, and how to drive GitOps processes using OCM as the source of truth.\u003c/p\u003e","tags":[],"title":"GitOps Driven Configuration of OCM Applications"},{"content":" Overview Input Types binary dir docker dockermulti file helm ociImage spiff utf-8 Access Types gitHub helm npm ociArtifact s3 Overview The Open Component Model spec supports multiple methods how to add resources to a component version. There are two different ways to add content: Input Type and Access Type.\nAn Input type adds content by value, along with the component descriptor and stores it in the same target repository where the component is stored. After pushing the content to the target registry this always resolves to the attribute\nrelation: local\rin a component descriptor.\nAn Access Type just adds content by reference to an external location, e.g., an OCI registry. It is a kind of pointer in a component descriptor. It resolves to the attribute\nrelation: external\rin a component descriptor.\nThe following input types are supported:\nbinary dir docker dockermulti file helm ociImage spiff utf-8 Please use the latest ocm-cli to check available input types:\nocm add resources --help | grep \u0026#39; - Input type\u0026#39; | sort -f\rThe following list of access types is supported:\ngitHub localBlob ociArtifact ociBlob s3 Please use the latest ocm-cli to check available access types:\nocm ocm-accessmethods | grep \u0026#39; - Access type\u0026#39; | sort -f\rNot all access and input types can be combined in useful ways with all artifact types. But the OCM specification does not define any restrictions on possible combinations.\nThe following sections give an overview and typical usage examples for access and input types. It does not describe the full list of possible fields and their meaning. For a complete list of attributes, please see the command reference. The examples below are meant to be used in a component that looks like this:\n- name: github.com/open-component-model/megacomponent version: 0.1.0\rInput Types binary Allows to define resources with binary content being base64 encoded. Should only be used for smaller blobs.\nresources: - name: noticeencoded type : blob input: data: VGhpcyBpcyBzb21lIGJhc2U2NCBlbmNvZGVkIGRhdGEK mediaType: text/plain compress: false type: binary\rdir Defines a resource from content of a directory in the local file system. It is packed with tar and optionally compressed.\nresources: - name: megadir type : fileSystem input: type: dir path: ./logos\rdocker Takes an image from the local docker registry and adds it as a resource. Requires a running docker daemon.\nresources: - name: megaimage type : ociImage input: type: docker repository: images/mega path: megacomp:${VERSION}\rif VERSION is set to 0.1.0 the following image is imported:\ndocker image ls REPOSITORY TAG IMAGE ID CREATED SIZE megacomp 0.1.0 9aab9cbca56e 5 days ago 7.46MB\rThe target location of the image can be set with the repository field. Here the resulting image will be stored at \u0026lt;REPO_URL\u0026gt;/github.com/open-component-model/megacomponent/images/mega:1.10.\ndockermulti Takes multiple images from the local docker registry and adds them as single multi-arch image. Requires a running docker daemon. The images have to be built for different architectures/os and need a unique tag identifying them. As docker does not support multi-arch images at the time of writing this is a workaround.\nresources: - name: megaimagemulti type : ociImage input: type: dockermulti repository: images/megamulti variants: - megacomp:${VERSION}-linux-amd64 - megacomp:${VERSION}-linux-arm64\rif VERSION is set to 0.1.0 the following image is imported:\ndocker image ls REPOSITORY TAG IMAGE ID CREATED SIZE megacomp 0.1.0-linux-amd64 96659c4f7a35 5 days ago 7.05MB megacomp 0.1.0-linux-arm64 64f209acb814 5 days ago 7.46MB\rThe target location of the image can be set with the repository field. Here the resulting image will be stored at \u0026lt;REPO_URL\u0026gt;/github.com/open-component-model/megacomponent/images/megamulti:1.10.\nfile Imports a file from the local file system and adds it as a resource.\nresources: - name: mega-file type: blob input: type: file path: ./logos/logo-image.png\rhelm Imports a helm chart from the local file system and adds it as a resource.\nresources: - name: mega-chart type: helmChart input: type: helm path: ./megachart repository: charts/mega\rAfter transporting the corresponding component version to an OCI registry, the helm chart will be made available under charts/mega prefixed by the name of the component version. This auto-prefix can be disabled by using a leading slash /charts/mega. If the repository tag is omitted, the name of the helm chart from Chart.yaml will be used.\nIt is also possible to import a helm chart from a helm chart repository:\nresources: - name: mariadb-chart type: helmChart input: type: helm helmRepository: https://charts.bitnami.com/bitnami path: mariadb version: 12.2.7 repository: charts/mariadb\rHere the helm chart version 12.2.7 is copied from the path mariadb in helm chart repository https://charts.bitnami.com/bitnami. After transporting the corresponding component version to an OCI registry, the helm chart will be made available under charts/mariadb prefixed by the name of the component version. This auto-prefix can be disabled by using a leading slash /charts/mariadb. If the repository tag is omitted, the name of the helm chart from Chart.yaml will be used. There are additional optional fields caCert and caCertFile to specify a TLS certificate for the helm chart repository.\nociImage Takes an image that is located in an OCI registry and adds it as a resource.\nresources: - name: mega-image type: ociImage input: type: ociImage path: gcr.io/google_containers/echoserver:1.10 repository: images/echo\rThe target location of the image after transporting to an OCI registry can be set with the repository field. Here the resulting image will be prefixed with the name of the component version, e.g., github.com/open-component-model/megacomponent/images/echo:1.10. This auto-prefix can be disabled by using a leading slash /images/echo.\nspiff Processes a resource using the spiff templater and can provide values for variables.\nresources: - name: mega-package type: toiPackage input: type: spiff mediaType: application/vnd.toi.ocm.software.package.v1+yaml path: packagespec.yaml values: RELEASE_NAME: megacomp\rutf-8 Adds a resource from inline text.\nresources: - name: noticeplain type : blob input: text: \u0026#34;Here is some text\u0026#34; mediaType: text/plain compress: false type: utf8\rAccess Types gitHub Refers to a Git repository at a certain commit or tag.\nresources: - name: git-ocm type: blob version: ${VERSION} access: type: gitHub repoUrl: https://github.com/open-component-model/ocm commit: 42cc249aec77aa64984b2b91eb0f3b96dd63aacd\rhelm Refers to a helm chart located in a helm chart repository.\n- name: mariadb-chart type: helmChart version: ${VERSION} access: type: helm helmChart: mariadb:12.2.7 helmRepository: https://charts.bitnami.com/bitnami\rnpm Refers to an npm package located in a Javascript package registry.\n- name: prime-npm type: ocm/npmPackage version: ${VERSION} access: type: npm package: random-prime version: 4.0.0 registry: https://registry.npmjs.org\rociArtifact Refers to an image in an (external) OCI registry.\nresources: - name: echo-image version: \u0026#34;1.10\u0026#34; type: ociImage access: type: ociArtifact imageReference: gcr.io/google_containers/echoserver:1.10\rs3 Refers to an object in an AWS S3 store.\nresources: - name: gardenlinux-meta type: blob version: ${VERSION} access: type: s3 bucket: gardenlinux key: meta/singles/gcp-cloud-gardener-_prod-890.0-53b732\r","date":"0001-01-01","id":34,"permalink":"/docs/tutorials/input-and-access-types/","summary":"\u003cul\u003e\n\u003cli\u003e\u003ca href=\"#overview\"\u003eOverview\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"#input-types\"\u003eInput Types\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"#binary\"\u003ebinary\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#dir\"\u003edir\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#docker\"\u003edocker\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#dockermulti\"\u003edockermulti\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#file\"\u003efile\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#helm\"\u003ehelm\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#ociimage\"\u003eociImage\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#spiff\"\u003espiff\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#utf-8\"\u003eutf-8\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#access-types\"\u003eAccess Types\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"#github\"\u003egitHub\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#helm-1\"\u003ehelm\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#npm\"\u003enpm\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#ociartifact\"\u003eociArtifact\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#s3\"\u003es3\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"overview\"\u003eOverview\u003c/h2\u003e\n\u003cp\u003eThe Open Component Model spec supports multiple methods how to add resources to a component version. There are two different ways to add content: Input Type and Access Type.\u003c/p\u003e","tags":[],"title":"Input and Access Types"},{"content":"","date":"2023-11-07","id":35,"permalink":"/docs/examples/","summary":"","tags":[],"title":"Examples"},{"content":"The source code for the demo can be found at https://github.com/open-component-model/demo-secure-delivery. A video guide can be found here.\nFully guided walkthrough This walkthrough deploys a full end-to-end scenario demonstrating how OCM and Flux can be employed to continuously deploy applications in air-gapped environments.\nThe demo environment consists of Gitea, Tekton, Flux and the OCM controller.\nTo be able to show that provider and consumer are really disconnected, two distinct Gitea organizations are created:\nsoftware-provider software-consumer Software Provider The provider organization contains a repository which models the podinfo application. When a new release is created a Tekton pipeline will be triggered that builds the OCM component and pushes it to the software provider\u0026rsquo;s OCI registry.\nSoftware Consumer The software consumer organization models an air-gapped scenario where applications are deployed from a secure OCI registry rather than directly from an arbitrary public upstream source.\nThe software consumer organization contains a repository named ocm-applications. During the setup of the demo a PR is created which contains a set of Kubernetes manifests required to deploy the OCM component published by the software provider.\nOnce this pull request is merged the Flux machinery will deploy podinfo component. Capacitor can be used to understand the state of the cluster.\nWalkthrough Instructions are provided to guide you through the process of deploying the demo environment, cutting a release for \u0026ldquo;podinfo,\u0026rdquo; verifying the release automation, installing the component, viewing the Capacitor GitOps dashboard, accessing the deployed application, applying configuration changes, monitoring the application update, and cutting a new release with updated features.\n1. Setup demo environment To deploy the demo environment execute the following:\nmake run\nOnce the environment has been created, login to Gitea using the following credentials:\nusername: ocm-admin password: password\r2. Cut a release for podinfo Next navigate to: https://gitea.ocm.dev/software-provider/podinfo-component/releases and click \u0026ldquo;New Release\u0026rdquo;.\nEnter \u0026ldquo;v1.0.0\u0026rdquo; for both the tag name and release name, and then click \u0026ldquo;Publish Release\u0026rdquo;.\n3. Verify the release Once the release is published, navigate to https://ci.ocm.dev/#/namespaces/tekton-pipelines/pipelineruns and follow the progress of the release automation.\n4. Install the Component When the release pipeline has been completed we can install the component. Navigate to https://gitea.ocm.dev/software-consumer/ocm-applications/pulls/1 and merge the pull request.\n5. View the Capacitor Dashboard After certificates are created the Capacitor component and the dashboard will be accessible at https://capacitor.ocm.dev. Give it a minute to spin up\u0026hellip;\n5. View the application We can view the podinfo Helm release that\u0026rsquo;s been deployed in the default namespace: https://capacitor.ocm.dev/\nWe can also view the running application at https://podinfo.ocm.dev\n6. Apply configuration The application can be configured using the parameters exposed in values.yaml. Now that podinfo is deployed we can tweak a few parameters. Navigate to https://gitea.ocm.dev/software-consumer/ocm-applications/_edit/main/values.yaml\nand add the following:\npodinfo: replicas: 2 message: \u0026#34;Hello Open Component Model!\u0026#34; serviceAccountName: ocm-ops\r7. View the configured application The changes will soon be reconciled by Flux and visible at https://podinfo.ocm.dev. Note how the pod id changes now that we have 2 replicas of our application running.\n8. Cut a new release Let\u0026rsquo;s jump back to the provider repository and cut another release. This release will contain a new feature that changes the image displayed by the podinfo application. Follow the same process as before to create a release, bumping the version to v1.1.0.\n9. Verify the release Once the release is published, navigate to https://ci.ocm.dev/#/namespaces/tekton-pipelines/pipelineruns and follow the progress of the release automation.\n10. Monitor the application update Jump back to https://capacitor.ocm.dev to view the rollout of the new release.\n11. View the updated application Finally, navigate to https://podinfo.ocm.dev which now displays the OCM logo in place of the cuttlefish and the updated application version of 6.3.6\nConclusion By leveraging the capabilities of Gitea, Tekton, Flux, and the OCM controller, this demo showcases the seamless deployment of components and dependencies in a secure manner. The use of secure OCI registries and automated release pipelines ensures the integrity and reliability of the deployment process.\nUsers can easily set up the demo environment, cut releases, monitor release automation, view the Capacitor GitOps dashboard and observe the deployment and update of applications. We have presented a practical illustration of how OCM and Flux can be employed to facilitate the deployment and management of applications in air-gapped environments, offering a robust and efficient solution for secure software delivery.\nContributing Code contributions, feature requests, bug reports, and help requests are very welcome. Please refer to the Contributing Guide in the Community repository for more information on how to contribute to OCM.\nOCM follows the CNCF Code of Conduct.\nLicensing Copyright 2024-2025 SAP SE or an SAP affiliate company and Open Component Model contributors. Please see our LICENSE for copyright and license information. Detailed information including third-party components and their licensing/copyright information is available via the REUSE tool.\n","date":"2023-11-07","id":36,"permalink":"/docs/examples/secure-software-delivery-with-flux-and-ocm/","summary":"\u003cp\u003eThe source code for the demo can be found at \u003ca href=\"https://github.com/open-component-model/demo-secure-delivery\"\u003ehttps://github.com/open-component-model/demo-secure-delivery\u003c/a\u003e.\nA video guide can be found \u003ca href=\"https://share.vidyard.com/watch/NjNrZF2926RUTSUvkU4MdR\"\u003ehere\u003c/a\u003e.\u003c/p\u003e\n\u003ch2 id=\"fully-guided-walkthrough\"\u003eFully guided walkthrough\u003c/h2\u003e\n\u003cp\u003e\r\n\r\n\u003cimg\r\n src=\"/new_diagram_7403461049610658471_hu955974254496665239.webp\"\r\n width=\"3036\"\r\n height=\"1956\"\r\n decoding=\"async\"\r\n fetchpriority=\"auto\"\r\n loading=\"lazy\"\r\n alt=\"workflow\"id=\"h-rh-i-0\"\r\n/\u003e\u003c/p\u003e","tags":[],"title":"Secure software delivery with Flux and OCM"},{"content":"","date":"2020-10-06","id":37,"permalink":"/docs/roadmap/","summary":"","tags":[],"title":"Roadmap"},{"content":"You can checkout the Project Roadmap on GitHub which is based on issues and PRs from the OCM project repository.\n","date":"2020-10-06","id":38,"permalink":"/docs/roadmap/our-roadmap/","summary":"\u003cp\u003eYou can checkout the \u003ca href=\"https://github.com/orgs/open-component-model/projects/10/views/5\"\u003eProject Roadmap on GitHub\u003c/a\u003e which is based on issues and PRs from the \u003ca href=\"https://github.com/open-component-model/ocm-project\"\u003eOCM project repository\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003e\r\n\r\n\u003cimg\r\n src=\"/images/roadmap_Q2-2024_hu3456875650843085168.webp\"\r\n width=\"3335\"\r\n height=\"1386\"\r\n decoding=\"async\"\r\n fetchpriority=\"auto\"\r\n loading=\"lazy\"\r\n alt=\"roadmap\"id=\"h-rh-i-0\"\r\n/\u003e\u003c/p\u003e","tags":[],"title":"Our Roadmap"},{"content":"","date":"2020-10-06","id":39,"permalink":"/docs/support/","summary":"","tags":[],"title":"Support"},{"content":"We are here to help you with any questions you have about OCM. Here are a few ways to get support:\nMake sure you’ve read the basic documentation: OCM Overview Getting Started Check the Glossary of the OCM specification for definitions of terms. Ask a question in the OCM Slack Channel in the Kubernetes Workspace. Check and read existing issues in the OCM repositories, report a bug, or request a new feature. ","date":"2020-10-06","id":40,"permalink":"/docs/support/how-to-get-support/","summary":"\u003cp\u003eWe are here to help you with any questions you have about OCM. Here are a few ways to get support:\u003c/p\u003e","tags":[],"title":"How to get Support"},{"content":"GitHub You can stay updated with OCM\u0026rsquo;s latest advancements, join our active conversations, and delve into our enhancement proposals on each project\u0026rsquo;s GitHub issues page specifically for OCM.\nIf you\u0026rsquo;re just starting with OCM, we recommend beginning with the \u0026lsquo;good first issue\u0026rsquo; label in our repositories.\nReady to contribute directly to OCM? Whether adding code, writing tests, or assisting with our documentation, please adhere to the guidelines provided in the \u0026lsquo;contributing\u0026rsquo; documentation of the relevant OCM repository.\nSlack Join #open-component-model on Kubernetes Slack and talk to us and other community members.\nKubernetes Slack Membership\nIf you aren\u0026rsquo;t already a member on the Kubernetes Slack workspace, please request an invitation.\nOur team is passionate about delving into diverse deployment processes, exploring patterns, aiding in design, and troubleshooting issues. Who knows? Your inquiry might inspire the development of the next OCM feature!\nCommunity Meetings The OCM team holds regular community meetings to discuss new developments in the project and any topics of interest to the Open Component Model community. Please monitor the OCM slack channel for announcement notices.\nPlease consult our community documentation for more details about the Open Component Model Community.\n","date":"2022-08-12","id":41,"permalink":"/docs/support/community/","summary":"\u003ch2 id=\"github\"\u003eGitHub\u003c/h2\u003e\n\u003cp\u003eYou can stay updated with OCM\u0026rsquo;s latest advancements, join our active conversations, and delve into our enhancement proposals on each project\u0026rsquo;s GitHub issues page specifically for OCM.\u003c/p\u003e","tags":[],"title":"The OCM Community"},{"content":"","date":"2020-10-06","id":42,"permalink":"/docs/contribution/","summary":"","tags":[],"title":"Contribute"},{"content":"Welcome to the OCM community!\nThank you for taking the time to contribute to OCM.\nDCO Support Channels Ways to Contribute Find an Issue Local Development Submitting Pull Requests Licensing and Copyright information on file level Pull Request Checklist Pull Request Process Style Guidelines Release Process Guideline for AI-generated code contributions to SAP Open Source Software Projects DCO By contributing to this project you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution.\nWe require all commits to be signed. By signing off with your signature, you certify that you wrote the patch or otherwise have the right to contribute the material by the rules of the DCO:\nSigned-off-by: Jane Doe \u0026lt;jane.doe@example.com\u0026gt;\nIf your user.name and user.email are configured in your Git config, you can sign your commit automatically with git commit -s.\nSupport Channels Before opening a new issue or submitting a Pull Request, make sure to search through the docs, open and closed issues, open and merged Pull Requests, and the Discussions board to check whether your question has been raised or answered already.\nPlease open an issue in any of the repositories in the open-component-model organisation if you wish to request a new feature or report a bug.\nIf you wish to propose or discuss a more involved feature or change to any of the OCM projects, you could start a new thread in the ocm Discussion Board. For example, this could be helpful if you wish to vet an idea before writing a feature request. It is a space to discuss in public with maintainers, contributors, users, and other interested parties. After reaching some form of consensus, the proposed changes can go through the pull request process where implementation details are reviewed, approved, or rejected by maintainers.\nWays to Contribute We welcome all types of contributions, including:\nNew features Bug reports/fixes Reviewing/updating documentation Refactoring Backfilling tests Joining discussions Web design Release management Reviews Board discussions You may find it helpful to start a new thread in the ocm Discussion Board for questions, help requests, feature requests, or any other type of discussion about OCM. A maintainer will reach out to you as soon as possible.\nFind an Issue Take a look at the OCM issues to find out more about what is currently in the works and what is planned. If you find something that you are interested in picking up, please leave a comment and wait for a maintainer to give you the green light to claim it and start working on it.\nIf you would like to contribute but are unsure about where to start, feel free to let the maintainers know through the ocm Discussion Board and someone will reach out to you.\nLocal Development Each project has its own setup for local development.\nSubmitting Pull Requests Ready to contribute? Read and follow the sections below to get your contribution to the finish line.\nLicensing and Copyright information on file level In general all files of the project are created under Apache 2.0 license. The project uses the REUSE process and tooling that supports maintaining licensing information centrally in a .reuse/dep5 config file on repository level. This means that in general there SHOULD NOT be any license and copyright specifiy SPDX headers on file level. Only in cases where content is copied from sources that use a different license and already use headers like\n// SPDX-FileCopyrightText: Copyright 2010 The Go Authors. All rights reserved. // // SPDX-License-Identifier: BSD-3-Clause\rthe headers of the source file should be kept and eventually aggregated with the Apache 2.0 license. Please check the REUSE FAQ for details.\nSuch files should be explicitly added as deviating from the .reuse/dep5 config file using the Files-Excluded field. Excluding the file /pkg/foo.go and pkg/bar.go from the general rule to add the Apache 2.0 license to all files, would look like this:\nFiles: ** Copyright: 2022 SAP SE or an SAP affiliate company and Open Component Model contributors License: Apache-2.0 Files-Excluded: /pkg/foo.go pkg/bar.go Pull Request Checklist Fork the repository, push your changes to a branch on your fork, then open a PR from that branch to the source repository\u0026rsquo;s main branch. Add as much information as possible in your PR description about what changed, why, as well as steps to test these changes. Sign your commits. Ensure that the branch is up to date with main. Write a neat title that is ready to be added to future release notes. Update documentation (either in the docs or README) that cover your changes. Add unit tests and integration tests to cover your changes. Ensure that the linter and all unit and integration tests are successful. Bonus: Backfill tests/documentation to make the world a better place. Pull Request Process Create PR. Please refer to the Pull Request Checklist before marking a PR as ready to be reviewed. Triage. A maintainer will triage the Pull Request by adding the appropriate label for the issue. Assign reviews. A maintainer will be assigned to review the changes in the Pull Request. Review/Discussion. One or more maintainer will review the Pull Request. Checkout the style guidelines section for some things reviewers will look for. Address comments by answering questions or changing code. Approve/Merge. A review should be approved by at least two other maintainers. If the PR was opened by a community contributor, they should wait for a maintainer to merge the Pull Request. Style Guidelines For Go standards, it is recommended to take a look at the Go Code Review Comments and the Formatting and style section of Peter Bourgon\u0026rsquo;s Go: Best Practices for Production Environments.\nRelease Process Follow these steps to do a release:\nCreate a PR with the following: Update the version. For example, in the ocm repository, this is located in pkg/version/release.go. Add the release notes. Use the draft release notes generated by the release-drafter GitHub Action that can be found in github.com/open-component-model/\u0026lt;repository\u0026gt;/releases. Add these to the repository\u0026rsquo;s docs/releasenotes/v0.x.0.md for a given minor version. For example, for v0.2.0 (or a release candidate for this version), create docs/releasenotes/v0.2.0.md. Request reviews for the PR \u0026amp; merge it once it is approved. Navigate to the Release GitHub Action. Tick the box if this is a Release Candidate, otherwise leave it blank, and click to start the action. This will run the tests and linter, check that the release notes are present for this version, create a branch and a tag, and finally trigger the release using goreleaser. Guideline for AI-generated code contributions to SAP Open Source Software Projects As artificial intelligence evolves, AI-generated code is becoming valuable for many software projects, including open-source initiatives. While we recognize the potential benefits of incorporating AI-generated content into our open-source projects there a certain requirements that need to be reflected and adhered to when making contributions.\nWhen using AI-generated code contributions in OSS Projects, their usage needs to align with Open-Source Software values and legal requirements. We have established these essential guidelines to help contributors navigate the complexities of using AI tools while maintaining compliance with open-source licenses and the broader Open-Source Definition.\nAI-generated code or content can be contributed to SAP Open Source Software projects if the following conditions are met:\nCompliance with AI Tool Terms and Conditions: Contributors must ensure that the AI tool\u0026rsquo;s terms and conditions do not impose any restrictions on the tool\u0026rsquo;s output that conflict with the project\u0026rsquo;s open-source license or intellectual property policies. This includes ensuring that the AI-generated content adheres to the Open Source Definition.\nFiltering Similar Suggestions: Contributors must use features provided by AI tools to suppress responses that are similar to third-party materials or flag similarities. We only accept contributions from AI tools with such filtering options. If the AI tool flags any similarities, contributors must review and ensure compliance with the licensing terms of such materials before including them in the project.\nManagement of Third-Party Materials: If the AI tool\u0026rsquo;s output includes pre-existing copyrighted materials, including open-source code authored or owned by third parties, contributors must verify that they have the necessary permissions from the original owners. This typically involves ensuring that there is an open-source license or public domain declaration that is compatible with the project\u0026rsquo;s licensing policies. Contributors must also provide appropriate notice and attribution for these third-party materials, along with relevant information about the applicable license terms.\nEmployer Policies Compliance: If AI-generated content is contributed in the context of employment, contributors must also adhere to their employer’s policies. This ensures that all contributions are made with proper authorization and respect for relevant corporate guidelines.\n","date":"0001-01-01","id":43,"permalink":"/docs/contribution/contributing-guideline/","summary":"\u003cp\u003eWelcome to the OCM community!\u003c/p\u003e\n\u003cp\u003eThank you for taking the time to contribute to OCM.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"#dco\"\u003eDCO\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#support-channels\"\u003eSupport Channels\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#ways-to-contribute\"\u003eWays to Contribute\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"#find-an-issue\"\u003eFind an Issue\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#local-development\"\u003eLocal Development\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#submitting-pull-requests\"\u003eSubmitting Pull Requests\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"#licensing-and-copyright-information-on-file-level\"\u003eLicensing and Copyright information on file level\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#pull-request-checklist\"\u003ePull Request Checklist\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#pull-request-process\"\u003ePull Request Process\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#style-guidelines\"\u003eStyle Guidelines\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#release-process\"\u003eRelease Process\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#guideline-for-ai-generated-code-contributions-to-sap-open-source-software-projects\"\u003eGuideline for AI-generated code contributions to SAP Open Source Software Projects\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"dco\"\u003eDCO\u003c/h2\u003e\n\u003cp\u003eBy contributing to this project you agree to the Developer Certificate of Origin (\u003ca href=\"https://raw.githubusercontent.com/open-component-model/.github/main/DCO\"\u003eDCO\u003c/a\u003e). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution.\u003c/p\u003e","tags":[],"title":"Contributing Guideline"},{"content":"Report a Vulnerability Please do not report security vulnerabilities through public GitHub issues!\nInstead, please report them via the SAP Trust Center at https://www.sap.com/about/trust-center/security/incident-management.html.\nIf you prefer to submit via email, please send an email to secure@sap.com. If possible, encrypt your message with the SAP PGP key; please download it from the SAP Trust Center.\nPlease include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:\nThe repository name or URL Type of issue (buffer overflow, SQL injection, cross-site scripting, etc.) Full paths of the source file(s) related to the manifestation of the issue The location of the affected source code (tag/branch/commit or direct URL) Any particular configuration required to reproduce the issue Step-by-step instructions to reproduce the issue Proof-of-concept or exploit code (if possible) Impact of the issue, including how an attacker might exploit the issue This information will help us triage your report more quickly\nFurther details may be found here: https://github.com/open-component-model/ocm/security/policy\nAdvisories Advisories will be published directly on the affected repositories, e.g:\nhttps://github.com/open-component-model/ocm/security/advisories https://github.com/open-component-model/ocm-controller/security/advisories https://github.com/open-component-model/vscode-ocm-tools/security/advisories ","date":"2022-08-12","id":44,"permalink":"/docs/contribution/security-guideline/","summary":"\u003ch2 id=\"report-a-vulnerability\"\u003eReport a Vulnerability\u003c/h2\u003e\n\u003cdiv class=\"callout callout-note d-flex flex-row mt-4 mb-4 pt-4 pe-4 pb-2 ps-3\"\u003e\r\n \r\n \u003cdiv class=\"callout-content\"\u003e\r\n \r\n \u003cdiv class=\"callout-body\"\u003e\r\n \u003cp\u003ePlease do not report security vulnerabilities through public GitHub issues!\u003c/p\u003e","tags":[],"title":"Security Guideline"},{"content":"This tutorial shows you how to bootstrap MPAS to a Kubernetes cluster and deploy a simple application.\nPrerequisites A Kubernetes cluster A GitHub access token with repo scope kubectl Objectives Bootstrap MPAS to a Kubernetes cluster Deploy a simple application Install the MPAS CLI The MPAS CLI is the primary tool for interacting with MPAS. It can be used to bootstrap MPAS to a Kubernetes cluster.\nTo install the MPAS CLI using brew:\nbrew install open-component-model/tap/mpas\rFor other installation methods, see the installation guide.\nBootstrap MPAS Export your GitHub access token The MPAS CLI uses your GitHub access token to authenticate with GitHub. To create a GitHub access token, see the GitHub documentation. In addition to that we need to export your GitHub user and an your email address as they are used later.\nexport GITHUB_TOKEN=\u0026lt;your-github-access-token\u0026gt; export GITHUB_USER=\u0026lt;your-username\u0026gt; export MY_EMAIL=\u0026lt;your-email-address\u0026gt;\rBootstrap To bootstrap MPAS to your Kubernetes cluster, run the following command. If nothing is specified it will use the KUBECONFIG specified in the user\u0026rsquo;s environment. It is also possible to specify a dedicated config using the \u0026ndash;kubeconfig option.\nmpas bootstrap github \\ --owner=$GITHUB_USER \\ --repository=mpas-bootstrap \\ --path=./clusters/my-cluster \\ --personal\rThis command will create a new Github repository called mpas-bootstrap and bootstrap MPAS to your Kubernetes cluster. The following components will be installed:\nFlux: A Kubernetes operator that will install and manage the other components. ocm-controller: A Kubernetes controller that enables the automated deployment of software components using the Open Component Model and Flux. git-controller: A Kubernetes controller that will create pull requests in the target Github repository when changes are made to the cluster. replication-controller: A Kubernetes controller that keeps keep component versions in the cluster up-to-date with a version defined by the consumer in the ComponentSubscription resource. mpas-product-controller: A Kubernetes controller, responsible for creating a product. Reconciles the Product resource. mpas-project-controller: A Kubernetes controller responsible for bootstrapping a whole project. Creates relevant access credentials, service accounts, roles and the main GitOps repository and reconciles the Project resource. The output of the bootstrap is similar to the following:\nRunning mpas bootstrap ... ✓ Preparing Management repository mpas-bootstrap ✓ Fetching bootstrap component from ghcr.io/open-component-model/mpas-bootstrap-component ✓ Installing flux with version v2.1.0 ✓ Installing cert-manager with version v1.13.1 ✓ Reconciling infrastructure components ✓ Waiting for cert-manager to be available ✓ Generating external-secrets-operator manifest with version v0.9.6 ✓ Generating git-controller manifest with version v0.9.0 ✓ Generating mpas-product-controller manifest with version v0.6.0 ✓ Generating mpas-project-controller manifest with version v0.5.0 ✓ Generating ocm-controller manifest with version v0.14.1 ✓ Generating replication-controller manifest with version v0.8.0 ✓ Generate certificate manifests ✓ Reconciling infrastructure components ✓ Waiting for components to be ready Bootstrap completed successfully!\rAfter completing the bootstrap process, the target github repository will contain yaml manifests for the components to be installed on the cluster and Flux will apply all of them to get the components installed. Furthermore the installed Flux components will be configured to watch the target github repository for changes in the path ./clusters/my-cluster.\nClone the git repository Clone the mpas-bootstrap repository to your local machine:\ngit clone https://github.com/$GITHUB_USER/mpas-bootstrap cd mpas-bootstrap\rDeploy podinfo application The podinfo application has been packaged as an OCM component and can be retrieved from Github.\nCreate a secret containing your GitHub credentials that will be used by MPAS to create your project repository.\nkubectl create secret generic \\ github-access \\ --from-literal=username=$GITHUB_USER \\ --from-literal=password=$GITHUB_TOKEN \\ -n mpas-system\rCreate a project that will contain the podinfo application.\nLet\u0026rsquo;s create a directory for the project:\nmkdir -p ./clusters/my-cluster/podinfo\rThen, create a project.yaml file in the ./clusters/my-cluster/podinfo directory:\nmpas create project podinfo-application \\ --owner=$GITHUB_USER \\ --provider=github \\ --visibility=public \\ --already-exists-policy=fail \\ --branch=main \\ --secret-ref=github-access \\ --email=$MY_EMAIL \\ --message=xxx \\ --author=mpas-admin \\ --maintainers=$GITHUB_USER \\ --prune \\ --personal \\ --export \u0026gt;\u0026gt; ./clusters/my-cluster/podinfo/project.yaml\rThen, apply the project to the cluster in a GitOps fashion:\ngit add --all \u0026amp;\u0026amp; git commit -m \u0026#34;Add podinfo project\u0026#34; \u0026amp;\u0026amp; git push\rFlux will detect the changes and apply the project to the cluster.\nThis will create a namespace for the project, a serviceaccount, and RBAC in the cluster. It will also create a GitHub repository for the project, and configure Flux to manage the project\u0026rsquo;s resources.\nAdd the needed secrets to the namespace\nFlux is used to deploy all workloads in a GitOps way. Flux needs a secret in the project namespace that will be used to communicate with github:\nkubectl create secret generic \\ github-access \\ --from-literal=username=$GITHUB_USER \\ --from-literal=password=$GITHUB_TOKEN \\ -n mpas-podinfo-application\rNote The credentials should have access to GitHub packages.\nAs part of step 2, a serviceaccount was created for the project. We will use this service account to provide the necessary permissions to pull from the ghcr registry.\nFirst, create a secret containing the credentials for the service account:\nkubectl create secret docker-registry github-registry-key --docker-server=ghcr.io \\ --docker-username=$GITHUB_USER --docker-password=$GITHUB_TOKEN \\ --docker-email=$MY_EMAIL -n mpas-podinfo-application\rThen, patch the service account to use the secret:\nkubectl patch serviceaccount mpas-podinfo-application -p \u0026#39;{\u0026#34;imagePullSecrets\u0026#34;: [{\u0026#34;name\u0026#34;: \u0026#34;github-registry-key\u0026#34;}]}\u0026#39; \\ -n mpas-podinfo-application\rClone the project repository\ngit clone https://github.com/$GITHUB_USER/mpas-podinfo-application cd mpas-podinfo-application\rAdd the podinfo ComponentSubscription\nCreate a file under ./subscriptions/ that will contain the subscription declaration.\nmpas create cs podinfo-subscription \\ --component=ocm.software/mpas/podinfo \\ --semver=\u0026#34;\u0026gt;=v1.0.0\u0026#34; \\ --source-url=ghcr.io/open-component-model/mpas \\ --source-secret-ref=github-access \\ --target-url=ghcr.io/$GITHUB_USER \\ --target-secret-ref=github-access \\ --namespace=mpas-podinfo-application \\ --export \u0026gt;\u0026gt; ./subscriptions/podinfo.yaml\rThen, apply the ComponentSubscription to the project in a GitOps fashion:\ngit add --all \u0026amp;\u0026amp; git commit -m \u0026#34;Add podinfo subscription\u0026#34; \u0026amp;\u0026amp; git push\rFlux will detect the changes and apply the subscription to the cluster.\nThis will replicate the product referenced by the field spec.component in the ComponentSubscription resource from the defined registry in spec.source.url to the spec.destination.url registry.\nAdd a Target for the podinfo application\nThe target will define where the application will be installed\ncat \u0026lt;\u0026lt;EOF \u0026gt;\u0026gt; ./targets/podinfo.yaml apiVersion: mpas.ocm.software/v1alpha1 kind: Target metadata: name: podinfo-kubernetes-target namespace: mpas-podinfo-application labels: target.mpas.ocm.software/ingress-enabled: \u0026#34;true\u0026#34; # This label is defined by the component that will use it to select an appropriate target to deploy to. spec: type: kubernetes access: targetNamespace: podinfo serviceAccountName: podinfo-sa selector: matchLabels: mpas.ocm.software/target-selector: podinfo-kubernetes-target interval: 5m0s EOF\rThen, apply the Target to the project in a GitOps fashion:\ngit add --all \u0026amp;\u0026amp; git commit -m \u0026#34;Add a target for podinfo\u0026#34; \u0026amp;\u0026amp; git push\rFlux will detect the changes and apply the target to the cluster.\nIn order for the Target to reach a Ready state, the needed secrets should be created in the podinfo namespace.\nFirst, create a secret containing the credentials for the service account:\nkubectl create secret docker-registry github-registry-key --docker-server=ghcr.io \\ --docker-username=$GITHUB_USER --docker-password=$GITHUB_TOKEN \\ --docker-email=$MY_EMAIL -n podinfo\rThen, add a label to allow the target to select it using the label selector:\nkubectl label secret github-registry-key mpas.ocm.software/target-selector=podinfo-kubernetes-target -n podinfo\rDeploy the podinfo application\nIn order to deploy the podinfo application, we need to create a ProductDeploymentGenerator resource:\nmpas create pdg podinfo \\ --service-account=mpas-podinfo-application \\ --subscription-name=podinfo-subscription \\ --subscription-namespace=mpas-podinfo-application \\ --namespace=mpas-podinfo-application \\ --export \u0026gt;\u0026gt; ./generators/podinfo.yaml\rThen, apply the ProductDeploymentGenerator to the project in a GitOps fashion:\ngit add --all \u0026amp;\u0026amp; git commit -m \u0026#34;Add podinfo deployment generator\u0026#34; \u0026amp;\u0026amp; git push\rFlux will detect the changes and apply the resource to the cluster.\nThis will create a pull request in the project repository with the ProductDeployment resource that will deploy the podinfo application.\nGo to the project repository and retrieve the pull request. It should contain a ProductDeployment declaration that provides the configuration and all steps needed to deploy the product, as well as a values.yaml file. The values file contains values that should be used to configure the different resources that are part of the product to be deployed. There is a check that should pass before merging the pull request.\nOnce the pull request is merged, Flux will detect the changes and deploy the application to the cluster.\nAfter a moment the ProductDeployment should be deployed successfully. It is possible to verify this with the command:\nk describe productdeployment -n mpas-podinfo-application\rThe result should look something like:\nName: podinfo Namespace: mpas-podinfo-application Labels: kustomize.toolkit.fluxcd.io/name=mpas-podinfo-application-products kustomize.toolkit.fluxcd.io/namespace=mpas-system API Version: mpas.ocm.software/v1alpha1 Kind: ProductDeployment Metadata: ... Status: Conditions: Last Transition Time: 2023-09-14T10:14:41Z Message: Reconciliation success Observed Generation: 1 Reason: Succeeded Status: True Type: Ready Observed Generation: 1\rThe application is deployed in the podinfo namespace.\n","date":"2023-09-12","id":45,"permalink":"/mpas/getting_started/","summary":"\u003cp\u003eThis tutorial shows you how to bootstrap MPAS to a Kubernetes cluster and deploy\na simple application.\u003c/p\u003e\n\u003ch2 id=\"prerequisites\"\u003ePrerequisites\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eA Kubernetes cluster\u003c/li\u003e\n\u003cli\u003eA GitHub access token with \u003ccode\u003erepo\u003c/code\u003e scope\u003c/li\u003e\n\u003cli\u003ekubectl\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"objectives\"\u003eObjectives\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eBootstrap MPAS to a Kubernetes cluster\u003c/li\u003e\n\u003cli\u003eDeploy a simple application\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"install-the-mpas-cli\"\u003eInstall the MPAS CLI\u003c/h2\u003e\n\u003cp\u003eThe MPAS CLI is the primary tool for interacting with MPAS. It can be used to\nbootstrap MPAS to a Kubernetes cluster.\u003c/p\u003e","tags":[],"title":"Get Started with MPAS"},{"content":"Install using Binaries To install the MPAS CLI, you can download the binaries for major platforms from the GitHub releases page.\nHomebrew You can also install via homebrew for macOS and Linux:\nbrew install open-component-model/tap/mpas\rBash To install with bash for macOS or Linux execute the following command:\ncurl -sfL https://raw.githubusercontent.com/open-component-model/mpas/main/install.sh | sh -\r","date":"2023-09-12","id":46,"permalink":"/mpas/installation/","summary":"\u003ch2 id=\"install-using-binaries\"\u003eInstall using Binaries\u003c/h2\u003e\n\u003cp\u003eTo install the MPAS CLI, you can download the binaries for major platforms from the GitHub \u003ca href=\"https://github.com/open-component-model/mpas/releases\"\u003ereleases page\u003c/a\u003e.\u003c/p\u003e","tags":[],"title":"Installation"},{"content":"This section describes the core concepts of MPAS and what Kubernetes controllers and custom resources are contained. To learn more about the MPAS architecture, see Architecture.\nProduct A Product is a package of software that can be deployed to target environments such as Kubernetes clusters, virtual machines or bare-metal devices.\nProducts are made available to the MPAS system as OCM Components via a Subscription. Multiple instances of a Product may be installed that refer to the same Subscription.\nA ProductDeployment is a Kubernetes Custom Resource that represents a product to be deployed to a target. The ProductDeployment is reconciled by the MPAS Product Controller which will generate the necessary Kubernetes resources to deploy the product to the cluster.\nA ProductDeploymentGenerator is a Kubernetes Custom Resource that represents a ProductDeployment to be deployed to a Kubernetes cluster. The ProductDeploymentGenerator is reconciled by the MPAS Product Controller in order to generate the ProductDeployment resource.\nA ProductDescription is a manifest that describes a product. It specifies the set of resources that are needed to deploy the product in a form of pipeline steps. The ProductDescription is retrieved by the MPAS Product Controller in order to generate the ProductDeployment resource during a ProductDeploymentGenerator reconciliation.\nA ProductDeploymentPipeline is a Kubernetes Custom Resource that defines a resource that needs to be deployed as part of the ProductDeployment. The ProductDeploymentPipeline is reconciled by the MPAS Product Controller as part of the ProductDeployment deployment.\nProject A Project is a Kubernetes Custom Resource that is used to manage the lifecycle of a MPAS project. A Project is reconciled by the MPAS Project Controller which will generate a project namespace and a git repository for the project containing the project folder structure. The controller will also generate the necessary Flux kustomization resources in the mpas-system namespace in order to update the cluster with the project resources from the git repository. All items that the MPAS Project Controller created during reconcile, are visible in the status subresource of a Project CR.\nThe project git repository is designed to be used as a GitOps repository for the project. It contains all the product custom resources in order to be deployed to the cluster.\nSubscription The purpose of a Subscription is to replicate OCM components containing a particular product from a delivery registry into a target registry in the MPAS customer\u0026rsquo;s environment.\nA ComponentSubscription is a Kubernetes Custom Resource that represents a subscription to a component. The ComponentSubscription is reconciled by the Replication Controller which will transfer the OCM component into the target registry using the OCM library.\nTarget A Target is a Kubernetes Custom Resource that represents a target environment where a Product should be deployed. The MPAS Product Controller controller reconciles the Target and creates any necessary prerequisite that needs to exist in the target environment, e.g. a namespace and a service account.\n","date":"2023-09-12","id":47,"permalink":"/mpas/core_concepts/","summary":"\u003cp\u003eThis section describes the core concepts of \u003ccode\u003eMPAS\u003c/code\u003e and what Kubernetes controllers and custom resources are contained.\nTo learn more about the \u003ccode\u003eMPAS\u003c/code\u003e architecture,\nsee \u003ca href=\"https://github.com/open-component-model/MPAS/tree/main/docs/concepts\"\u003eArchitecture\u003c/a\u003e.\u003c/p\u003e","tags":[],"title":"Core Concepts"},{"content":"The mpas bootstrap command deploys the following components to your cluster:\nFlux: A Kubernetes operator that will install and manage the other components. ocm-controller: A Kubernetes controller that enables the automated deployment of software using the Open Component Model and Flux. git-controller: A Kubernetes controller that will create pull requests in the target Github repository when changes are made to the cluster. replication-controller: A Kubernetes controller that replicates everything defined and bundled in an OCM component version (and that the consumer subscribed to) into the local OCI registry of the cluster. mpas-product-controller: A Kubernetes controller responsible for creating the custom resource Product. mpas-project-controller: A Kubernetes controller responsible for bootstrapping a whole project and creating relevant access credentials, service accounts, roles and the main repository. It reconciles the Project resource. Besides the above components, the mpas bootstrap command will also push the corresponding component manifests to the target Git repository and configure Flux to continuously update the installed components from the target Git repository.\nAfter the mpas bootstrap command is executed, the cluster is ready to deploy software in a GitOps fashion using the Open Component Model and MPAS.\nCluster Admin Rights\nTo bootstrap MPAS, the person running the command must have cluster admin rights for the target Kubernetes cluster. It is also required that the person running the command to be the owner of the GitHub repository, or to have admin rights of a GitHub organization.\nBootstrap for GitHub GitHub Personal Access Token (PAT) For accessing the GitHub API, the boostrap command requires a GitHub personal access token (PAT) with administration permissions.\nThe GitHub PAT can be exported as environment variable:\nexport GITHUB_TOKEN=\u0026lt;your-github-pat\u0026gt;\rIf the GITHUB_TOKEN environment variable is not set, the mpas bootstrap command will prompt for the GitHub PAT.\nToken in Secret\nNote that the GitHub PAT is stored in the cluster as a Kubernetes Secret named flux-system inside the flux-system namespace.\nPersonal account Run the bootstrap for a repository on your personal GitHub account:\nmpas bootstrap github \\ --owner=\u0026lt;your-github-username\u0026gt; \\ --repository=\u0026lt;your-github-repository\u0026gt; \\ --path=clusters/my-cluster \\ --dev \\ --personal\rIf the specified repository does not exist, the mpas bootstrap command will create it as a private repository. If you wish to create a public repository, you can use the --private=false flag.\nOrganization If you want to bootstrap MPAS for a repository owned by an GitHub organization, it is recommended to create a dedicated GitHub user for MPAS and use that user to bootstrap the repository.\nRun the bootstrap for a repository owned by a GitHub organization:\nmpas bootstrap github \\ --owner=\u0026lt;your-github-organization\u0026gt; \\ --repository=\u0026lt;your-github-repository\u0026gt; \\ --path=clusters/my-cluster \\ --dev\rBootstrap for Gitea Gitea API token For accessing the Gitea API, the boostrap command requires a Gitea API token with administration permissions.\nThe Gitea API Token can be exported as an environment variable:\nexport GITEA_TOKEN=\u0026lt;your-gitea-api-token\u0026gt;\rIf the GITEA_TOKEN environment variable is not set, the mpas bootstrap command will prompt for the Gitea API token.\nToken in Secret\nNote that the Gitea API Token is stored in the cluster as a Kubernetes Secret named flux-system inside the flux-system namespace.\nPersonal account Run bootstrap for a repository on your personal Gitea account:\nmpas bootstrap gitea \\ --owner=\u0026lt;your-gite -username\u0026gt; \\ --repository=\u0026lt;your-gitea-repository\u0026gt; \\ --path=clusters/my-cluster \\ --dev \\ --personal\rIf the specified repository does not exist, the mpas bootstrap command will create it as a private repository. If you wish to create a public repository, you can use the --private=false flag.\nOrganization If you want to bootstrap MPAS for a repository owned by an Gitea organization, it is recommended to create a dedicated Gitea user for MPAS and use that user to bootstrap the repository.\nRun the bootstrap for a repository owned by a Gitea organization:\nmpas bootstrap gitea \\ --owner=\u0026lt;your-gitea-organization\u0026gt; \\ --repository=\u0026lt;your-gitea-repository\u0026gt; \\ --path=clusters/my-cluster \\ --dev\rBootstrap for an air-gapped environment If you want to bootstrap MPAS for a repository in an air-gapped environment, only Gitea is supported at the moment.\nExport the bootstrap components bundle To bootstrap MPAS in an air-gapped environment, you need to export the bootstrap components bundle from the MPAS default registry.\nmpas bootstrap \\ --export \\ --export-path=/tmp\rThe above command will export the bootstrap components archive to /tmp/mpas-bundle.tar.gz.\nIt is then possible to import the bootstrap components bundle into an air-gapped environment registry and use it to bootstrap MPAS for a repository in that environment.\nmpas bootstrap gitea \\ --owner=\u0026lt;your-gitea-organization\u0026gt; \\ --repository=\u0026lt;your-gitea-repository\u0026gt; \\ --from-file=/tmp/mpas-bundle.tar.gz \\ --registry=\u0026lt;your-air-gapped-registry\u0026gt; \\ --path=clusters/my-cluster \\ --dev\rThe above command will copy the bootstrap components from the bundle archive to the specified air-gapped registry and bootstrap MPAS for the specified repository.\n","date":"2023-09-12","id":48,"permalink":"/mpas/bootstrap/","summary":"\u003cp\u003eThe \u003ccode\u003empas bootstrap\u003c/code\u003e command deploys the following components to your cluster:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://fluxcd.io/docs/components/\"\u003eFlux\u003c/a\u003e: A Kubernetes operator that will\ninstall and manage the other components.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/open-component-model/ocm-controller\"\u003eocm-controller\u003c/a\u003e: A Kubernetes controller\nthat enables the automated deployment of software using the Open Component Model and \u003ccode\u003eFlux\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/open-component-model/git-controller\"\u003egit-controller\u003c/a\u003e: A\nKubernetes controller that will create pull requests in the target Github repository\nwhen changes are made to the cluster.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/open-component-model/git-controller\"\u003ereplication-controller\u003c/a\u003e: A Kubernetes controller that replicates\neverything defined and bundled in an OCM component version (and that the consumer subscribed to)\ninto the local OCI registry of the cluster.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/open-component-model/mpas-product-controller\"\u003empas-product-controller\u003c/a\u003e: A Kubernetes controller responsible\nfor creating the custom resource \u003ccode\u003eProduct\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/open-component-model/mpas-project-controller\"\u003empas-project-controller\u003c/a\u003e: A Kubernetes controller responsible\nfor bootstrapping a whole project and creating relevant access credentials, service accounts, roles and the main repository.\nIt reconciles the \u003ccode\u003eProject\u003c/code\u003e resource.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eBesides the above components, the \u003ccode\u003empas bootstrap\u003c/code\u003e command will also push the corresponding\ncomponent manifests to the target Git repository and configure \u003ccode\u003eFlux\u003c/code\u003e to continuously update\nthe installed components from the target Git repository.\u003c/p\u003e","tags":[],"title":"Bootstrap"},{"content":"Demo of MPAS\n","date":"2024-04-02","id":49,"permalink":"/mpas/demo_of_mpas/","summary":"\u003cp\u003e\u003ca href=\"https://sapvideoa35699dc5.hana.ondemand.com/?entry_id=1_2u4p4u7z\"\u003eDemo of MPAS\u003c/a\u003e\u003c/p\u003e","tags":[],"title":"MPAS Demo Video"},{"content":"Overview The OCM command line client can be configured by supplying it with a configuration file. By default, the CLI looks for configuration in $HOME/.ocmconfig, if it exists.\nThe configuration file can be used in particular to specify the credentials, which are required for the CLI to be able to access the artifact repositories referenced in CLI commands.\nExamples This page contains basic examples of credentials configuration for a few most common artifact repository types. The examples below are complete .ocmconfig files, not snippets.\nFor comprehensive documentation on the credentials topic, including usage of certificates or HashiCorp Vault, execute the command ocm credential-handling.\nRepositories and Consumers In the examples below, some configuration is located under configurations[0].repositories, and some other under configurations[0].consumers. This chapter explains the difference between repositories and consumers, which is potentially not as obvious as one could think.\nIn this context, repository is a place where credentials can be stored, i.e., it is a credentials repository. For example, Docker\u0026rsquo;s config.json can store multiple credentials, and in that sense the file serves as a repository that can store and provide credentials. That is why its location is configured under repositories. Other examples of credentials repositories can be the NPM\u0026rsquo;s .npmrc file or a HashiCorp Vault instance.\nA consumer is something the credentials are required for. For example, if you need to configure credentials that are required to log in to an OCI registry, one could say that the registry will be consuming these credentials, i.e., the registry is a credentials consumer. That is why it is configured under consumers.\nReuse Credentials Configured for Docker This .ocmconfig file will tell the OCM CLI to use credentials configuration from Docker\u0026rsquo;s config.json file.\ntype: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software repositories: - repository: type: DockerConfig/v1 dockerConfigFile: \u0026#34;~/.docker/config.json\u0026#34;\rReuse Credentials Configured for npm This .ocmconfig file will tell OCM CLI to use credentials configuration from npm\u0026rsquo;s .npmrc file.\ntype: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software repositories: - repository: type: NPMConfig/v1 npmrcFile: \u0026#39;~/.npmrc\u0026#39;\rAccessing OCI Registries HTTPS and Path To access artifacts in https://ghcr.io/open-component-model:\nThe different parts of the URL have to be specified in separate fields: scheme, hostname, and pathprefix The fields scheme and pathprefix are optional. If not specified, the OCM CLI will use the credentials for all schemes and paths on that host The password is the user\u0026rsquo;s basic authentication password. Some OCI registries allow to generate user access tokens, which can also be used for basic authentication type: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software consumers: - identity: type: OCIRegistry scheme: https hostname: ghcr.io pathprefix: open-component-model credentials: - type: Credentials properties: username: some-user password: some-token\rHTTP, Port Number, Empty Path To access artifacts in http://127.0.0.1:5001:\nThe fields scheme and port are optional. If not specified, the OCM CLI will use the credentials for all schemes and ports on that host As the URL has no path behind the port number, the pathprefix element can be removed type: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software consumers: - identity: type: OCIRegistry scheme: http hostname: 127.0.0.1 port: 5001 credentials: - type: Credentials properties: username: admin password: admin\rAccessing Helm Chart Repositories Similar to OCI registries, but uses HelmChartRepository as identity type.\ntype: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software consumers: - identity: type: HelmChartRepository hostname: ghcr.io pathprefix: open-component-model credentials: - type: Credentials properties: username: some-user password: some-token\rAccessing Maven Repositories Similar to OCI registries, but uses MavenRepository as identity type.\ntype: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software consumers: - identity: type: MavenRepository hostname: maven.repo.host pathprefix: path/to/repo credentials: - type: Credentials properties: username: some-user password: some-password\rAccessing npm Registries Similar to OCI registries, but uses NpmRegistry as identity type. In addition, it is required to specify the email address matching with the one in the user record in the npm registry.\ntype: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software consumers: - identity: type: NpmRegistry hostname: npm.registry.host pathprefix: path/to/registry credentials: - type: Credentials properties: username: some-user password: some-password email: foo.bar@acme.org\rAccessing GitHub Repositories To access code in https://my.github.enterprise/my-org/my-repo:\nUse Github as identity type hostname is the domain name of the GitHub instance pathprefix is a combination of organization and repository names token is a personal access token generated in GitHub Developer Settings type: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software consumers: - identity: type: Github hostname: my.github.enterprise pathprefix: my-org/my-repo credentials: - type: Credentials properties: token: ghp_my_personal_access_token\rAccessing Several Systems It is, of course, possible to configure credentials for several systems in the same .ocmconfig file. To do that, you can combine as many repositories and consumers as you need.\nThe example below instructs OCM CLI to look for credentials in Docker\u0026rsquo;s config.json, and in addition specifies dedicated credentials for an OCI registry and a GitHub repository.\ntype: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software repositories: - repository: type: DockerConfig/v1 dockerConfigFile: \u0026#34;~/.docker/config.json\u0026#34; propagateConsumerIdentity: true consumers: - identity: type: OCIRegistry hostname: ghcr.io pathprefix: open-component-model credentials: - type: Credentials properties: username: some-user password: some-token - identity: type: Github hostname: my.github.enterprise pathprefix: my-org/my-repo credentials: - type: Credentials properties: token: ghp_my_personal_access_token\r","date":"2024-09-04","id":50,"permalink":"/docs/examples/credentials-in-an-.ocmconfig-file/","summary":"\u003ch2 id=\"overview\"\u003eOverview\u003c/h2\u003e\n\u003cp\u003eThe \u003ca href=\"https://github.com/open-component-model/ocm/blob/main/docs/reference/ocm.md\"\u003eOCM command line client\u003c/a\u003e can be configured by supplying it with a \u003ca href=\"https://github.com/open-component-model/ocm/blob/main/docs/reference/ocm_configfile.md\"\u003econfiguration file\u003c/a\u003e. By default, the CLI looks for configuration in \u003ccode\u003e$HOME/.ocmconfig\u003c/code\u003e, if it exists.\u003c/p\u003e","tags":[],"title":"Credentials in an .ocmconfig file"},{"content":"","date":"2024-09-04","id":51,"permalink":"/docs/","summary":"","tags":[],"title":"Docs"},{"content":"","date":"2024-04-02","id":52,"permalink":"/mpas/","summary":"","tags":[],"title":"Mpas"},{"content":"","date":"2020-10-06","id":53,"permalink":"/","summary":"","tags":[],"title":"Open Component Model"},{"content":"Usage ocm add [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for add\rSee Also Sub Commands ocm add componentversions\t— add component version(s) to a (new) transport archive ocm add references\t— add aggregation information to a component version ocm add resource-configuration\t— add a resource specification to a resource config file ocm add resources\t— add resources to a component version ocm add routingslips\t— add routing slip entry ocm add source-configuration\t— add a source specification to a source config file ocm add sources\t— add source information to a component version ","date":"0001-01-01","id":54,"permalink":"/docs/cli-reference/add/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm add [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for add\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/add/componentversions/\"\u003eocm add \u003cb\u003ecomponentversions\u003c/b\u003e\u003c/a\u003e\t — add component version(s) to a (new) transport archive\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/add/references/\"\u003eocm add \u003cb\u003ereferences\u003c/b\u003e\u003c/a\u003e\t — add aggregation information to a component version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/add/resource-configuration/\"\u003eocm add \u003cb\u003eresource-configuration\u003c/b\u003e\u003c/a\u003e\t — add a resource specification to a resource config file\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/add/resources/\"\u003eocm add \u003cb\u003eresources\u003c/b\u003e\u003c/a\u003e\t — add resources to a component version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/add/routingslips/\"\u003eocm add \u003cb\u003eroutingslips\u003c/b\u003e\u003c/a\u003e\t — add routing slip entry\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/add/source-configuration/\"\u003eocm add \u003cb\u003esource-configuration\u003c/b\u003e\u003c/a\u003e\t — add a source specification to a source config file\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/add/sources/\"\u003eocm add \u003cb\u003esources\u003c/b\u003e\u003c/a\u003e\t — add source information to a component version\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"add"},{"content":"Usage ocm describe artifacts [\u0026lt;options\u0026gt;] {\u0026lt;artifact-reference\u0026gt;}\rOptions -h, --help help for artifacts --layerfiles list layer files -o, --output string output mode (JSON, json, yaml) --repo string repository name or spec\rDescription Describe lists all artifact versions specified, if only a repository is specified all tagged artifacts are listed. Per version a detailed, potentially recursive description is printed.\nIf the repository/registry option is specified, the given names are interpreted relative to the specified registry using the syntax\n\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as extended OCI artifact references.\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e]/\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] The \u0026ndash;repo option takes a repository/OCI registry specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz are possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nArtifactSet: v1 CommonTransportFormat: v1 DockerDaemon: v1 Empty: v1 OCIRegistry: v1 oci: v1 ociRegistry With the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json yaml Examples $ ocm describe artifact ghcr.io/open-component-model/ocm/component-descriptors/ocm.software/ocmcli:0.17.0 $ ocm describe artifact ghcr.io/open-component-model/ocm/ocm.software/ocmcli/ocmcli-image:0.17.0\rSee Also ocm describe\t— Describe various elements by using appropriate sub commands. ","date":"0001-01-01","id":55,"permalink":"/docs/cli-reference/describe/artifacts/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm describe artifacts [\u0026lt;options\u0026gt;] {\u0026lt;artifact-reference\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for artifacts\n --layerfiles list layer files\n -o, --output string output mode (JSON, json, yaml)\n --repo string repository name or spec\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eDescribe lists all artifact versions specified, if only a repository is specified\nall tagged artifacts are listed.\nPer version a detailed, potentially recursive description is printed.\u003c/p\u003e","tags":[],"title":"artifacts"},{"content":"Usage ocm download artifacts [\u0026lt;options\u0026gt;] {\u0026lt;artifact\u0026gt;} Options --dirtree extract as effective filesystem content -h, --help help for artifacts --layers ints extract dedicated layers -O, --outfile string output file or directory --repo string repository name or spec -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\rDescription Download artifacts from an OCI registry. The result is stored in artifact set format, without the repository part\nThe files are named according to the artifact repository name.\nIf the repository/registry option is specified, the given names are interpreted relative to the specified registry using the syntax\n\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as extended OCI artifact references.\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e]/\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] The \u0026ndash;repo option takes a repository/OCI registry specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz are possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nArtifactSet: v1 CommonTransportFormat: v1 DockerDaemon: v1 Empty: v1 OCIRegistry: v1 oci: v1 ociRegistry With option \u0026ndash;layers it is possible to request the download of dedicated layers, only. Option \u0026ndash;dirtree expects the artifact to be a layered filesystem (for example OCI Image) and provided the effective filesystem content.\nThe \u0026ndash;type option accepts a file format for the target archive to use. It is only evaluated if the target archive does not exist yet. The following formats are supported:\ndirectory tar tgz The default format is directory.\nSee Also ocm download\t— Download oci artifacts, resources or complete components ","date":"0001-01-01","id":56,"permalink":"/docs/cli-reference/download/artifacts/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm download artifacts [\u0026lt;options\u0026gt;] {\u0026lt;artifact\u0026gt;} \u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --dirtree extract as effective filesystem content\n -h, --help help for artifacts\n --layers ints extract dedicated layers\n -O, --outfile string output file or directory\n --repo string repository name or spec\n -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eDownload artifacts from an OCI registry. The result is stored in\nartifact set format, without the repository part\u003c/p\u003e","tags":[],"title":"artifacts"},{"content":"Usage ocm get artifacts [\u0026lt;options\u0026gt;] {\u0026lt;artifact-reference\u0026gt;}\rOptions -a, --attached show attached artifacts -h, --help help for artifacts -o, --output string output mode (JSON, json, tree, wide, yaml) -r, --recursive follow index nesting --repo string repository name or spec -s, --sort stringArray sort fields\rDescription Get lists all artifact versions specified, if only a repository is specified all tagged artifacts are listed.\nIf the repository/registry option is specified, the given names are interpreted relative to the specified registry using the syntax\n\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as extended OCI artifact references.\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e]/\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] The \u0026ndash;repo option takes a repository/OCI registry specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz are possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nArtifactSet: v1 CommonTransportFormat: v1 DockerDaemon: v1 Empty: v1 OCIRegistry: v1 oci: v1 ociRegistry With the option \u0026ndash;recursive the complete reference tree of a index is traversed.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json tree wide yaml Examples $ ocm get artifact ghcr.io/open-component-model/ocm/component-descriptors/ocm.software/ocmcli $ ocm get artifact ghcr.io/open-component-model/ocm/ocm.software/ocmcli/ocmcli-image:0.17.0\rSee Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":57,"permalink":"/docs/cli-reference/get/artifacts/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get artifacts [\u0026lt;options\u0026gt;] {\u0026lt;artifact-reference\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -a, --attached show attached artifacts\n -h, --help help for artifacts\n -o, --output string output mode (JSON, json, tree, wide, yaml)\n -r, --recursive follow index nesting\n --repo string repository name or spec\n -s, --sort stringArray sort fields\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eGet lists all artifact versions specified, if only a repository is specified\nall tagged artifacts are listed.\u003c/p\u003e","tags":[],"title":"artifacts"},{"content":"Usage ocm transfer artifacts [\u0026lt;options\u0026gt;] {\u0026lt;artifact-reference\u0026gt;} \u0026lt;target\u0026gt;\rOptions -h, --help help for artifacts --repo string repository name or spec -R, --repo-name transfer repository name\rDescription Transfer OCI artifacts from one registry to another one. Several transfer scenarios are supported:\ncopy a set of artifacts (for the same repository) into another registry copy a set of artifacts (for the same repository) into another repository copy artifacts from multiple repositories into another registry copy artifacts from multiple repositories into another registry with a given repository prefix (option -R) By default, the target is seen as a single repository if a repository is specified. If a complete registry is specified as target, option -R is implied, but the source must provide a repository. THis combination does not allow an artifact set as source, which specifies no repository for the artifacts.\nSources may be specified as\ndedicated artifacts with repository and version or tag repository (without version), which is resolved to all available tags registry, if the specified registry implementation supports a namespace/repository lister, which is not the case for registries conforming to the OCI distribution specification. Note that there is an indirection of \u0026ldquo;ocm oci artifact\u0026rdquo; to \u0026ldquo;ocm transfer artifact\u0026rdquo; out of convenience.\nIf the repository/registry option is specified, the given names are interpreted relative to the specified registry using the syntax\n\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as extended OCI artifact references.\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e]/\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] The \u0026ndash;repo option takes a repository/OCI registry specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz are possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nArtifactSet: v1 CommonTransportFormat: v1 DockerDaemon: v1 Empty: v1 OCIRegistry: v1 oci: v1 ociRegistry Examples # Simple: $ ocm transfer artifact ghcr.io/open-component-model/ocm/ocm.software/ocmcli/ocmcli-image:0.17.0 ghcr.io/MY_USER/ocmcli:0.17.0 $ ocm transfer artifact ghcr.io/open-component-model/ocm/ocm.software/ocmcli/ocmcli-image ghcr.io/MY_USER/ocmcli $ ocm transfer artifact ghcr.io/open-component-model/ocm/ocm.software/ocmcli/ocmcli-image gcr.io $ ocm transfer artifact transfer /tmp/ctf ghcr.io/MY_USER/ocmcli # Equivalent to ocm transfer artifact: $ ocm oci artifact transfer # Complex: # Transfer an artifact from a CTF into an OCI Repository: # 1. Get the link to all artifacts in the CTF with \u0026#34;ocm get artifact $PATH_TO_CTF\u0026#34;, $ ocm get artifact $PATH_TO_CTF REGISTRY REPOSITORY CommonTransportFormat::$PATH_TO_CTF/ component-descriptors/ocm.software/ocmcli # 2. Then use any combination to form an artifact reference: $ ocm transfer artifact CommonTransportFormat::$PATH_TO_CTF//component-descriptors/ocm.software/ocmcli ghcr.io/open-component-model/ocm:latest\rSee Also ocm transfer\t— Transfer artifacts or components ","date":"0001-01-01","id":58,"permalink":"/docs/cli-reference/transfer/artifacts/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm transfer artifacts [\u0026lt;options\u0026gt;] {\u0026lt;artifact-reference\u0026gt;} \u0026lt;target\u0026gt;\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for artifacts\n --repo string repository name or spec\n -R, --repo-name transfer repository name\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eTransfer OCI artifacts from one registry to another one.\nSeveral transfer scenarios are supported:\u003c/p\u003e","tags":[],"title":"artifacts"},{"content":"Description The OCM library supports a set of attributes, which can be used to influence the behaviour of various functions. The CLI also supports setting of those attributes using the config file (see ocm configfile) or by command line options of the main command (see ocm).\nThe following options are available in the currently used version of the OCM library:\ngithub.com/mandelsoft/logforward [logfwd]: logconfig Logging config structure used for config forwarding\nThis attribute is used to specify a logging configuration intended to be forwarded to other tools. (For example: TOI passes this config to the executor)\ngithub.com/mandelsoft/oci/cache [cache]: string\nFilesystem folder to use for caching OCI blobs\ngithub.com/mandelsoft/ocm/compat [compat]: bool\nCompatibility mode: Avoid generic local access methods and prefer type specific ones.\ngithub.com/mandelsoft/ocm/hasher: JSON\nPreferred hash algorithm to calculate resource digests. The following digesters are supported:\nNO-DIGEST SHA-256 (default) SHA-512 github.com/mandelsoft/ocm/keeplocalblob [keeplocalblob]: bool\nKeep local blobs when importing OCI artifacts to OCI registries from localBlob access methods. By default, they will be expanded to OCI artifacts with the access method ociRegistry. If this option is set to true, they will be stored as local blobs, also. The access method will still be localBlob but with a nested ociRegistry access method for describing the global access.\ngithub.com/mandelsoft/ocm/mapocirepo [mapocirepo]: bool|YAML\nWhen uploading an OCI artifact blob to an OCI based OCM repository and the artifact is uploaded as OCI artifact, the repository path part is shortened, either by hashing all but the last repository name part or by executing some prefix based name mappings.\nIf a boolean is given the short hash or none mode is enabled. The YAML flavor uses the following fields:\nmode string: hash, shortHash, prefixMapping or none. If unset, no mapping is done. prefixMappings: map[string]string repository path prefix mapping. prefix: string repository prefix to use (replaces potential sub path of OCM repo). or none. prefixMapping: map[string]string repository path prefix mapping. Notes:\nThe mapping only occurs in transfer commands and only when transferring to OCI registries (e.g. when transferring to a CTF archive this option will be ignored). The mapping in mode prefixMapping requires a full prefix of the composed final name. Partial matches are not supported. The host name of the target will be skipped. The artifact name of the component-descriptor is not mapped. If the mapping is provided on the command line it must be JSON format and needs to be properly escaped (see example below). Example:\nAssume a component named github.com/my_org/myexamplewithalongname and a chart name echo in the Charts.yaml of the chart archive. The following input to a resource.yaml creates a component version:\nname: mychart type: helmChart input: type: helm path: charts/mychart.tgz --- name: myimage type: ociImage version: 0.1.0 input: type: ociImage repository: ocm/ocm.software/ocmcli/ocmcli-image path: ghcr.io/acme/ocm/ocm.software/ocmcli/ocmcli-image:0.1.0 The following command:\nocm \"-X mapocirepo={\\\"mode\\\":\\\"mapping\\\",\\\"prefixMappings\\\":{\\\"acme/github.com/my_org/myexamplewithalongname/ocm/ocm.software/ocmcli\\\":\\\"acme/cli\\\", \\\"acme/github.com/my_org/myexamplewithalongnameabc123\\\":\\\"acme/mychart\\\"}}\" transfer ctf -f --copy-resources ./ctf ghcr.io/acme will result in the following artifacts in ghcr.io/my_org:\nmychart/echo cli/ocmcli-image Note that the host name part of the transfer target ghcr.io/acme is excluded from the prefix but the path acme is considered.\nThe same using a config file .ocmconfig:\ntype: generic.config.ocm.software/v1 configurations: ... - type: attributes.config.ocm.software attributes: ... mapocirepo: mode: mapping prefixMappings: acme/github.com/my\\_org/myexamplewithalongname/ocm/ocm.software/ocmcli: acme/cli acme/github.com/my\\_org/myexamplewithalongnameabc123: acme/mychart ocm transfer ca -f --copy-resources ./ca ghcr.io/acme github.com/mandelsoft/ocm/ociuploadrepo [ociuploadrepo]: oci base repository ref\nUpload local OCI artifact blobs to a dedicated repository.\ngithub.com/mandelsoft/ocm/plugindir [plugindir]: plugin directory\nDirectory to look for OCM plugin executables.\ngithub.com/mandelsoft/ocm/rootcerts [rootcerts]: JSON\nGeneral root certificate settings given as JSON document with the following format:\n{ \"rootCertificates\": [ { \"data\": \"\"\u0026lt;base64\u003e\" }, { \"path\": \"\"\u0026lt;file path\u003e\" } ] } One of following data fields are possible:\ndata: base64 encoded binary data stringdata: plain text data path: a file path to read the data from github.com/mandelsoft/ocm/signing: JSON\nPublic and private Key settings given as JSON document with the following format:\n{ \"publicKeys\": [ \"\u0026lt;provider\u003e\": { \"data\": \"\"\u0026lt;base64\u003e\" } ], \"privateKeys\"\": [ \"\u0026lt;provider\u003e\": { \"path\": \"\"\u0026lt;file path\u003e\" } ] } One of following data fields are possible:\ndata: base64 encoded binary data stringdata: plain text data path: a file path to read the data from github.com/mandelsoft/tempblobcache [blobcache]: string Foldername for temporary blob cache\nThe temporary blob cache is used to accessing large blobs from remote systems. The are temporarily stored in the filesystem, instead of the memory, to avoid blowing up the memory consumption.\nocm.software/cliconfig [cliconfig]: cliconfig Configuration Object passed to command line plugin.\nocm.software/compositionmode [compositionmode]: bool (default: false)\nComposition mode decouples a component version provided by a repository implementation from the backend persistence. Added local blobs will and other changes will not be forwarded to the backend repository until an AddVersion is called on the component. If composition mode is disabled blobs will directly be forwarded to the backend and descriptor updated will be persisted on AddVersion or closing a provided existing component version.\nocm.software/signing/sigstore [sigstore]: sigstore config Configuration to use for sigstore based signing.\nThe following fields are used.\nfulcioURL string default is https://fulcio.sigstore.dev rekorURL string default is https://rekor.sigstore.dev OIDCIssuer string default is https://oauth2.sigstore.dev/auth OIDCClientID string default is sigstore See Also ","date":"0001-01-01","id":59,"permalink":"/docs/cli-reference/help/attributes/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eThe OCM library supports a set of attributes, which can be used to influence\nthe behaviour of various functions. The CLI also supports setting of those\nattributes using the config file (see \u003ca href=\"/docs/cli-reference/help/configfile/\"\u003eocm configfile\u003c/a\u003e) or by\ncommand line options of the main command (see \u003ca href=\"/docs/cli-reference/\"\u003eocm\u003c/a\u003e).\u003c/p\u003e","tags":[],"title":"attributes"},{"content":"Usage ocm clean cache [\u0026lt;options\u0026gt;]\rOptions -b, --before string time since last usage -s, --dry-run show size to be removed -h, --help help for cache\rDescription Cleanup all blobs stored in oci blob cache (if given).\nExamples $ ocm clean cache\rSee Also ocm clean\t— Cleanup/re-organize elements ","date":"0001-01-01","id":60,"permalink":"/docs/cli-reference/clean/cache/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm clean cache [\u0026lt;options\u0026gt;]\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -b, --before string time since last usage\n -s, --dry-run show size to be removed\n -h, --help help for cache\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eCleanup all blobs stored in oci blob cache (if given).\u003c/p\u003e","tags":[],"title":"cache"},{"content":"Usage ocm describe cache [\u0026lt;options\u0026gt;]\rOptions -h, --help help for cache\rDescription Show details about the OCI blob cache (if given).\nExamples $ ocm cache info\rSee Also ocm describe\t— Describe various elements by using appropriate sub commands. ","date":"0001-01-01","id":61,"permalink":"/docs/cli-reference/describe/cache/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm describe cache [\u0026lt;options\u0026gt;]\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for cache\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eShow details about the OCI blob cache (if given).\u003c/p\u003e","tags":[],"title":"cache"},{"content":"","date":"0001-01-01","id":62,"permalink":"/categories/","summary":"","tags":[],"title":"Categories"},{"content":"Usage ocm check [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for check\rSee Also Sub Commands ocm check componentversions\t— Check completeness of a component version in an OCM repository ","date":"0001-01-01","id":63,"permalink":"/docs/cli-reference/check/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm check [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for check\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/check/componentversions/\"\u003eocm check \u003cb\u003ecomponentversions\u003c/b\u003e\u003c/a\u003e\t — Check completeness of a component version in an OCM repository\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"check"},{"content":"Usage ocm clean [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for clean\rSee Also Sub Commands ocm clean cache\t— cleanup oci blob cache ","date":"0001-01-01","id":64,"permalink":"/docs/cli-reference/clean/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm clean [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for clean\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/clean/cache/\"\u003eocm clean \u003cb\u003ecache\u003c/b\u003e\u003c/a\u003e\t — cleanup oci blob cache\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"clean"},{"content":"Usage ocm download cli [\u0026lt;options\u0026gt;] [\u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}]\rOptions -c, --constraints constraints version constraint -h, --help help for cli -O, --outfile string output file or directory -p, --path lookup executable in PATH --repo string repository name or spec --use-verified enable verification store --verified string file used to remember verifications for downloads (default \u0026#34;~/.ocm/verified\u0026#34;) --verify verify downloads\rDescription Download an OCM CLI executable. By default, the standard publishing component and repository is used. Optionally, another component or repo and even a resource can be specified. Resources are specified by identities. An identity consists of a name argument followed by optional \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; arguments.\nThe option -O is used to declare the output destination. The default location is the location of the ocm executable in the actual PATH.\nIf the option \u0026ndash;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.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 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 \u0026ndash;download-handlers option. Otherwise the resource as returned by the access method is stored.\nIf the verification store is enabled, resources downloaded from signed or verified component versions are verified against their digests provided by the component version.(not supported for using downloaders for the resource download).\nThe usage of the verification store is enabled by \u0026ndash;use-verified or by specifying a verification file with \u0026ndash;verified.\nSee Also ocm download\t— Download oci artifacts, resources or complete components ","date":"0001-01-01","id":65,"permalink":"/docs/cli-reference/download/cli/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm download cli [\u0026lt;options\u0026gt;] [\u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}]\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -c, --constraints constraints version constraint\n -h, --help help for cli\n -O, --outfile string output file or directory\n -p, --path lookup executable in PATH\n --repo string repository name or spec\n --use-verified enable verification store\n --verified string file used to remember verifications for downloads (default \u0026#34;~/.ocm/verified\u0026#34;)\n --verify verify downloads\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eDownload an OCM CLI executable. By default, the standard publishing component\nand repository is used. Optionally, another component or repo and even a resource\ncan be specified. Resources are specified by identities. An identity consists of\na name argument followed by optional \u003ccode\u003e\u0026lt;key\u0026gt;=\u0026lt;value\u0026gt;\u003c/code\u003e\narguments.\u003c/p\u003e","tags":[],"title":"cli"},{"content":"Options -X, --attribute stringArray attribute setting --ca-cert stringArray additional root certificate authorities (for signing certificates) --config stringArray configuration file --config-set strings apply configuration set -C, --cred stringArray credential setting -h, --help help for ocm -I, --issuer stringArray issuer name or distinguished name (DN) (optionally for dedicated signature) ([\u0026lt;name\u0026gt;:=]\u0026lt;dn\u0026gt;) --logJson log as json instead of human readable logs --logconfig string log config -L, --logfile string set log file --logkeys stringArray log tags/realms(with leading /) to be enabled ([/[+]]name{,[/[+]]name}[=level]) -l, --loglevel string set log level -K, --private-key stringArray private key setting -k, --public-key stringArray public key setting -v, --verbose deprecated: enable logrus verbose logging --version show version\rIntroduction The Open Component Model command line client supports the work with OCM artifacts, like Component Archives, Common Transport Archive, Component Repositories, and Component Versions.\nAdditionally it provides some limited support for the docker daemon, OCI artifacts and registries.\nIt can be used in two ways:\nverb/operation first: here the sub commands follow the pattern \u0026lt;verb\u0026gt; \u0026lt;object kind\u0026gt; \u0026lt;arguments\u0026gt; area/kind first: here the area and/or object kind is given first followed by the operation according to the pattern [\u0026lt;area\u0026gt;] \u0026lt;object kind\u0026gt; \u0026lt;verb/operation\u0026gt; \u0026lt;arguments\u0026gt; The command accepts some top level options, they can only be given before the sub commands.\nA configuration according to ocm configfile is read from a .ocmconfig file located in the HOME directory. With the option \u0026ndash;config other file locations can be specified. If nothing is specified and no file is found at the default location a default configuration is composed according to known type specific configuration files.\nThe following configuration sources are used:\nThe docker configuration file at ~/.docker/config.json is read to feed in the configured credentials for OCI registries.\nThe npm configuration file at ~/.npmrc is read to feed in the configured credentials for NPM registries.\nWith the option \u0026ndash;cred it is possible to specify arbitrary credentials for various environments on the command line. Nevertheless it is always preferable to use the cli config file. Every credential setting is related to a dedicated consumer and provides a set of credential attributes. All this can be specified by a sequence of \u0026ndash;cred options.\nEvery option value has the format\n--cred [:]\u0026lt;attr\u003e=\u0026lt;value\u003e Consumer identity attributes are prefixed with the colon \u0026lsquo;:\u0026rsquo;. A credential settings always start with a sequence of at least one identity attributes, followed by a sequence of credential attributes. If a credential attribute is followed by an identity attribute a new credential setting is started.\nThe first credential setting may omit identity attributes. In this case it is used as default credential, always used if no dedicated match is found.\nFor example:\n--cred :type=OCIRegistry --cred :hostname=ghcr.io --cred username=mandelsoft --cred password=xyz With the option -X it is possible to pass global settings of the form\n-X \u0026lt;attribute\u003e=\u0026lt;value\u003e The \u0026ndash;log* options can be used to configure the logging behaviour. For details see ocm logging.\nThere is a quick config option \u0026ndash;logkeys to configure simple tag/realm based condition rules. The comma-separated names build an AND rule. Hereby, names starting with a slash (/) denote a realm (without the leading slash). A realm is a slash separated sequence of identifiers. If the realm name starts with a plus (+) character the generated rule will match the realm and all its sub-realms, otherwise, only the dedicated realm is affected. For example /+ocm=trace will enable all log output of the OCM library.\nA tag directly matches the logging tags. Used tags and realms can be found under topic ocm logging. The ocm coding basically uses the realm ocm. The default level to enable is info. Separated by an equal sign (=) optionally a dedicated level can be specified. Log levels can be (error, warn, info, debug and trace. The default level is warn. The \u0026ndash;logconfig* options can be used to configure a complete logging configuration (yaml/json) via command line. If the argument starts with an @, the logging configuration is taken from a file.\nThe value can be a simple type or a JSON/YAML string for complex values (see ocm attributes). The following attributes are supported:\ngithub.com/mandelsoft/logforward [logfwd]: logconfig Logging config structure used for config forwarding\nThis attribute is used to specify a logging configuration intended to be forwarded to other tools. (For example: TOI passes this config to the executor)\ngithub.com/mandelsoft/oci/cache [cache]: string\nFilesystem folder to use for caching OCI blobs\ngithub.com/mandelsoft/ocm/compat [compat]: bool\nCompatibility mode: Avoid generic local access methods and prefer type specific ones.\ngithub.com/mandelsoft/ocm/hasher: JSON\nPreferred hash algorithm to calculate resource digests. The following digesters are supported:\nNO-DIGEST SHA-256 (default) SHA-512 github.com/mandelsoft/ocm/keeplocalblob [keeplocalblob]: bool\nKeep local blobs when importing OCI artifacts to OCI registries from localBlob access methods. By default, they will be expanded to OCI artifacts with the access method ociRegistry. If this option is set to true, they will be stored as local blobs, also. The access method will still be localBlob but with a nested ociRegistry access method for describing the global access.\ngithub.com/mandelsoft/ocm/mapocirepo [mapocirepo]: bool|YAML\nWhen uploading an OCI artifact blob to an OCI based OCM repository and the artifact is uploaded as OCI artifact, the repository path part is shortened, either by hashing all but the last repository name part or by executing some prefix based name mappings.\nIf a boolean is given the short hash or none mode is enabled. The YAML flavor uses the following fields:\nmode string: hash, shortHash, prefixMapping or none. If unset, no mapping is done. prefixMappings: map[string]string repository path prefix mapping. prefix: string repository prefix to use (replaces potential sub path of OCM repo). or none. prefixMapping: map[string]string repository path prefix mapping. Notes:\nThe mapping only occurs in transfer commands and only when transferring to OCI registries (e.g. when transferring to a CTF archive this option will be ignored). The mapping in mode prefixMapping requires a full prefix of the composed final name. Partial matches are not supported. The host name of the target will be skipped. The artifact name of the component-descriptor is not mapped. If the mapping is provided on the command line it must be JSON format and needs to be properly escaped (see example below). Example:\nAssume a component named github.com/my_org/myexamplewithalongname and a chart name echo in the Charts.yaml of the chart archive. The following input to a resource.yaml creates a component version:\nname: mychart type: helmChart input: type: helm path: charts/mychart.tgz --- name: myimage type: ociImage version: 0.1.0 input: type: ociImage repository: ocm/ocm.software/ocmcli/ocmcli-image path: ghcr.io/acme/ocm/ocm.software/ocmcli/ocmcli-image:0.1.0 The following command:\nocm \"-X mapocirepo={\\\"mode\\\":\\\"mapping\\\",\\\"prefixMappings\\\":{\\\"acme/github.com/my_org/myexamplewithalongname/ocm/ocm.software/ocmcli\\\":\\\"acme/cli\\\", \\\"acme/github.com/my_org/myexamplewithalongnameabc123\\\":\\\"acme/mychart\\\"}}\" transfer ctf -f --copy-resources ./ctf ghcr.io/acme will result in the following artifacts in ghcr.io/my_org:\nmychart/echo cli/ocmcli-image Note that the host name part of the transfer target ghcr.io/acme is excluded from the prefix but the path acme is considered.\nThe same using a config file .ocmconfig:\ntype: generic.config.ocm.software/v1 configurations: ... - type: attributes.config.ocm.software attributes: ... mapocirepo: mode: mapping prefixMappings: acme/github.com/my\\_org/myexamplewithalongname/ocm/ocm.software/ocmcli: acme/cli acme/github.com/my\\_org/myexamplewithalongnameabc123: acme/mychart ocm transfer ca -f --copy-resources ./ca ghcr.io/acme github.com/mandelsoft/ocm/ociuploadrepo [ociuploadrepo]: oci base repository ref\nUpload local OCI artifact blobs to a dedicated repository.\ngithub.com/mandelsoft/ocm/plugindir [plugindir]: plugin directory\nDirectory to look for OCM plugin executables.\ngithub.com/mandelsoft/ocm/rootcerts [rootcerts]: JSON\nGeneral root certificate settings given as JSON document with the following format:\n{ \"rootCertificates\": [ { \"data\": \"\"\u0026lt;base64\u003e\" }, { \"path\": \"\"\u0026lt;file path\u003e\" } ] } One of following data fields are possible:\ndata: base64 encoded binary data stringdata: plain text data path: a file path to read the data from github.com/mandelsoft/ocm/signing: JSON\nPublic and private Key settings given as JSON document with the following format:\n{ \"publicKeys\": [ \"\u0026lt;provider\u003e\": { \"data\": \"\"\u0026lt;base64\u003e\" } ], \"privateKeys\"\": [ \"\u0026lt;provider\u003e\": { \"path\": \"\"\u0026lt;file path\u003e\" } ] } One of following data fields are possible:\ndata: base64 encoded binary data stringdata: plain text data path: a file path to read the data from github.com/mandelsoft/tempblobcache [blobcache]: string Foldername for temporary blob cache\nThe temporary blob cache is used to accessing large blobs from remote systems. The are temporarily stored in the filesystem, instead of the memory, to avoid blowing up the memory consumption.\nocm.software/cliconfig [cliconfig]: cliconfig Configuration Object passed to command line plugin.\nocm.software/compositionmode [compositionmode]: bool (default: false)\nComposition mode decouples a component version provided by a repository implementation from the backend persistence. Added local blobs will and other changes will not be forwarded to the backend repository until an AddVersion is called on the component. If composition mode is disabled blobs will directly be forwarded to the backend and descriptor updated will be persisted on AddVersion or closing a provided existing component version.\nocm.software/signing/sigstore [sigstore]: sigstore config Configuration to use for sigstore based signing.\nThe following fields are used.\nfulcioURL string default is https://fulcio.sigstore.dev rekorURL string default is https://rekor.sigstore.dev OIDCIssuer string default is https://oauth2.sigstore.dev/auth OIDCClientID string default is sigstore For several options (like -X) it is possible to pass complex values using JSON or YAML syntax. To pass those arguments the escaping of the used shell must be used to pass quotes, commas, curly brackets or newlines. for the bash the easiest way to achieve this is to put the complete value into single quotes.\n-X 'mapocirepo={\"mode\": \"shortHash\"}'. Alternatively, quotes and opening curly brackets can be escaped by using a backslash (\\). Often a tagged value can also be substituted from a file with the syntax\n\u0026lt;attr\u003e=@\u0026lt;filepath\u003e The \u0026ndash;public-key and \u0026ndash;private-key options can be used to define public and private keys on the command line. The options have an argument of the form \u0026lt;name\u0026gt;=\u0026lt;filepath\u0026gt;. The name is the name of the key and represents the context is used for (For example the signature name of a component version)\nAlternatively a key can be specified as base64 encoded string if the argument start with the prefix ! or as direct string with the prefix =.\nWith \u0026ndash;issuer it is possible to declare expected issuer constraints for public key certificates provided as part of a signature required to accept the provisioned public key (besides the successful validation of the certificate). By default, the issuer constraint is derived from the signature name. If it is not a formal distinguished name, it is assumed to be a plain common name.\nWith \u0026ndash;ca-cert it is possible to define additional root certificates for signature verification, if public keys are provided by a certificate delivered with the signature.\nSee Also Sub Commands ocm add\t— Add elements to a component repository or component version ocm check\t— check components in OCM repository ocm clean\t— Cleanup/re-organize elements ocm create\t— Create transport or component archive ocm describe\t— Describe various elements by using appropriate sub commands. ocm download\t— Download oci artifacts, resources or complete components ocm get\t— Get information about artifacts and components ocm list\t— List information about components ocm set\t— Set information about OCM repositories ocm show\t— Show tags or versions ocm sign\t— Sign components or hashes ocm transfer\t— Transfer artifacts or components ocm verify\t— Verify component version signatures Additional Help Topics ocm attributes\t— configuration attributes used to control the behaviour ocm configfile\t— configuration file ocm credential-handling\t— Provisioning of credentials for credential consumers ocm logging\t— Configured logging keys ocm oci-references\t— notation for OCI references ocm ocm-accessmethods\t— List of all supported access methods ocm ocm-downloadhandlers\t— List of all available download handlers ocm ocm-labels\t— Labels and Label Merging ocm ocm-pubsub\t— List of all supported publish/subscribe implementations ocm ocm-references\t— notation for OCM references ocm ocm-uploadhandlers\t— List of all available upload handlers ocm toi-bootstrapping\t— Tiny OCM Installer based on component versions ","date":"0001-01-01","id":66,"permalink":"/docs/cli-reference/","summary":"\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -X, --attribute stringArray attribute setting\n --ca-cert stringArray additional root certificate authorities (for signing certificates)\n --config stringArray configuration file\n --config-set strings apply configuration set\n -C, --cred stringArray credential setting\n -h, --help help for ocm\n -I, --issuer stringArray issuer name or distinguished name (DN) (optionally for dedicated signature) ([\u0026lt;name\u0026gt;:=]\u0026lt;dn\u0026gt;)\n --logJson log as json instead of human readable logs\n --logconfig string log config\n -L, --logfile string set log file\n --logkeys stringArray log tags/realms(with leading /) to be enabled ([/[+]]name{,[/[+]]name}[=level])\n -l, --loglevel string set log level\n -K, --private-key stringArray private key setting\n -k, --public-key stringArray public key setting\n -v, --verbose deprecated: enable logrus verbose logging\n --version show version\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"introduction\"\u003eIntroduction\u003c/h3\u003e\n\u003cp\u003eThe Open Component Model command line client supports the work with OCM\nartifacts, like Component Archives, Common Transport Archive,\nComponent Repositories, and Component Versions.\u003c/p\u003e","tags":[],"title":"cli-reference"},{"content":"Usage ocm transfer commontransportarchive [\u0026lt;options\u0026gt;] \u0026lt;ctf\u0026gt; \u0026lt;target\u0026gt;\rOptions -L, --copy-local-resources transfer referenced local resources by-value -V, --copy-resources transfer referenced resources by-value --copy-sources transfer referenced sources by-value --enforce enforce transport as if target version were not present -h, --help help for commontransportarchive --lookup stringArray repository name or spec for closure lookup fallback --no-update don\u0026#39;t touch existing versions in target -N, --omit-access-types strings omit by-value transfer for resource types -f, --overwrite overwrite existing component versions -r, --recursive follow component reference nesting --script string config name of transfer handler script -s, --scriptFile string filename of transfer handler script -E, --stop-on-existing stop on existing component version in target repository -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;) --uploader \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; repository uploader (\u0026lt;name\u0026gt;[:\u0026lt;artifact type\u0026gt;[:\u0026lt;media type\u0026gt;[:\u0026lt;priority\u0026gt;]]]=\u0026lt;JSON target config\u0026gt;) (default [])\rDescription Transfer content of a Common Transport Archive to the given target repository.\nWith the option \u0026ndash;recursive the complete reference tree of a component reference is traversed.\nWith the option \u0026ndash;no-update existing versions in the target repository will not be touched at all. An additional specification of the option \u0026ndash;overwrite is ignored. By default, updates of volatile (non-signature-relevant) information is enabled, but the modification of non-volatile data is prohibited unless the overwrite option is given.\nIf the option \u0026ndash;overwrite is given, component versions in the target repository will be overwritten, if they already exist, but with different digest. If the option \u0026ndash;enforce is given, component versions in the target repository will be transported as if they were not present on the target side, regardless of their state (this is independent on their actual state, even identical versions are re-transported).\nIf a component lookup for building a reference closure is required the \u0026ndash;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.\nThe \u0026ndash;type option accepts a file format for the target archive to use. It is only evaluated if the target archive does not exist yet. The following formats are supported:\ndirectory tar tgz The default format is directory.\nIf the option \u0026ndash;copy-resources is given, all referential resources will potentially be localized, mapped to component version local resources in the target repository. If the option \u0026ndash;copy-local-resources is given, instead, only resources with the relation local will be transferred. This behaviour can be further influenced by specifying a transfer script with the script option family.\nIf the option \u0026ndash;copy-sources is given, all referential sources 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.\nIf the option \u0026ndash;omit-access-types is given, by-value transfer is omitted completely for the given resource types.\nIf the option \u0026ndash;stop-on-existing is given together with the \u0026ndash;recursive option, the recursion is stopped for component versions already existing in the target repository. This behaviour can be further influenced by specifying a transfer script with the script option family.\nIf the \u0026ndash;uploader option is specified, appropriate uploader handlers are configured for the operation. It has the following format\n\u0026lt;name\u003e:\u0026lt;artifact type\u003e:\u0026lt;media type\u003e=\u0026lt;yaml target config\u003e The uploader name may be a path expression with the following possibilities:\nocm/mavenPackage: uploading maven artifacts\nThe ocm/mavenPackage uploader is able to upload maven artifacts (whole GAV only!) as artifact archive according to the maven artifact spec. If registered the default mime type is: application/x-tgz\nIt accepts a plain string for the URL or a config with the following field: \u0026lsquo;url\u0026rsquo;: the URL of the maven repository.\nocm/npmPackage: uploading npm artifacts\nThe ocm/npmPackage uploader is able to upload npm artifacts as artifact archive according to the npm package spec. If registered the default mime type is: application/x-tgz\nIt accepts a plain string for the URL or a config with the following field: \u0026lsquo;url\u0026rsquo;: the URL of the npm repository.\nocm/ociArtifacts: downloading OCI artifacts\nThe ociArtifacts downloader is able to download OCI artifacts as artifact archive according to the OCI distribution spec. The following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar application/vnd.oci.image.manifest.v1+tar+gzip application/vnd.oci.image.index.v1+tar application/vnd.oci.image.index.v1+tar+gzip application/vnd.docker.distribution.manifest.v2+tar application/vnd.docker.distribution.manifest.v2+tar+gzip application/vnd.docker.distribution.manifest.list.v2+tar application/vnd.docker.distribution.manifest.list.v2+tar+gzip By default, it is registered for these mimetypes.\nIt accepts a config with the following fields:\nnamespacePrefix: a namespace prefix used for the uploaded artifacts ociRef: an OCI repository reference repository: an OCI repository specification for the target OCI registry Alternatively, a single string value can be given representing an OCI repository reference.\nplugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\nSee ocm ocm-uploadhandlers for further details on using upload handlers.\nIt is possible to use a dedicated transfer script based on spiff. The option \u0026ndash;scriptFile can be used to specify this script by a file name. With \u0026ndash;script it can be taken from the CLI config using an entry of the following format:\ntype: scripts.ocm.config.ocm.software scripts: \u0026lt;name\u003e: path: \u0026lt;filepath\u003e script: \u0026lt;scriptdata\u003e Only one of the fields path or script can be used.\nIf no script option is given and the cli config defines a script default this one is used.\nExamples $ ocm transfer ctf ctf.tgz ghcr.io/mandelsoft/components\rSee Also ocm transfer\t— Transfer artifacts or components ","date":"0001-01-01","id":67,"permalink":"/docs/cli-reference/transfer/commontransportarchive/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm transfer commontransportarchive [\u0026lt;options\u0026gt;] \u0026lt;ctf\u0026gt; \u0026lt;target\u0026gt;\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -L, --copy-local-resources transfer referenced local resources by-value\n -V, --copy-resources transfer referenced resources by-value\n --copy-sources transfer referenced sources by-value\n --enforce enforce transport as if target version were not present\n -h, --help help for commontransportarchive\n --lookup stringArray repository name or spec for closure lookup fallback\n --no-update don\u0026#39;t touch existing versions in target\n -N, --omit-access-types strings omit by-value transfer for resource types\n -f, --overwrite overwrite existing component versions\n -r, --recursive follow component reference nesting\n --script string config name of transfer handler script\n -s, --scriptFile string filename of transfer handler script\n -E, --stop-on-existing stop on existing component version in target repository\n -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\n --uploader \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; repository uploader (\u0026lt;name\u0026gt;[:\u0026lt;artifact type\u0026gt;[:\u0026lt;media type\u0026gt;[:\u0026lt;priority\u0026gt;]]]=\u0026lt;JSON target config\u0026gt;) (default [])\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eTransfer content of a Common Transport Archive to the given target repository.\u003c/p\u003e","tags":[],"title":"commontransportarchive"},{"content":"Usage ocm create componentarchive [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; \u0026lt;version\u0026gt; --provider \u0026lt;provider-name\u0026gt; {--provider \u0026lt;label\u0026gt;=\u0026lt;value\u0026gt;} {\u0026lt;label\u0026gt;=\u0026lt;value\u0026gt;}\rOptions -F, --file string target file/directory (default \u0026#34;component-archive\u0026#34;) -f, --force remove existing content -h, --help help for componentarchive -p, --provider stringArray provider attribute -S, --scheme string schema version (default \u0026#34;v2\u0026#34;) -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\rDescription Create a new component archive. This might be either a directory prepared to host component version content or a tar/tgz file (see option \u0026ndash;type).\nA provider must be specified, additional provider labels are optional.\nThe \u0026ndash;type option accepts a file format for the target archive to use. It is only evaluated if the target archive does not exist yet. The following formats are supported:\ndirectory tar tgz The default format is directory.\nIf the option \u0026ndash;scheme is given, the specified component descriptor format is used/generated.\nThe following schema versions are supported for explicit conversions:\nocm.software/v3alpha1 v2 (default) Examples $ ocm create componentarchive --file myfirst --provider acme.org --provider email=alice@acme.org acme.org/demo 1.0\rSee Also ocm create\t— Create transport or component archive ","date":"0001-01-01","id":68,"permalink":"/docs/cli-reference/create/componentarchive/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm create componentarchive [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; \u0026lt;version\u0026gt; --provider \u0026lt;provider-name\u0026gt; {--provider \u0026lt;label\u0026gt;=\u0026lt;value\u0026gt;} {\u0026lt;label\u0026gt;=\u0026lt;value\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -F, --file string target file/directory (default \u0026#34;component-archive\u0026#34;)\n -f, --force remove existing content\n -h, --help help for componentarchive\n -p, --provider stringArray provider attribute\n -S, --scheme string schema version (default \u0026#34;v2\u0026#34;)\n -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eCreate a new component archive. This might be either a directory prepared\nto host component version content or a tar/tgz file (see option \u0026ndash;type).\u003c/p\u003e","tags":[],"title":"componentarchive"},{"content":"Usage ocm transfer componentarchive [\u0026lt;options\u0026gt;] \u0026lt;source\u0026gt; \u0026lt;target\u0026gt;\rOptions -L, --copy-local-resources transfer referenced local resources by-value -V, --copy-resources transfer referenced resources by-value --copy-sources transfer referenced sources by-value --enforce enforce transport as if target version were not present -h, --help help for componentarchive --lookup stringArray repository name or spec for closure lookup fallback --no-update don\u0026#39;t touch existing versions in target -f, --overwrite overwrite existing component versions -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\rDescription Transfer a component archive to some component repository. This might be a CTF Archive or a regular repository. If the type CTF is specified the target must already exist, if CTF flavor is specified it will be created if it does not exist.\nBesides those explicitly known types a complete repository spec might be configured, either via inline argument or command configuration file and name.\nThe \u0026ndash;type option accepts a file format for the target archive to use. It is only evaluated if the target archive does not exist yet. The following formats are supported:\ndirectory tar tgz The default format is directory.\nIf a component lookup for building a reference closure is required the \u0026ndash;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.\nWith the option \u0026ndash;no-update existing versions in the target repository will not be touched at all. An additional specification of the option \u0026ndash;overwrite is ignored. By default, updates of volatile (non-signature-relevant) information is enabled, but the modification of non-volatile data is prohibited unless the overwrite option is given.\nIf the option \u0026ndash;overwrite is given, component versions in the target repository will be overwritten, if they already exist, but with different digest. If the option \u0026ndash;enforce is given, component versions in the target repository will be transported as if they were not present on the target side, regardless of their state (this is independent on their actual state, even identical versions are re-transported).\nIf the option \u0026ndash;copy-resources is given, all referential resources will potentially be localized, mapped to component version local resources in the target repository. If the option \u0026ndash;copy-local-resources is given, instead, only resources with the relation local will be transferred. This behaviour can be further influenced by specifying a transfer script with the script option family.\nIf the option \u0026ndash;copy-sources is given, all referential sources 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.\nSee Also ocm transfer\t— Transfer artifacts or components ","date":"0001-01-01","id":69,"permalink":"/docs/cli-reference/transfer/componentarchive/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm transfer componentarchive [\u0026lt;options\u0026gt;] \u0026lt;source\u0026gt; \u0026lt;target\u0026gt;\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -L, --copy-local-resources transfer referenced local resources by-value\n -V, --copy-resources transfer referenced resources by-value\n --copy-sources transfer referenced sources by-value\n --enforce enforce transport as if target version were not present\n -h, --help help for componentarchive\n --lookup stringArray repository name or spec for closure lookup fallback\n --no-update don\u0026#39;t touch existing versions in target\n -f, --overwrite overwrite existing component versions\n -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eTransfer a component archive to some component repository. This might\nbe a CTF Archive or a regular repository.\nIf the type CTF is specified the target must already exist, if CTF flavor\nis specified it will be created if it does not exist.\u003c/p\u003e","tags":[],"title":"componentarchive"},{"content":"Usage ocm add componentversions [\u0026lt;options\u0026gt;] [--version \u0026lt;version\u0026gt;] [\u0026lt;ctf archive\u0026gt;] {\u0026lt;component-constructor.yaml\u0026gt;}\rOptions --addenv access environment for templating -C, --complete include all referenced component version -L, --copy-local-resources transfer referenced local resources by-value -V, --copy-resources transfer referenced resources by-value -c, --create (re)create archive --dry-run evaluate and print component specifications -F, --file string target file/directory (default \u0026#34;transport-archive\u0026#34;) -f, --force remove existing content -h, --help help for componentversions --lookup stringArray repository name or spec for closure lookup fallback -O, --output string output file for dry-run -P, --preserve-signature preserve existing signatures -R, --replace replace existing elements -S, --scheme string schema version (default \u0026#34;v2\u0026#34;) -s, --settings stringArray settings file with variable settings (yaml) --skip-digest-generation skip digest creation --templater string templater to use (go, none, spiff, subst) (default \u0026#34;subst\u0026#34;) -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;) --uploader \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; repository uploader (\u0026lt;name\u0026gt;[:\u0026lt;artifact type\u0026gt;[:\u0026lt;media type\u0026gt;[:\u0026lt;priority\u0026gt;]]]=\u0026lt;JSON target config\u0026gt;) (default []) -v, --version string default version for components\rDescription Add component versions specified by a constructor file to a Common Transport Archive. The archive might be either a directory prepared to host component version content or a tar/tgz file (see option \u0026ndash;type).\nIf option \u0026ndash;create is given, the archive is created first. An additional option \u0026ndash;force will recreate an empty archive if it already exists.\nIf option \u0026ndash;complete is given all component versions referenced by the added one, will be added, also. Therefore, the \u0026ndash;lookup is required to specify an OCM repository to lookup the missing component versions. If additionally the -V is given, the resources of those additional components will be added by value.\nThe \u0026ndash;replace option allows users to specify whether adding an element with the same name and extra identity but different version as an existing element, append (false) or replace (true) the existing element.\nThe \u0026ndash;preserve-signature option prohibits changes of signature relevant elements.\nThe source, resource and reference list can be composed according to the commands ocm add sources, ocm add resources, ocm add references, respectively.\nThe description file might contain:\na single component as shown in the example a list of components under the key components a list of yaml documents with a single component or component list The optional field meta.configuredSchemaVersion for a component entry can be used to specify a dedicated serialization format to use for the component descriptor. If given it overrides the \u0026ndash;schema option of the command. By default, v2 is used.\nVarious elements support to add arbitrary information by using labels (see ocm ocm-labels).\nThe \u0026ndash;type option accepts a file format for the target archive to use. It is only evaluated if the target archive does not exist yet. The following formats are supported:\ndirectory tar tgz The default format is directory.\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" If a component lookup for building a reference closure is required the \u0026ndash;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.\nIf the option \u0026ndash;copy-resources is given, all referential resources will potentially be localized, mapped to component version local resources in the target repository. If the option \u0026ndash;copy-local-resources is given, instead, only resources with the relation local will be transferred. This behaviour can be further influenced by specifying a transfer script with the script option family.\nIf the \u0026ndash;uploader option is specified, appropriate uploader handlers are configured for the operation. It has the following format\n\u0026lt;name\u003e:\u0026lt;artifact type\u003e:\u0026lt;media type\u003e=\u0026lt;yaml target config\u003e The uploader name may be a path expression with the following possibilities:\nocm/mavenPackage: uploading maven artifacts\nThe ocm/mavenPackage uploader is able to upload maven artifacts (whole GAV only!) as artifact archive according to the maven artifact spec. If registered the default mime type is: application/x-tgz\nIt accepts a plain string for the URL or a config with the following field: \u0026lsquo;url\u0026rsquo;: the URL of the maven repository.\nocm/npmPackage: uploading npm artifacts\nThe ocm/npmPackage uploader is able to upload npm artifacts as artifact archive according to the npm package spec. If registered the default mime type is: application/x-tgz\nIt accepts a plain string for the URL or a config with the following field: \u0026lsquo;url\u0026rsquo;: the URL of the npm repository.\nocm/ociArtifacts: downloading OCI artifacts\nThe ociArtifacts downloader is able to download OCI artifacts as artifact archive according to the OCI distribution spec. The following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar application/vnd.oci.image.manifest.v1+tar+gzip application/vnd.oci.image.index.v1+tar application/vnd.oci.image.index.v1+tar+gzip application/vnd.docker.distribution.manifest.v2+tar application/vnd.docker.distribution.manifest.v2+tar+gzip application/vnd.docker.distribution.manifest.list.v2+tar application/vnd.docker.distribution.manifest.list.v2+tar+gzip By default, it is registered for these mimetypes.\nIt accepts a config with the following fields:\nnamespacePrefix: a namespace prefix used for the uploaded artifacts ociRef: an OCI repository reference repository: an OCI repository specification for the target OCI registry Alternatively, a single string value can be given representing an OCI repository reference.\nplugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\nSee ocm ocm-uploadhandlers for further details on using upload handlers.\nExamples $ ocm add componentversions --file ctf --version 1.0 component-constructor.yaml and a file \u0026lt;code\u0026gt;component-constructor.yaml\u0026lt;/code\u0026gt;: name: ocm.software/demo/test version: 1.0.0 provider: name: ocm.software labels: - name: city value: Karlsruhe labels: - name: purpose value: test resources: - name: text type: PlainText input: type: file path: testdata - name: data type: PlainText input: type: binary data: IXN0cmluZ2RhdGE= The resource \u0026lt;code\u0026gt;text\u0026lt;/code\u0026gt; is taken from a file \u0026lt;code\u0026gt;testdata\u0026lt;/code\u0026gt; located next to the description file.\rSee Also ocm add\t— Add elements to a component repository or component version ","date":"0001-01-01","id":70,"permalink":"/docs/cli-reference/add/componentversions/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm add componentversions [\u0026lt;options\u0026gt;] [--version \u0026lt;version\u0026gt;] [\u0026lt;ctf archive\u0026gt;] {\u0026lt;component-constructor.yaml\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --addenv access environment for templating\n -C, --complete include all referenced component version\n -L, --copy-local-resources transfer referenced local resources by-value\n -V, --copy-resources transfer referenced resources by-value\n -c, --create (re)create archive\n --dry-run evaluate and print component specifications\n -F, --file string target file/directory (default \u0026#34;transport-archive\u0026#34;)\n -f, --force remove existing content\n -h, --help help for componentversions\n --lookup stringArray repository name or spec for closure lookup fallback\n -O, --output string output file for dry-run\n -P, --preserve-signature preserve existing signatures\n -R, --replace replace existing elements\n -S, --scheme string schema version (default \u0026#34;v2\u0026#34;)\n -s, --settings stringArray settings file with variable settings (yaml)\n --skip-digest-generation skip digest creation\n --templater string templater to use (go, none, spiff, subst) (default \u0026#34;subst\u0026#34;)\n -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\n --uploader \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; repository uploader (\u0026lt;name\u0026gt;[:\u0026lt;artifact type\u0026gt;[:\u0026lt;media type\u0026gt;[:\u0026lt;priority\u0026gt;]]]=\u0026lt;JSON target config\u0026gt;) (default [])\n -v, --version string default version for components\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAdd component versions specified by a constructor file to a Common Transport\nArchive. The archive might be either a directory prepared to host component version\ncontent or a tar/tgz file (see option \u0026ndash;type).\u003c/p\u003e","tags":[],"title":"componentversions"},{"content":"Usage ocm check componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\rOptions --fail-on-error fail on validation error -h, --help help for componentversions -R, --local-resources check also for describing resources with local access method, only -S, --local-sources check also for describing sources with local access method, only -o, --output string output mode (JSON, json, wide, yaml) --repo string repository name or spec -s, --sort stringArray sort fields\rDescription This command checks, whether component versions are completely contained in an OCM repository with all its dependent component references.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry If the options \u0026ndash;local-resources and/or \u0026ndash;local-sources are given the check additionally assures that all resources or sources are included into the component version. This means that they are using local access methods, only.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json wide yaml Examples $ ocm check componentversion ghcr.io/open-component-model/ocm//ocm.software/ocmcli:0.17.0 $ ocm check componentversion --repo OCIRegistry::ghcr.io/open-component-model/ocm ocm.software/ocmcli:0.17.0\rSee Also ocm check\t— check components in OCM repository ","date":"0001-01-01","id":71,"permalink":"/docs/cli-reference/check/componentversions/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm check componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --fail-on-error fail on validation error\n -h, --help help for componentversions\n -R, --local-resources check also for describing resources with local access method, only\n -S, --local-sources check also for describing sources with local access method, only\n -o, --output string output mode (JSON, json, wide, yaml)\n --repo string repository name or spec\n -s, --sort stringArray sort fields\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eThis command checks, whether component versions are completely contained\nin an OCM repository with all its dependent component references.\u003c/p\u003e","tags":[],"title":"componentversions"},{"content":"Usage ocm download componentversions [\u0026lt;options\u0026gt;] {\u0026lt;components\u0026gt;} Options -h, --help help for componentversions -O, --outfile string output file or directory --repo string repository name or spec -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\rDescription Download component versions from an OCM repository. The result is stored in component archives.\nThe files are named according to the component version name.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry The \u0026ndash;type option accepts a file format for the target archive to use. It is only evaluated if the target archive does not exist yet. The following formats are supported:\ndirectory tar tgz The default format is directory.\nSee Also ocm download\t— Download oci artifacts, resources or complete components ","date":"0001-01-01","id":72,"permalink":"/docs/cli-reference/download/componentversions/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm download componentversions [\u0026lt;options\u0026gt;] {\u0026lt;components\u0026gt;} \u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for componentversions\n -O, --outfile string output file or directory\n --repo string repository name or spec\n -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eDownload component versions from an OCM repository. The result is stored in\ncomponent archives.\u003c/p\u003e","tags":[],"title":"componentversions"},{"content":"Usage ocm get componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\rOptions -c, --constraints constraints version constraint -h, --help help for componentversions --latest restrict component versions to latest --lookup stringArray repository name or spec for closure lookup fallback -o, --output string output mode (JSON, json, tree, wide, yaml) -r, --recursive follow component reference nesting --repo string repository name or spec -S, --scheme string schema version -s, --sort stringArray sort fields\rDescription Get lists all component versions specified, if only a component is specified all versions are listed.\nIf the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry With the option \u0026ndash;recursive the complete reference tree of a component reference is traversed.\nIf a component lookup for building a reference closure is required the \u0026ndash;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.\nIf the option \u0026ndash;scheme is given, the component descriptor is converted to the specified format for output. If no format is given the storage format of the actual descriptor is used or, for new ones v2 is used. With internal the internal representation is shown. The following schema versions are supported for explicit conversions:\nocm.software/v3alpha1 v2 With the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json tree wide yaml Examples $ ocm get componentversion ghcr.io/open-component-model/ocm//ocm.software/ocmcli:0.17.0 $ ocm get componentversion --repo OCIRegistry::ghcr.io/open-component-model/ocm ocm.software/ocmcli:0.17.0\rSee Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":73,"permalink":"/docs/cli-reference/get/componentversions/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -c, --constraints constraints version constraint\n -h, --help help for componentversions\n --latest restrict component versions to latest\n --lookup stringArray repository name or spec for closure lookup fallback\n -o, --output string output mode (JSON, json, tree, wide, yaml)\n -r, --recursive follow component reference nesting\n --repo string repository name or spec\n -S, --scheme string schema version\n -s, --sort stringArray sort fields\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eGet lists all component versions specified, if only a component is specified\nall versions are listed.\u003c/p\u003e","tags":[],"title":"componentversions"},{"content":"Usage ocm list componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\rOptions -c, --constraints constraints version constraint -h, --help help for componentversions --latest restrict component versions to latest --lookup stringArray repository name or spec for closure lookup fallback -o, --output string output mode (JSON, json, yaml) --repo string repository name or spec -S, --scheme string schema version -s, --sort stringArray sort fields\rDescription List lists the version names of the specified objects, if only a component is specified all versions according to the given version constraints are listed.\nIf the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry If a component lookup for building a reference closure is required the \u0026ndash;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.\nIf the option \u0026ndash;scheme is given, the component descriptor is converted to the specified format for output. If no format is given the storage format of the actual descriptor is used or, for new ones v2 is used. With internal the internal representation is shown. The following schema versions are supported for explicit conversions:\nocm.software/v3alpha1 v2 With the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json yaml Examples $ ocm list componentversion ghcr.io/open-component-model/ocm//ocm.software/ocmcli $ ocm list componentversion --repo OCIRegistry::ghcr.io/open-component-model/ocm ocm.software/ocmcli\rSee Also ocm list\t— List information about components ","date":"0001-01-01","id":74,"permalink":"/docs/cli-reference/list/componentversions/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm list componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -c, --constraints constraints version constraint\n -h, --help help for componentversions\n --latest restrict component versions to latest\n --lookup stringArray repository name or spec for closure lookup fallback\n -o, --output string output mode (JSON, json, yaml)\n --repo string repository name or spec\n -S, --scheme string schema version\n -s, --sort stringArray sort fields\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eList lists the version names of the specified objects, if only a component is specified\nall versions according to the given version constraints are listed.\u003c/p\u003e","tags":[],"title":"componentversions"},{"content":"Usage ocm sign componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\rOptions -- enable verification store -S, --algorithm string signature handler (default \u0026#34;RSASSA-PKCS1-V1_5\u0026#34;) --ca-cert stringArray additional root certificate authorities (for signing certificates) -c, --constraints constraints version constraint -H, --hash string hash algorithm (default \u0026#34;SHA-256\u0026#34;) -h, --help help for componentversions -I, --issuer stringArray issuer name or distinguished name (DN) (optionally for dedicated signature) ([\u0026lt;name\u0026gt;:=]\u0026lt;dn\u0026gt;) --keyless use keyless signing --latest restrict component versions to latest --lookup stringArray repository name or spec for closure lookup fallback -N, --normalization string normalization algorithm (default \u0026#34;jsonNormalisation/v1\u0026#34;) -K, --private-key stringArray private key setting -k, --public-key stringArray public key setting -R, --recursive recursively sign component versions --repo string repository name or spec -s, --signature stringArray signature name --tsa use timestamp authority (default server: http://timestamp.digicert.com) --tsa-url string TSA server URL --update update digest in component versions (default true) --verified string file used to remember verifications for downloads (default \u0026#34;~/.ocm/verified\u0026#34;) -V, --verify verify existing digests (default true)\rDescription Sign specified component versions.\nIf the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry The \u0026ndash;public-key and \u0026ndash;private-key options can be used to define public and private keys on the command line. The options have an argument of the form [\u0026lt;name\u0026gt;=]\u0026lt;filepath\u0026gt;. The optional name specifies the signature name the key should be used for. By default, this is the signature name specified with the option \u0026ndash;signature.\nAlternatively a key can be specified as base64 encoded string if the argument start with the prefix ! or as direct string with the prefix =.\nIf the verification store is enabled, resources downloaded from signed or verified component versions are verified against their digests provided by the component version.(not supported for using downloaders for the resource download).\nThe usage of the verification store is enabled by \u0026ndash; or by specifying a verification file with \u0026ndash;verified.\nIf in signing mode a public key is specified, existing signatures for the given signature name will be verified, instead of recreated.\nThe following signing types are supported with option \u0026ndash;algorithm:\nRSASSA-PKCS1-V1_5 (default) RSASSA-PSS rsa-signingservice rsapss-signingservice sigstore The following normalization modes are supported with option \u0026ndash;normalization:\njsonNormalisation/v1 (default) jsonNormalisation/v2 The following hash modes are supported with option \u0026ndash;hash:\nNO-DIGEST SHA-256 (default) SHA-512 If a component lookup for building a reference closure is required the \u0026ndash;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.\nExamples $ ocm sign componentversion --signature mysignature --private-key=my.key ghcr.io/open-component-model/ocm//ocm.software/ocmcli:0.17.0\rSee Also ocm sign\t— Sign components or hashes ","date":"0001-01-01","id":75,"permalink":"/docs/cli-reference/sign/componentversions/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm sign componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -- enable verification store\n -S, --algorithm string signature handler (default \u0026#34;RSASSA-PKCS1-V1_5\u0026#34;)\n --ca-cert stringArray additional root certificate authorities (for signing certificates)\n -c, --constraints constraints version constraint\n -H, --hash string hash algorithm (default \u0026#34;SHA-256\u0026#34;)\n -h, --help help for componentversions\n -I, --issuer stringArray issuer name or distinguished name (DN) (optionally for dedicated signature) ([\u0026lt;name\u0026gt;:=]\u0026lt;dn\u0026gt;)\n --keyless use keyless signing\n --latest restrict component versions to latest\n --lookup stringArray repository name or spec for closure lookup fallback\n -N, --normalization string normalization algorithm (default \u0026#34;jsonNormalisation/v1\u0026#34;)\n -K, --private-key stringArray private key setting\n -k, --public-key stringArray public key setting\n -R, --recursive recursively sign component versions\n --repo string repository name or spec\n -s, --signature stringArray signature name\n --tsa use timestamp authority (default server: http://timestamp.digicert.com)\n --tsa-url string TSA server URL\n --update update digest in component versions (default true)\n --verified string file used to remember verifications for downloads (default \u0026#34;~/.ocm/verified\u0026#34;)\n -V, --verify verify existing digests (default true)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eSign specified component versions.\u003c/p\u003e","tags":[],"title":"componentversions"},{"content":"Usage ocm transfer componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;} \u0026lt;target\u0026gt;\rOptions -B, --bom-file string file name to write the component version BOM -c, --constraints constraints version constraint -L, --copy-local-resources transfer referenced local resources by-value -V, --copy-resources transfer referenced resources by-value --copy-sources transfer referenced sources by-value --disable-uploads disable standard upload handlers for transport --enforce enforce transport as if target version were not present -h, --help help for componentversions --latest restrict component versions to latest --lookup stringArray repository name or spec for closure lookup fallback --no-update don\u0026#39;t touch existing versions in target -N, --omit-access-types strings omit by-value transfer for resource types -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 -E, --stop-on-existing stop on existing component version in target repository -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;) --uploader \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; repository uploader (\u0026lt;name\u0026gt;[:\u0026lt;artifact type\u0026gt;[:\u0026lt;media type\u0026gt;[:\u0026lt;priority\u0026gt;]]]=\u0026lt;JSON target config\u0026gt;) (default [])\rDescription 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.\nIf the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry The \u0026ndash;type option accepts a file format for the target archive to use. It is only evaluated if the target archive does not exist yet. The following formats are supported:\ndirectory tar tgz The default format is directory.\nWith the option \u0026ndash;recursive the complete reference tree of a component reference is traversed.\nIf a component lookup for building a reference closure is required the \u0026ndash;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.\nIf the option \u0026ndash;overwrite is given, component versions in the target repository will be overwritten, if they already exist, but with different digest. If the option \u0026ndash;enforce is given, component versions in the target repository will be transported as if they were not present on the target side, regardless of their state (this is independent on their actual state, even identical versions are re-transported).\nWith the option \u0026ndash;no-update existing versions in the target repository will not be touched at all. An additional specification of the option \u0026ndash;overwrite is ignored. By default, updates of volatile (non-signature-relevant) information is enabled, but the modification of non-volatile data is prohibited unless the overwrite option is given.\nIf the option \u0026ndash;copy-resources is given, all referential resources will potentially be localized, mapped to component version local resources in the target repository. If the option \u0026ndash;copy-local-resources is given, instead, only resources with the relation local will be transferred. This behaviour can be further influenced by specifying a transfer script with the script option family.\nIf the option \u0026ndash;copy-sources is given, all referential sources 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.\nIf the option \u0026ndash;omit-access-types is given, by-value transfer is omitted completely for the given resource types.\nIf the option \u0026ndash;stop-on-existing is given together with the \u0026ndash;recursive option, the recursion is stopped for component versions already existing in the target repository. This behaviour can be further influenced by specifying a transfer script with the script option family.\nIf the \u0026ndash;uploader option is specified, appropriate uploader handlers are configured for the operation. It has the following format\n\u0026lt;name\u003e:\u0026lt;artifact type\u003e:\u0026lt;media type\u003e=\u0026lt;yaml target config\u003e The uploader name may be a path expression with the following possibilities:\nocm/mavenPackage: uploading maven artifacts\nThe ocm/mavenPackage uploader is able to upload maven artifacts (whole GAV only!) as artifact archive according to the maven artifact spec. If registered the default mime type is: application/x-tgz\nIt accepts a plain string for the URL or a config with the following field: \u0026lsquo;url\u0026rsquo;: the URL of the maven repository.\nocm/npmPackage: uploading npm artifacts\nThe ocm/npmPackage uploader is able to upload npm artifacts as artifact archive according to the npm package spec. If registered the default mime type is: application/x-tgz\nIt accepts a plain string for the URL or a config with the following field: \u0026lsquo;url\u0026rsquo;: the URL of the npm repository.\nocm/ociArtifacts: downloading OCI artifacts\nThe ociArtifacts downloader is able to download OCI artifacts as artifact archive according to the OCI distribution spec. The following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar application/vnd.oci.image.manifest.v1+tar+gzip application/vnd.oci.image.index.v1+tar application/vnd.oci.image.index.v1+tar+gzip application/vnd.docker.distribution.manifest.v2+tar application/vnd.docker.distribution.manifest.v2+tar+gzip application/vnd.docker.distribution.manifest.list.v2+tar application/vnd.docker.distribution.manifest.list.v2+tar+gzip By default, it is registered for these mimetypes.\nIt accepts a config with the following fields:\nnamespacePrefix: a namespace prefix used for the uploaded artifacts ociRef: an OCI repository reference repository: an OCI repository specification for the target OCI registry Alternatively, a single string value can be given representing an OCI repository reference.\nplugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\nSee ocm ocm-uploadhandlers for further details on using upload handlers.\nIt is possible to use a dedicated transfer script based on spiff. The option \u0026ndash;scriptFile can be used to specify this script by a file name. With \u0026ndash;script it can be taken from the CLI config using an entry of the following format:\ntype: scripts.ocm.config.ocm.software scripts: \u0026lt;name\u003e: path: \u0026lt;filepath\u003e script: \u0026lt;scriptdata\u003e Only one of the fields path or script can be used.\nIf no script option is given and the cli config defines a script default this one is used.\nExamples $ ocm transfer components -t tgz ghcr.io/open-component-model/ocm//ocm.software/ocmcli:0.17.0 ./ctf.tgz $ ocm transfer components --latest -t tgz --repo OCIRegistry::ghcr.io/open-component-model/ocm ocm.software/ocmcli ./ctf.tgz $ ocm transfer components --latest --copy-resources --type directory ghcr.io/open-component-model/ocm//ocm.software/ocmcli ./ctf\rSee Also ocm transfer\t— Transfer artifacts or components ","date":"0001-01-01","id":76,"permalink":"/docs/cli-reference/transfer/componentversions/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm transfer componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;} \u0026lt;target\u0026gt;\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -B, --bom-file string file name to write the component version BOM\n -c, --constraints constraints version constraint\n -L, --copy-local-resources transfer referenced local resources by-value\n -V, --copy-resources transfer referenced resources by-value\n --copy-sources transfer referenced sources by-value\n --disable-uploads disable standard upload handlers for transport\n --enforce enforce transport as if target version were not present\n -h, --help help for componentversions\n --latest restrict component versions to latest\n --lookup stringArray repository name or spec for closure lookup fallback\n --no-update don\u0026#39;t touch existing versions in target\n -N, --omit-access-types strings omit by-value transfer for resource types\n -f, --overwrite overwrite existing component versions\n -r, --recursive follow component reference nesting\n --repo string repository name or spec\n --script string config name of transfer handler script\n -s, --scriptFile string filename of transfer handler script\n -E, --stop-on-existing stop on existing component version in target repository\n -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\n --uploader \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; repository uploader (\u0026lt;name\u0026gt;[:\u0026lt;artifact type\u0026gt;[:\u0026lt;media type\u0026gt;[:\u0026lt;priority\u0026gt;]]]=\u0026lt;JSON target config\u0026gt;) (default [])\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eTransfer all component versions specified to the given target repository.\nIf only a component (instead of a component version) is specified all versions\nare transferred.\u003c/p\u003e","tags":[],"title":"componentversions"},{"content":"Usage ocm verify componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\rOptions -- enable verification store --ca-cert stringArray additional root certificate authorities (for signing certificates) -c, --constraints constraints version constraint -h, --help help for componentversions -I, --issuer stringArray issuer name or distinguished name (DN) (optionally for dedicated signature) ([\u0026lt;name\u0026gt;:=]\u0026lt;dn\u0026gt;) --keyless use keyless signing --latest restrict component versions to latest -L, --local verification based on information found in component versions, only --lookup stringArray repository name or spec for closure lookup fallback -K, --private-key stringArray private key setting -k, --public-key stringArray public key setting --repo string repository name or spec -s, --signature stringArray signature name --verified string file used to remember verifications for downloads (default \u0026#34;~/.ocm/verified\u0026#34;) -V, --verify verify existing digests\rDescription Verify signature of specified component versions.\nIf no signature name is given, only the digests are validated against the registered ones at the component version.\nIf the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry The \u0026ndash;public-key and \u0026ndash;private-key options can be used to define public and private keys on the command line. The options have an argument of the form [\u0026lt;name\u0026gt;=]\u0026lt;filepath\u0026gt;. The optional name specifies the signature name the key should be used for. By default, this is the signature name specified with the option \u0026ndash;signature.\nAlternatively a key can be specified as base64 encoded string if the argument start with the prefix ! or as direct string with the prefix =.\nIf the verification store is enabled, resources downloaded from signed or verified component versions are verified against their digests provided by the component version.(not supported for using downloaders for the resource download).\nThe usage of the verification store is enabled by \u0026ndash; or by specifying a verification file with \u0026ndash;verified.\nIf a component lookup for building a reference closure is required the \u0026ndash;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.\nExamples $ ocm verify componentversion --signature mysig --public-key=pub.key ghcr.io/open-component-model/ocm//ocm.software/ocm:0.17.0\rSee Also ocm verify\t— Verify component version signatures ","date":"0001-01-01","id":77,"permalink":"/docs/cli-reference/verify/componentversions/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm verify componentversions [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -- enable verification store\n --ca-cert stringArray additional root certificate authorities (for signing certificates)\n -c, --constraints constraints version constraint\n -h, --help help for componentversions\n -I, --issuer stringArray issuer name or distinguished name (DN) (optionally for dedicated signature) ([\u0026lt;name\u0026gt;:=]\u0026lt;dn\u0026gt;)\n --keyless use keyless signing\n --latest restrict component versions to latest\n -L, --local verification based on information found in component versions, only\n --lookup stringArray repository name or spec for closure lookup fallback\n -K, --private-key stringArray private key setting\n -k, --public-key stringArray public key setting\n --repo string repository name or spec\n -s, --signature stringArray signature name\n --verified string file used to remember verifications for downloads (default \u0026#34;~/.ocm/verified\u0026#34;)\n -V, --verify verify existing digests\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eVerify signature of specified component versions.\u003c/p\u003e","tags":[],"title":"componentversions"},{"content":"Usage ocm get config \u0026lt;options\u0026gt;\rOptions -h, --help help for config -O, --outfile string output file or directory -o, --output string output mode (JSON, json, yaml)\rDescription Evaluate the command line arguments and all explicitly or implicitly used configuration files and provide a single configuration object.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json yaml See Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":78,"permalink":"/docs/cli-reference/get/config/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get config \u0026lt;options\u0026gt;\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for config\n -O, --outfile string output file or directory\n -o, --output string output mode (JSON, json, yaml)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eEvaluate the command line arguments and all explicitly\nor implicitly used configuration files and provide\na single configuration object.\u003c/p\u003e","tags":[],"title":"config"},{"content":"Description The command line client supports configuring by a given configuration file. If existent, by default, the file $HOME/.ocmconfig will be read. Using the option \u0026ndash;config an alternative file can be specified.\nThe file format is yaml. It uses the same type mechanism used for all kinds of typed specification in the ocm area. The file must have the type of a configuration specification. Instead, the command line client supports a generic configuration specification able to host a list of arbitrary configuration specifications. The type for this spec is generic.config.ocm.software/v1.\nThe following configuration types are supported:\nattributes.config.ocm.software The config type attributes.config.ocm.software can be used to define a list of arbitrary attribute specifications:\ntype: attributes.config.ocm.software attributes: \u0026lt;name\u003e: \u0026lt;yaml defining the attribute\u003e ... cli.ocm.config.ocm.software The config type cli.ocm.config.ocm.software is used to handle the main configuration flags of the OCM command line tool.\ntype: cli.ocm.config.ocm.software aliases: \u0026lt;name\u003e: \u0026lt;OCI registry specification\u003e ... credentials.config.ocm.software The config type credentials.config.ocm.software can be used to define a list of arbitrary configuration specifications:\ntype: credentials.config.ocm.software consumers: - identity: \u0026lt;name\u003e: \u0026lt;value\u003e ... credentials: - \u0026lt;credential specification\u003e ... credential chain repositories: - repository: \u0026lt;repository specification\u003e credentials: - \u0026lt;credential specification\u003e ... credential chain aliases: \u0026lt;name\u003e: repository: \u0026lt;repository specification\u003e credentials: - \u0026lt;credential specification\u003e ... credential chain downloader.ocm.config.ocm.software The config type downloader.ocm.config.ocm.software can be used to define a list of preconfigured download handler registrations (see ocm ocm-downloadhandlers), the default priority is 200:\ntype: downloader.ocm.config.ocm.software description: \"my standard download handler configuration\" registrations: - name: oci/artifact artifactType: ociImage mimeType: ... description: ... priority: ... config: ... ... generic.config.ocm.software The config type generic.config.ocm.software can be used to define a list of arbitrary configuration specifications and named configuration sets:\ntype: generic.config.ocm.software configurations: - type: \u0026lt;any config type\u003e ... ... sets: standard: description: my selectable standard config configurations: - type: ... ... ... Configurations are directly applied. Configuration sets are just stored in the configuration context and can be applied on-demand. On the CLI, this can be done using the main command option \u0026ndash;config-set \u0026lt;name\u0026gt;.\nhasher.config.ocm.software The config type hasher.config.ocm.software can be used to define the default hash algorithm used to calculate digests for resources. It supports the field hashAlgorithm, with one of the following values:\nNO-DIGEST SHA-256 (default) SHA-512 keys.config.ocm.software The config type keys.config.ocm.software can be used to define public and private keys. A key value might be given by one of the fields:\npath: path of file with key data data: base64 encoded binary data stringdata: data a string parsed by key handler type: keys.config.ocm.software privateKeys: \u0026lt;name\u003e: path: \u0026lt;file path\u003e ... publicKeys: \u0026lt;name\u003e: data: \u0026lt;base64 encoded key representation\u003e ... rootCertificates: - path: \u0026lt;file path\u003e issuers: \u0026lt;name\u003e: commonName: acme.org Issuers define an expected distinguished name for public key certificates optionally provided together with signatures. They support the following fields:\ncommonName string organization string array organizationalUnit string array country string array locality string array province string array streetAddress string array postalCode string array At least the given values must be present in the certificate to be accepted for a successful signature validation.\nlogging.config.ocm.software The config type logging.config.ocm.software can be used to configure the logging aspect of a dedicated context type:\ntype: logging.config.ocm.software contextType: attributes.context.ocm.software settings: defaultLevel: Info rules: - ... The context type attributes.context.ocm.software is the root context of a context hierarchy.\nIf no context type is specified, the config will be applies to any target acting as logging context provider, which is not a non-root context.\nmemory.credentials.config.ocm.software The config type memory.credentials.config.ocm.software can be used to define a list of arbitrary credentials stored in a memory based credentials repository:\ntype: memory.credentials.config.ocm.software repoName: default credentials: - credentialsName: ref reference: # refer to a credential set stored in some other credential repository type: Credentials # this is a repo providing just one explicit credential set properties: username: mandelsoft password: specialsecret - credentialsName: direct credentials: # direct credential specification username: mandelsoft2 password: specialsecret2 merge.config.ocm.software The config type merge.config.ocm.software can be used to set some assignments for the merging of (label) values. It applies to a value merge handler registry, either directly or via an OCM context.\ntype: merge.config.ocm.software labels: - name: acme.org/audit/level merge: algorithm: acme.org/audit config: ... assignments: label:acme.org/audit/level@v1: algorithm: acme.org/audit config: ... ... oci.config.ocm.software The config type oci.config.ocm.software can be used to define OCI registry aliases:\ntype: oci.config.ocm.software aliases: \u0026lt;name\u003e: \u0026lt;OCI registry specification\u003e ... ocm.cmd.config.ocm.software The config type ocm.cmd.config.ocm.software can be used to configure predefined aliases for dedicated OCM repositories and OCI registries.\ntype: ocm.cmd.config.ocm.software ocmRepositories: \u0026lt;name\u003e: \u0026lt;specification of OCM repository\u003e ... ociRepositories: \u0026lt;name\u003e: \u0026lt;specification of OCI registry\u003e ... ocm.config.ocm.software The config type ocm.config.ocm.software can be used to set some configurations for an OCM context;\ntype: ocm.config.ocm.software aliases: myrepo: type: \u0026lt;any repository type\u003e \u0026lt;specification attributes\u003e ... resolvers: - repository: type: \u0026lt;any repository type\u003e \u0026lt;specification attributes\u003e ... prefix: ghcr.io/open-component-model/ocm priority: 10 With aliases repository alias names can be mapped to a repository specification. The alias name can be used in a string notation for an OCM repository.\nResolvers define a list of OCM repository specifications to be used to resolve dedicated component versions. These settings are used to compose a standard component version resolver provided for an OCM context. Optionally, a component name prefix can be given. It limits the usage of the repository to resolve only components with the given name prefix (always complete name segments). An optional priority can be used to influence the lookup order. Larger value means higher priority (default 10).\nAll matching entries are tried to lookup a component version in the following order:\nhighest priority first longest matching sequence of component name segments first. If resolvers are defined, it is possible to use component version names on the command line without a repository. The names are resolved with the specified resolution rule. They are also used as default lookup repositories to lookup component references for recursive operations on component versions (\u0026ndash;lookup option).\nplugin.config.ocm.software The config type plugin.config.ocm.software can be used to configure a plugin.\ntype: plugin.config.ocm.software plugin: \u0026lt;plugin name\u003e config: \u0026lt;arbitrary configuration structure\u003e disableAutoRegistration: \u0026lt;boolean flag to disable auto registration for up- and download handlers\u003e rootcerts.config.ocm.software The config type rootcerts.config.ocm.software can be used to define general root certificates. A certificate value might be given by one of the fields:\npath: path of file with key data data: base64 encoded binary data stringdata: data a string parsed by key handler rootCertificates: - path: \u0026lt;file path\u003e scripts.ocm.config.ocm.software The config type scripts.ocm.config.ocm.software can be used to define transfer scripts:\ntype: scripts.ocm.config.ocm.software scripts: \u0026lt;name\u003e: path: \u0026lt;\u003efile path\u003e \u0026lt;other name\u003e: script: \u0026lt;\u003enested script as yaml\u003e transport.ocm.config.ocm.software The config type transport.ocm.config.ocm.software can be used to define transfer scripts:\ntype: transport.ocm.config.ocm.software recursive: true overwrite: true localResourcesByValue: false resourcesByValue: true sourcesByValue: false keepGlobalAccess: false stopOnExistingVersion: false omitAccessTypes: - s3 uploader.ocm.config.ocm.software The config type uploader.ocm.config.ocm.software can be used to define a list of preconfigured upload handler registrations (see ocm ocm-uploadhandlers), the default priority is 200:\ntype: uploader.ocm.config.ocm.software description: \"my standard upload handler configuration\" registrations: - name: oci/artifact artifactType: ociImage config: ociRef: ghcr.io/open-component-model/... ... Examples type: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software repositories: - repository: type: DockerConfig/v1 dockerConfigFile: \u0026#34;~/.docker/config.json\u0026#34; propagateConsumerIdentity: true - type: attributes.config.ocm.software attributes: # map of attribute settings compat: true # - type: scripts.ocm.config.ocm.software # scripts: # \u0026#34;default\u0026#34;: # script: # process: true\rSee Also ","date":"0001-01-01","id":79,"permalink":"/docs/cli-reference/help/configfile/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eThe command line client supports configuring by a given configuration file.\nIf existent, by default, the file \u003ccode\u003e$HOME/.ocmconfig\u003c/code\u003e will be read.\nUsing the option \u003ccode\u003e\u0026ndash;config\u003c/code\u003e an alternative file can be specified.\u003c/p\u003e","tags":[],"title":"configfile"},{"content":"","date":"0001-01-01","id":80,"permalink":"/contributors/","summary":"","tags":[],"title":"Contributors"},{"content":"Usage ocm create [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for create\rSee Also Sub Commands ocm create componentarchive\t— create new component archive ocm create rsakeypair\t— create RSA public key pair ocm create transportarchive\t— create new OCI/OCM transport archive ","date":"0001-01-01","id":81,"permalink":"/docs/cli-reference/create/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm create [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for create\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/create/componentarchive/\"\u003eocm create \u003cb\u003ecomponentarchive\u003c/b\u003e\u003c/a\u003e\t — create new component archive\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/create/rsakeypair/\"\u003eocm create \u003cb\u003ersakeypair\u003c/b\u003e\u003c/a\u003e\t — create RSA public key pair\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/create/transportarchive/\"\u003eocm create \u003cb\u003etransportarchive\u003c/b\u003e\u003c/a\u003e\t — create new OCI/OCM transport archive\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"create"},{"content":"Description In contrast to libraries intended for a dedicated technical environment, for example the handling of OCI images in OCI registries, the OCM ecosystem cannot provide a specialized credential management for a dedicated environment.\nBecause of its extensibility working with component versions could require access to any kind of technical system, either for storing the model elements in a storage backend, or for accessing content in any kind of technical storage system. There are several kinds of credential consumers with potentially completely different kinds of credentials. Therefore, a common uniform credential management is required, capable to serve all those use cases.\nThis credential management brings together various kinds of credential consumers, for example the access to artifacts in OCI registries or accessing Git repository content, and credential providers, like vaults or local files in the filesystem (for example a technology specific credential source like the docker config json file for accessing OCI registries).\nThe used credential management model is based on four elements:\nCredentials:\nCredentials are described property set (key/value pairs).\nConsumer Ids\nBecause of the extensible nature of the OCM model, credential consumers must be formally identified. A consumer id described a concrete access, which must be authorized.\nThis is again achieved by a set of simple named attributes. There is only one defined property, which must always be present, the type attribute. It denotes the type of the technical environment credentials are required for. For example, for accessing OCI or Git registries. Additionally, there may be any number of arbitrary attributes used to describe the concrete instance of such an environment and access paths in this environment, which should be accessed (for example the OCI registry URL to describe the instance and the repository path for the set of objects, which should be accessed)\nThere are two use cases for consumer ids:\nCredential Request. They are used by a credential consumer to issue a credential request to the credential management. Hereby, they describe the concrete element, which should accessed. Credential Assignment. The credential management allows to assign credentials to consumer ids Credential Providers or repositories\nCredential repositories are dedicated kinds of implementations, which provide access to names sets of credentials stored in any kind of technical environment, for example a vault or a credentials somewhere on the local filesystem.\nIdentity Matchers\nThe credential management must resolve credential requests against a set of credential assignments. This is not necessarily a complete attribute match for the involved consumer ids. There is typically some kind of matching involved. For example, an assignment is done for an OCI registry with a dedicated server url and prefix for the repository path (type is OCIRegistry, host is ghcr.io, prefix path is open-component-model). The assigned credentials should be applicable for sub repositories. So the assignment uses a more general consumer id than the concrete credential request (for example for repository path open-component-model/ocm/ocmcli)\nThis kind of matching depend on the used attribute and is therefore in general type specific. Therefore, every consumer type uses an own identity matcher, which is then used by the credential management to find the best matching assignment.\nThe general process for a credential management then looks as follows.\ncredentials provided by credential repositories are assigned to generalized consumer ids. a concrete access operation for a technical environment calculates a detailed consumer id for the element, which should be accessed it asks the credential management for credentials for this id the management examines all defined assignments to find the best matching one based on the provided matching mechanism. it then returns the mapped credentials from the references repository. The critical task for a user of the toolset is to define those assignments. This is basically a manual task, because the credentials stored in vault (for example) could be usable for any kind of system, which typically cannot be derived from the credential values.\nBut luckily, those could partly be automated:\nthere may be credential providers, which are technology specific, for example the docker config json is used to describe credentials for OCI registries. Such providers can automatically assign the found credentials to appropriate consumer ids. If the credential store has the possibility to store custom meta data for a credential set, this metadata can be used to describe the intended consumer ids. The provider implementation then uses this info create the appropriate assignments. Consumer Types and Matchers The following credential consumer types are used/supported:\nBuildcredentials.ocm.software: Gardener config credential matcher\nIt matches the Buildcredentials.ocm.software consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type Buildcredentials.ocm.software evaluate the following credential properties:\nkey: secret key use to access the credential server Github: GitHub credential matcher\nThis matcher is a hostpath matcher.\nCredential consumers of the consumer type Github evaluate the following credential properties:\ntoken: GitHub personal access token HashiCorpVault: HashiCorp Vault credential matcher\nThis matcher matches credentials for a HashiCorp vault instance. It uses the following identity attributes:\nhostname: vault server host scheme: (optional) URL scheme port: (optional) server port namespace: vault namespace mountPath: mount path pathprefix: path prefix for secret Credential consumers of the consumer type HashiCorpVault evaluate the following credential properties:\nauthmeth: auth method token: vault token roleid: app-role role id secretid: app-role secret id The only supported auth methods, so far, are token and approle.\nHelmChartRepository: Helm chart repository\nIt matches the HelmChartRepository consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type HelmChartRepository evaluate the following credential properties:\nusername: the basic auth user name password: the basic auth password certificate: TLS client certificate privateKey: TLS private key certificateAuthority: TLS certificate authority MavenRepository: MVN repository\nIt matches the MavenRepository consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type MavenRepository evaluate the following credential properties:\nusername: the basic auth user name password: the basic auth password NpmRegistry: NPM registry\nIt matches the NpmRegistry consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type NpmRegistry evaluate the following credential properties:\nusername: the basic auth user name password: the basic auth password email: NPM registry, require an email address token: the token attribute. May exist after login at any npm registry. Check your .npmrc file! OCIRegistry: OCI registry credential matcher\nIt matches the OCIRegistry consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type OCIRegistry evaluate the following credential properties:\nusername: the basic auth username password: the basic auth password identityToken: the bearer token used for non-basic auth authorization certificateAuthority: the certificate authority certificate used to verify certificates S3: S3 credential matcher\nThis matcher is a hostpath matcher.\nCredential consumers of the consumer type S3 evaluate the following credential properties:\nawsAccessKeyID: AWS access key id awsSecretAccessKey: AWS secret for access key id token: AWS access token (alternatively) Signingserver.gardener.cloud: signing service credential matcher\nThis matcher matches credentials for a Signing Service instance. It uses the following identity attributes:\nhostname: signing server host scheme: (optional) URL scheme port: (optional) server port pathprefix: path prefix for the server URL Credential consumers of the consumer type Signingserver.gardener.cloud evaluate the following credential properties:\nclientCert: client certificate for authentication privateKey: private key for client certificate caCerts: root certificate for signing server wget: wget credential matcher\nIt matches the wget consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type wget evaluate the following credential properties:\nusername: the basic auth user name password: the basic auth password identityToken: the bearer token used for non-basic auth authorization certificateAuthority: the certificate authority certificate used to verify certificates presented by the server certificate: the certificate used to present to the server privateKey: the private key corresponding to the certificate Those consumer types provide their own matchers, which are often based on some standard generic matches. Those generic matchers and their behaviors are described in the following list:\nexact: exact match of given pattern set\nhostpath: Host and path based credential matcher\nThis matcher works on the following properties:\ntype (required if set in pattern): the identity type hostname (required if set in pattern): the hostname of a server scheme (optional): the URL scheme of a server port (optional): the port of a server pathprefix (optional): a path prefix to match. The element with the most matching path components is selected (separator is /). partial: complete match of given pattern ignoring additional attributes\nCredential Providers Credential providers offer sets of named credentials from various sources, which might be directly mapped to consumer identities (if supported by the provider type).\nThe type Credentials can be used to inline credentials in credential configuration objects to configure mappings of consumer identities to a credential set (see ocm configfile).\nThe following types are currently available:\nCredential provider Credentials\nThis repository type can be used to specify a single inline credential set. The default name is the empty string or Credentials.\nThe following versions are supported:\nVersion v1\nThe repository specification supports the following fields:\nproperties: map[string]string: direct credential fields Credential provider DockerConfig\nThis repository type can be used to access credentials stored in a file following the docker config json format. It take into account the credentials helper section, also. If enabled, the described credentials will be automatically assigned to appropriate consumer ids.\nThe following versions are supported:\nVersion v1\nThe repository specification supports the following fields:\ndockerConfigFile: string: the file path to a docker config file dockerConfig: json: an embedded docker config json propagateConsumerIdentity: bool(optional): enable consumer id propagation Credential provider HashiCorpVault\nThis repository type can be used to access credentials stored in a HashiCorp Vault.\nIt provides access to list of secrets stored under a dedicated path in a vault namespace. This list can either explicitly be specified, or it is taken from the metadata of a specified secret.\nThe following custom metadata attributes are evaluated:\nsecrets this attribute may contain a comma separated list of vault secrets, which should be exposed by this repository instance. The names are evaluated under the path prefix used for the repository. consumerId this attribute may contain a JSON encoded consumer id , this secret should be assigned to. type if no special attribute is defined this attribute indicated to use the complete custom metadata as consumer id. It uses the HashiCorpVault identity matcher and consumer type to requests credentials for the access.\nThis matcher matches credentials for a HashiCorp vault instance. It uses the following identity attributes:\nhostname: vault server host scheme: (optional) URL scheme port: (optional) server port namespace: vault namespace mountPath: mount path pathprefix: path prefix for secret It requires the following credential attributes:\nauthmeth: auth method token: vault token roleid: app-role role id secretid: app-role secret id The only supported auth methods, so far, are token and approle.\nThe following versions are supported:\nVersion v1\nThe repository specification supports the following fields:\nserverURL: string (required): the URL of the vault instance namespace: string (optional): the namespace used to evaluate secrets mountPath: string (optional): the mount path to use (default: secrets) path: string (optional): the path prefix used to lookup secrets secrets: []string (optional): list of secrets propagateConsumerIdentity: bool(optional): evaluate metadata for consumer id propagation If the secrets list is empty, all secret entries found in the given path is read.\nCredential provider NPMConfig\nThis repository type can be used to access credentials stored in a file following the NPM npmrc format (~/.npmrc). It take into account the credentials helper section, also. If enabled, the described credentials will be automatically assigned to appropriate consumer ids.\nThe following versions are supported:\nVersion v1\nThe repository specification supports the following fields:\nnpmrcFile: string: the file path to a NPM npmrc file propagateConsumerIdentity: bool(optional): enable consumer id propagation See Also ","date":"0001-01-01","id":82,"permalink":"/docs/cli-reference/help/credential-handling/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eIn contrast to libraries intended for a dedicated technical environment,\nfor example the handling of OCI images in OCI registries, the OCM\necosystem cannot provide a specialized credential management for a dedicated\nenvironment.\u003c/p\u003e","tags":[],"title":"credential-handling"},{"content":"Usage ocm get credentials {\u0026lt;consumer property\u0026gt;=\u0026lt;value\u0026gt;}\rOptions -h, --help help for credentials -m, --matcher string matcher type override -s, --sloppy sloppy matching of consumer type\rDescription Try to resolve a given consumer specification against the configured credential settings and show the found credential attributes.\nMatchers exist for the following usage contexts or consumer types:\nBuildcredentials.ocm.software: Gardener config credential matcher\nIt matches the Buildcredentials.ocm.software consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type Buildcredentials.ocm.software evaluate the following credential properties:\nkey: secret key use to access the credential server Github: GitHub credential matcher\nThis matcher is a hostpath matcher.\nCredential consumers of the consumer type Github evaluate the following credential properties:\ntoken: GitHub personal access token HashiCorpVault: HashiCorp Vault credential matcher\nThis matcher matches credentials for a HashiCorp vault instance. It uses the following identity attributes:\nhostname: vault server host scheme: (optional) URL scheme port: (optional) server port namespace: vault namespace mountPath: mount path pathprefix: path prefix for secret Credential consumers of the consumer type HashiCorpVault evaluate the following credential properties:\nauthmeth: auth method token: vault token roleid: app-role role id secretid: app-role secret id The only supported auth methods, so far, are token and approle.\nHelmChartRepository: Helm chart repository\nIt matches the HelmChartRepository consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type HelmChartRepository evaluate the following credential properties:\nusername: the basic auth user name password: the basic auth password certificate: TLS client certificate privateKey: TLS private key certificateAuthority: TLS certificate authority MavenRepository: MVN repository\nIt matches the MavenRepository consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type MavenRepository evaluate the following credential properties:\nusername: the basic auth user name password: the basic auth password NpmRegistry: NPM registry\nIt matches the NpmRegistry consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type NpmRegistry evaluate the following credential properties:\nusername: the basic auth user name password: the basic auth password email: NPM registry, require an email address token: the token attribute. May exist after login at any npm registry. Check your .npmrc file! OCIRegistry: OCI registry credential matcher\nIt matches the OCIRegistry consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type OCIRegistry evaluate the following credential properties:\nusername: the basic auth username password: the basic auth password identityToken: the bearer token used for non-basic auth authorization certificateAuthority: the certificate authority certificate used to verify certificates S3: S3 credential matcher\nThis matcher is a hostpath matcher.\nCredential consumers of the consumer type S3 evaluate the following credential properties:\nawsAccessKeyID: AWS access key id awsSecretAccessKey: AWS secret for access key id token: AWS access token (alternatively) Signingserver.gardener.cloud: signing service credential matcher\nThis matcher matches credentials for a Signing Service instance. It uses the following identity attributes:\nhostname: signing server host scheme: (optional) URL scheme port: (optional) server port pathprefix: path prefix for the server URL Credential consumers of the consumer type Signingserver.gardener.cloud evaluate the following credential properties:\nclientCert: client certificate for authentication privateKey: private key for client certificate caCerts: root certificate for signing server wget: wget credential matcher\nIt matches the wget consumer type and additionally acts like the hostpath type.\nCredential consumers of the consumer type wget evaluate the following credential properties:\nusername: the basic auth user name password: the basic auth password identityToken: the bearer token used for non-basic auth authorization certificateAuthority: the certificate authority certificate used to verify certificates presented by the server certificate: the certificate used to present to the server privateKey: the private key corresponding to the certificate The following standard identity matchers are supported:\nexact: exact match of given pattern set\nhostpath: Host and path based credential matcher\nThis matcher works on the following properties:\ntype (required if set in pattern): the identity type hostname (required if set in pattern): the hostname of a server scheme (optional): the URL scheme of a server port (optional): the port of a server pathprefix (optional): a path prefix to match. The element with the most matching path components is selected (separator is /). partial (default): complete match of given pattern ignoring additional attributes\nThe used matcher is derived from the consumer attribute type. For all other consumer types a matcher matching all attributes will be used. The usage of a dedicated matcher can be enforced by the option \u0026ndash;matcher.\nSee Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":83,"permalink":"/docs/cli-reference/get/credentials/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get credentials {\u0026lt;consumer property\u0026gt;=\u0026lt;value\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for credentials\n -m, --matcher string matcher type override\n -s, --sloppy sloppy matching of consumer type\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eTry to resolve a given consumer specification against the configured credential\nsettings and show the found credential attributes.\u003c/p\u003e","tags":[],"title":"credentials"},{"content":"Usage ocm describe [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for describe\rSee Also Sub Commands ocm describe artifacts\t— describe artifact version ocm describe cache\t— show OCI blob cache information ocm describe package\t— describe TOI package ocm describe plugins\t— get plugins ","date":"0001-01-01","id":84,"permalink":"/docs/cli-reference/describe/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm describe [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for describe\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/describe/artifacts/\"\u003eocm describe \u003cb\u003eartifacts\u003c/b\u003e\u003c/a\u003e\t — describe artifact version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/describe/cache/\"\u003eocm describe \u003cb\u003ecache\u003c/b\u003e\u003c/a\u003e\t — show OCI blob cache information\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/describe/package/\"\u003eocm describe \u003cb\u003epackage\u003c/b\u003e\u003c/a\u003e\t — describe TOI package\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/describe/plugins/\"\u003eocm describe \u003cb\u003eplugins\u003c/b\u003e\u003c/a\u003e\t — get plugins\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"describe"},{"content":"Usage ocm download [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for download\rSee Also Sub Commands ocm download artifacts\t— download oci artifacts ocm download cli\t— download OCM CLI from an OCM repository ocm download componentversions\t— download ocm component versions ocm download resources\t— download resources of a component version ","date":"0001-01-01","id":85,"permalink":"/docs/cli-reference/download/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm download [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for download\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/download/artifacts/\"\u003eocm download \u003cb\u003eartifacts\u003c/b\u003e\u003c/a\u003e\t — download oci artifacts\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/download/cli/\"\u003eocm download \u003cb\u003ecli\u003c/b\u003e\u003c/a\u003e\t — download OCM CLI from an OCM repository\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/download/componentversions/\"\u003eocm download \u003cb\u003ecomponentversions\u003c/b\u003e\u003c/a\u003e\t — download ocm component versions\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/download/resources/\"\u003eocm download \u003cb\u003eresources\u003c/b\u003e\u003c/a\u003e\t — download resources of a component version\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"download"},{"content":"Usage ocm get [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for get\rSee Also Sub Commands ocm get artifacts\t— get artifact version ocm get componentversions\t— get component version ocm get config\t— Get evaluated config for actual command call ocm get credentials\t— Get credentials for a dedicated consumer spec ocm get plugins\t— get plugins ocm get pubsub\t— Get the pubsub spec for an ocm repository ocm get references\t— get references of a component version ocm get resources\t— get resources of a component version ocm get routingslips\t— get routings slips for a component version ocm get sources\t— get sources of a component version ocm get verified\t— get verified component versions ","date":"0001-01-01","id":86,"permalink":"/docs/cli-reference/get/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for get\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/artifacts/\"\u003eocm get \u003cb\u003eartifacts\u003c/b\u003e\u003c/a\u003e\t — get artifact version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/componentversions/\"\u003eocm get \u003cb\u003ecomponentversions\u003c/b\u003e\u003c/a\u003e\t — get component version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/config/\"\u003eocm get \u003cb\u003econfig\u003c/b\u003e\u003c/a\u003e\t — Get evaluated config for actual command call\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/credentials/\"\u003eocm get \u003cb\u003ecredentials\u003c/b\u003e\u003c/a\u003e\t — Get credentials for a dedicated consumer spec\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/plugins/\"\u003eocm get \u003cb\u003eplugins\u003c/b\u003e\u003c/a\u003e\t — get plugins\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/pubsub/\"\u003eocm get \u003cb\u003epubsub\u003c/b\u003e\u003c/a\u003e\t — Get the pubsub spec for an ocm repository\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/references/\"\u003eocm get \u003cb\u003ereferences\u003c/b\u003e\u003c/a\u003e\t — get references of a component version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/resources/\"\u003eocm get \u003cb\u003eresources\u003c/b\u003e\u003c/a\u003e\t — get resources of a component version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/routingslips/\"\u003eocm get \u003cb\u003eroutingslips\u003c/b\u003e\u003c/a\u003e\t — get routings slips for a component version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/get/sources/\"\u003eocm get \u003cb\u003esources\u003c/b\u003e\u003c/a\u003e\t — get sources of a component version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"\"\u003eocm get \u003cb\u003everified\u003c/b\u003e\u003c/a\u003e\t — get verified component versions\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"get"},{"content":"Usage ocm sign hash \u0026lt;private key file\u0026gt; \u0026lt;hash\u0026gt; [\u0026lt;issuer\u0026gt;]\rOptions -S, --algorithm string signature algorithm (default \u0026#34;RSASSA-PKCS1-V1_5\u0026#34;) --ca-cert stringArray additional root certificate authorities (for signing certificates) -h, --help help for hash --publicKey string public key certificate file --rootCerts string root certificates file (deprecated)\rDescription Print the signature for a dedicated digest value.\nExamples $ ocm sign hash key.priv SHA-256:810ff2fb242a5dee4220f2cb0e6a519891fb67f2f828a6cab4ef8894633b1f50\rSee Also ocm sign\t— Sign components or hashes ","date":"0001-01-01","id":87,"permalink":"/docs/cli-reference/sign/hash/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm sign hash \u0026lt;private key file\u0026gt; \u0026lt;hash\u0026gt; [\u0026lt;issuer\u0026gt;]\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -S, --algorithm string signature algorithm (default \u0026#34;RSASSA-PKCS1-V1_5\u0026#34;)\n --ca-cert stringArray additional root certificate authorities (for signing certificates)\n -h, --help help for hash\n --publicKey string public key certificate file\n --rootCerts string root certificates file (deprecated)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003ePrint the signature for a dedicated digest value.\u003c/p\u003e","tags":[],"title":"hash"},{"content":"Additional Topics attributes — attributes configfile — configfile credential-handling — credential-handling logging — logging oci-references — oci-references ocm-accessmethods — ocm-accessmethods ocm-downloadhandlers — ocm-downloadhandlers ocm-labels — ocm-labels ocm-pubsub — ocm-pubsub ocm-references — ocm-references ocm-uploadhandlers — ocm-uploadhandlers toi-bootstrapping — toi-bootstrapping ","date":"0001-01-01","id":88,"permalink":"/docs/cli-reference/help/","summary":"\u003ch3 id=\"additional-topics\"\u003eAdditional Topics\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/attributes/\"\u003eattributes\u003c/a\u003e — attributes\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/configfile/\"\u003econfigfile\u003c/a\u003e — configfile\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/credential-handling/\"\u003ecredential-handling\u003c/a\u003e — credential-handling\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/logging/\"\u003elogging\u003c/a\u003e — logging\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/oci-references/\"\u003eoci-references\u003c/a\u003e — oci-references\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/ocm-accessmethods/\"\u003eocm-accessmethods\u003c/a\u003e — ocm-accessmethods\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/ocm-downloadhandlers/\"\u003eocm-downloadhandlers\u003c/a\u003e — ocm-downloadhandlers\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/ocm-labels/\"\u003eocm-labels\u003c/a\u003e — ocm-labels\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/ocm-pubsub/\"\u003eocm-pubsub\u003c/a\u003e — ocm-pubsub\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/ocm-references/\"\u003eocm-references\u003c/a\u003e — ocm-references\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/ocm-uploadhandlers/\"\u003eocm-uploadhandlers\u003c/a\u003e — ocm-uploadhandlers\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/help/toi-bootstrapping/\"\u003etoi-bootstrapping\u003c/a\u003e — toi-bootstrapping\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"help"},{"content":"Usage ocm list [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for list\rSee Also Sub Commands ocm list componentversions\t— list component version names ","date":"0001-01-01","id":89,"permalink":"/docs/cli-reference/list/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm list [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for list\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/list/componentversions/\"\u003eocm list \u003cb\u003ecomponentversions\u003c/b\u003e\u003c/a\u003e\t — list component version names\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"list"},{"content":"Description Logging can be configured as part of the ocm config file (ocm configfile) or by command line options of the ocm command. Details about the YAML structure of a logging settings can be found on https://github.com/mandelsoft/logging.\nThe command line also supports some quick-config options for enabling log levels for dedicated tags and realms or realm prefixes (logging keys).\nThe following tags are used by the command line tool:\nblobhandler: execution of blob handler used to upload resource blobs to an ocm repository. cd-diff: component descriptor modification The following realms are used by the command line tool:\nocm: general realm used for the ocm go library. ocm/accessmethod/ociartifact: access method ociArtifact ocm/accessmethod/wget: access method for wget ocm/blobaccess/wget: blob access for wget ocm/compdesc: component descriptor handling ocm/config: configuration management ocm/context: context lifecycle ocm/credentials: Credentials ocm/credentials/dockerconfig: docker config handling as credential repository ocm/credentials/vault: HashiCorp Vault Access ocm/downloader: Downloaders ocm/maven: Maven repository ocm/npm: NPM registry ocm/oci/docker: Docker repository handling ocm/oci/mapping: OCM to OCI Registry Mapping ocm/oci/ocireg: OCI repository handling ocm/plugins: OCM plugin handling ocm/processing: output processing chains ocm/refcnt: reference counting ocm/toi: TOI logging ocm/transfer: OCM transfer handling ocm/valuemerge: value marge handling Examples type: logging.config.ocm.software contextType: attributes.context.ocm.software settings: defaultLevel: Info rules: - ...\rSee Also ","date":"0001-01-01","id":90,"permalink":"/docs/cli-reference/help/logging/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eLogging can be configured as part of the ocm config file (\u003ca href=\"/docs/cli-reference/help/configfile/\"\u003eocm configfile\u003c/a\u003e)\nor by command line options of the \u003ca href=\"/docs/cli-reference/\"\u003eocm\u003c/a\u003e command. Details about\nthe YAML structure of a logging settings can be found on https://github.com/mandelsoft/logging.\u003c/p\u003e","tags":[],"title":"logging"},{"content":"Description The command line client supports a special notation scheme for specifying references to instances of oci like registries. This allows for specifying references to any registry supported by the OCM toolset that can host OCI artifacts. As a subset the regular OCI artifact notation used for docker images are possible:\n[+][\u0026lt;type\u003e::][./][\u0026lt;file path\u003e//\u0026lt;repository\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] or\n[+][\u0026lt;type\u003e::][\u0026lt;json repo spec\u003e//]\u0026lt;repository\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] Notice that if you specify the \u0026lt;type\u0026gt; in the beginning of this notation AND in the \u0026lt;json repo spec\u0026gt;, the types have to match (but there is no reason to specify the type in both places).\nor\n[+][\u0026lt;type\u003e::][\u0026lt;scheme\u003e://]\u0026lt;domain\u003e[:\u0026lt;port\u003e][/]/\u0026lt;repository\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] Notice that this notation optionally also allows a double slash to separate \u0026lt;domain\u0026gt;[:\u0026lt;port\u0026gt;] and \u0026lt;repository\u0026gt;. While it is not necessary for unambiguous parsing here, it is supported for consistency with the other notations.\nor\n[+][\u0026lt;type\u003e::][\u0026lt;scheme\u003e://]\u0026lt;host\u003e:\u0026lt;port\u003e/\u0026lt;repository\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] Notice that \u0026lt;port\u0026gt; is required in this notation. Without \u0026lt;port\u0026gt;, this notation would be ambiguous with the docker library notation mentioned below.\nor\n[+][\u0026lt;type\u003e::][\u0026lt;scheme\u003e://]\u0026lt;host\u003e[:\u0026lt;port\u003e]//\u0026lt;repository\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] Notice the double slash (//) before the \u0026lt;repository\u0026gt;. This serves as a clear separator between \u0026lt;host\u0026gt;[:\u0026lt;port\u0026gt;] and \u0026lt;repository\u0026gt;. Thus, with this notation, the port is optional and can therefore be omitted without creating ambiguity with the docker library notation mentioned below.\nor\n\u0026lt;docker library\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] or\n\u0026lt;docker repository\u003e/\u0026lt;docker image\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] Besides dedicated artifacts it is also possible to denote registries as a whole:\n[+][\u0026lt;type\u003e::][./]\u0026lt;file path\u003e or\n[+][\u0026lt;type\u003e::]\u0026lt;json repo spec\u003e Notice that if you specify the \u0026lt;type\u0026gt; in the beginning of this notation AND in the \u0026lt;json repo spec\u0026gt;, the types have to match (but there is no reason to specify the type in both places).\nor\n[+][\u0026lt;type\u003e::][\u0026lt;scheme\u003e://]\u0026lt;domain\u003e[:\u0026lt;port\u003e] or\n[+][\u0026lt;type\u003e::][\u0026lt;scheme\u003e://]\u0026lt;host\u003e[:\u0026lt;port\u003e] Notice that \u0026lt;port\u0026gt; is optional in this notation since this cannot be an image reference and therefore cannot be ambiguous with the docker library notation.\nThe optional + is used for file based implementations (Common Transport Format) to indicate the creation of a not yet existing file.\nThe type may contain a file format qualifier separated by a + character. The following formats are supported: directory, tar, tgz\nExamples +ctf+directory::./ocm/ctf//ocm.software/ocmcli/ocmcli-image:0.7.0@sha256:29c842be1ef1da67f6a1c07a3a3a8eb101bbcc4c80f174b87d147b341bca9625 oci::{\u0026#34;baseUrl\u0026#34;: \u0026#34;ghcr.io\u0026#34;}//open-component-model/ocm/ocm.software/ocmcli/ocmcli-image:0.7.0@sha256:29c842be1ef1da67f6a1c07a3a3a8eb101bbcc4c80f174b87d147b341bca9625 oci::https://ghcr.io/open-component-model/ocm/ocm.software/ocmcli/ocmcli-image:0.7.0@sha256:29c842be1ef1da67f6a1c07a3a3a8eb101bbcc4c80f174b87d147b341bca9625 oci::https://ghcr.io//open-component-model/ocm/ocm.software/ocmcli/ocmcli-image:0.7.0@sha256:29c842be1ef1da67f6a1c07a3a3a8eb101bbcc4c80f174b87d147b341bca9625 oci::http://localhost:8080/ocm.software/ocmcli/ocmcli-image:0.7.0@sha256:29c842be1ef1da67f6a1c07a3a3a8eb101bbcc4c80f174b87d147b341bca9625 oci::http://localhost:8080//ocm.software/ocmcli/ocmcli-image:0.7.0@sha256:29c842be1ef1da67f6a1c07a3a3a8eb101bbcc4c80f174b87d147b341bca9625 ubuntu:24.04 ubuntu tensorflow/tensorflow:2.15.0 tensorflow/tensorflow\rSee Also ","date":"0001-01-01","id":91,"permalink":"/docs/cli-reference/help/oci-references/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eThe command line client supports a special notation scheme for specifying\nreferences to instances of oci like registries. This allows for specifying\nreferences to any registry supported by the OCM toolset that can host OCI\nartifacts. As a subset the regular OCI artifact notation used for docker\nimages are possible:\u003c/p\u003e","tags":[],"title":"oci-references"},{"content":"Description Access methods are used to handle the access to the content of artifacts described in a component version. Therefore, an artifact entry contains an access specification describing the access attributes for the dedicated artifact.\nThe following list describes the supported access methods, their versions and specification formats. Typically there is special support for the CLI artifact add commands. The access method specification can be put below the access field. If always requires the field type describing the kind and version shown below.\nAccess type gitHub\nThis method implements the access of the content of a git commit stored in a GitHub repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nRepository URL with or without scheme.\nref (optional) string\nOriginal ref used to get the commit from\ncommit string\nThe sha/id of the git commit\nOptions used to configure fields: \u0026ndash;accessHostname, \u0026ndash;accessRepository, \u0026ndash;commit\nAccess type helm\nThis method implements the access of a Helm chart stored in a Helm repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nhelmRepository string\nHelm repository URL.\nhelmChart string\nThe name of the Helm chart and its version separated by a colon.\nversion string\nThe version of the Helm chart if not specified as part of the chart name.\ncaCert string\nAn optional TLS root certificate.\nkeyring string\nAn optional keyring used to verify the chart.\nIt uses the consumer identity type HelmChartRepository with the fields for a hostpath identity matcher (see ocm get credentials).\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type localBlob\nThis method is used to store a resource blob along with the component descriptor on behalf of the hosting OCM repository.\nIts implementation is specific to the implementation of OCM repository used to read the component descriptor. Every repository implementation may decide how and where local blobs are stored, but it MUST provide an implementation for this method.\nRegardless of the chosen implementation the attribute specification is defined globally the same.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nlocalReference string\nRepository type specific location information as string. The value may encode any deep structure, but typically just an access path is sufficient.\nmediaType string\nThe media type of the blob used to store the resource. It may add format information like +tar or +gzip.\nreferenceName (optional) string\nThis optional attribute may contain identity information used by other repositories to restore some global access with an identity related to the original source.\nFor example, if an OCI artifact originally referenced using the access method ociArtifact is stored during some transport step as local artifact, the reference name can be set to its original repository name. An import step into an OCI based OCM repository may then decide to make this artifact available again as regular OCI artifact.\nglobalAccess (optional) access method specification\nIf a resource blob is stored locally, the repository implementation may decide to provide an external access information (independent of the OCM model).\nFor example, an OCI artifact stored as local blob can be additionally stored as regular OCI artifact in an OCI registry.\nThis additional external access information can be added using a second external access method specification.\nOptions used to configure fields: \u0026ndash;globalAccess, \u0026ndash;hint, \u0026ndash;mediaType, \u0026ndash;reference\nAccess type maven\nThis method implements the access of a Maven artifact in a Maven repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nURL of the Maven repository\ngroupId string\nThe groupId of the Maven artifact\nartifactId string\nThe artifactId of the Maven artifact\nversion string\nThe version name of the Maven artifact\nclassifier string\nThe optional classifier of the Maven artifact\nextension string\nThe optional extension of the Maven artifact\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;artifactId, \u0026ndash;classifier, \u0026ndash;extension, \u0026ndash;groupId\nAccess type none\ndummy resource with no access\nAccess type npm\nThis method implements the access of an NPM package in an NPM registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregistry string\nBase URL of the NPM registry.\npackage string\nThe name of the NPM package\nversion string\nThe version name of the NPM package\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type ociArtifact\nThis method implements the access of an OCI artifact stored in an OCI registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI image/artifact reference following the possible docker schemes:\n\u0026lt;repo\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;digest\u0026gt;@\u0026lt;tag\u0026gt; [\u0026lt;port\u0026gt;]/\u0026lt;repo path\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;version\u0026gt;@\u0026lt;tag\u0026gt; Options used to configure fields: \u0026ndash;reference\nAccess type ociBlob\nThis method implements the access of an OCI blob stored in an OCI repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI repository reference (this artifact name used to store the blob).\nmediaType string\nThe media type of the blob\ndigest string\nThe digest of the blob used to access the blob in the OCI repository.\nsize integer\nThe size of the blob\nOptions used to configure fields: \u0026ndash;digest, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;size\nAccess type ocm\nThis method implements the access of any resource artifact stored in an OCM repository. Only repository types supporting remote access should be used.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nocmRepository json\nThe repository spec for the OCM repository\ncomponent string\n(Optional) The name of the component. The default is the own component.\nversion string\n(Optional) The version of the component. The default is the own component version.\nresourceRef relative resource ref\nThe resource reference of the denoted resource relative to the given component version.\nIt uses the consumer identity and credentials for the intermediate repositories and the final resource access.\nOptions used to configure fields: \u0026ndash;accessComponent, \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;identityPath\nAccess type s3\nThis method implements the access of a blob stored in an S3 bucket.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucket string\nThe name of the S3 bucket containing the blob\nkey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nVersion v2\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucketName string\nThe name of the S3 bucket containing the blob\nobjectKey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nOptions used to configure fields: \u0026ndash;accessVersion, \u0026ndash;bucket, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;region\nAccess type wget\nThis method implements access to resources stored on an http server.\nThe following versions are supported:\nVersion v1\nThe url is the url pointing to the http endpoint from which a resource is downloaded. The mimeType can be used to specify the MIME type of the resource.\nThis blob type specification supports the following fields:\nurl string This REQUIRED property describes the url from which the resource is to be downloaded.\nmediaType string This OPTIONAL property describes the media type of the resource to be downloaded. If omitted, ocm tries to read the mediaType from the Content-Type header of the http response. If the mediaType cannot be set from the Content-Type header as well, ocm tries to deduct the mediaType from the URL. If that is not possible either, the default media type is defaulted to application/octet-stream.\nheader map[string][]string This OPTIONAL property describes the http headers to be set in the http request to the server.\nverb string This OPTIONAL property describes the http verb (also known as http request method) for the http request. If omitted, the http verb is defaulted to GET.\nbody []byte This OPTIONAL property describes the http body to be included in the request.\nnoredirect bool This OPTIONAL property describes whether http redirects should be disabled. If omitted, it is defaulted to false (so, per default, redirects are enabled).\nOptions used to configure fields: \u0026ndash;body, \u0026ndash;header, \u0026ndash;mediaType, \u0026ndash;noredirect, \u0026ndash;url, \u0026ndash;verb\nSee Also ","date":"0001-01-01","id":92,"permalink":"/docs/cli-reference/help/ocm-accessmethods/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAccess methods are used to handle the access to the content of artifacts\ndescribed in a component version. Therefore, an artifact entry contains\nan access specification describing the access attributes for the dedicated\nartifact.\u003c/p\u003e","tags":[],"title":"ocm-accessmethods"},{"content":"Description A download handler can be used to process resources to be downloaded from on OCM repository. By default, the blobs provided from the access method (see ocm ocm-accessmethods) are used to store the resource content in the local filesystem. Download handlers can be used to tweak this process. They get access to the blob content and decide on their own what to do with it, or how to transform it into files stored in the file system.\nFor example, a pre-registered helm download handler will store OCI-based helm artifacts as regular helm archives in the local file system.\nHandler Registration Programmatically any kind of handlers can be registered for various download conditions. But this feature is available as command-line option, also. New handlers can be provided by plugins. In general available handlers, plugin-based or as part of the CLI coding are nameable using an hierarchical namespace. Those names can be used by a \u0026ndash;downloader option to register handlers for various conditions for CLI commands like ocm download resources (implicitly registered download handlers can be enabled using the option -d).\nBesides the activation constraints (resource type and media type of the resource blob), it is possible to pass handler configuration controlling the exact behaviour of the handler for selected artifacts.\nThe following handler names are possible:\nhelm/artifact: download helm chart resources\nThe helm downloader is able to download helm chart resources as helm chart packages. Thus, the downloader may perform transformations. For example, if the helm chart is currently stored as an oci artifact, the downloader performs the necessary extraction to provide the helm chart package from within that oci artifact.\nThe following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar+gzip application/vnd.cncf.helm.chart.content.v1.tar+gzip It accepts no config.\nlandscaper/blueprint: uploading an OCI artifact to an OCI registry\nThe artifact downloader is able to transfer OCI artifact-like resources into an OCI registry given by the combination of the download target and the registration config.\nIf no config is given, the target must be an OCI reference with a potentially omitted repository. The repo part is derived from the reference hint provided by the resource\u0026rsquo;s access specification.\nIf the config is given, the target is used as repository name prefixed with an optional repository prefix given by the configuration.\nThe following artifact media types are supported:\napplication/vnd.docker.distribution.manifest.v2+tar application/vnd.docker.distribution.manifest.v2+tar+gzip application/vnd.gardener.landscaper.blueprint.layer.v1.tar application/vnd.gardener.landscaper.blueprint.layer.v1.tar+gzip application/vnd.gardener.landscaper.blueprint.v1+tar application/vnd.gardener.landscaper.blueprint.v1+tar+gzip application/vnd.oci.image.manifest.v1+tar application/vnd.oci.image.manifest.v1+tar+gzip application/x-tar application/x-tar+gzip application/x-tgz It accepts a config with the following fields:\nociConfigTypes: a list of accepted OCI config archive mime types defaulted by application/vnd.gardener.landscaper.blueprint.config.v1. This handler is by default registered for the following artifact types: landscaper.gardener.cloud/blueprint,blueprint\noci/artifact: downloading an OCI artifact and optionally re-uploading to an OCI registry\nThe artifact download resources stored as oci artifact. Furthermore, it allows to specify another OCI registry as download destination, thereby, providing a kind of transfer functionality.\nIf no config is given, the target must be an OCI reference with a potentially omitted repository. The repo part is derived from the reference hint provided by the resource\u0026rsquo;s access specification.\nIf the config is given, the target is used as repository name prefixed with an optional repository prefix given by the configuration.\nThe following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar+gzip application/vnd.oci.image.index.v1+tar+gzip It accepts a config with the following fields:\nnamespacePrefix: a namespace prefix used for the uploaded artifacts ociRef: an OCI repository reference repository: an OCI repository specification for the target OCI registry ocm/dirtree: downloading directory tree-like resources\nThe dirtree downloader is able to download directory-tree like resources as directory structure (default) or archive. The following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar+gzip application/x-tgz application/x-tar+gzip application/x-tar By default, it is registered for the following resource types:\ndirectoryTree filesystem It accepts a config with the following fields:\nasArchive: flag to request an archive download ociConfigTypes: a list of accepted OCI config archive mime types defaulted by application/vnd.oci.image.config.v1+json. plugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\nSee ocm ocm-downloadhandlers for further details on using download handlers.\nSee Also ","date":"0001-01-01","id":93,"permalink":"/docs/cli-reference/help/ocm-downloadhandlers/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eA download handler can be used to process resources to be downloaded from\non OCM repository. By default, the blobs provided from the access method\n(see \u003ca href=\"/docs/cli-reference/help/ocm-accessmethods/\"\u003eocm ocm-accessmethods\u003c/a\u003e) are used to store the resource content\nin the local filesystem. Download handlers can be used to tweak this process.\nThey get access to the blob content and decide on their own what to do\nwith it, or how to transform it into files stored in the file system.\u003c/p\u003e","tags":[],"title":"ocm-downloadhandlers"},{"content":"Description Labels are a set of arbitrary properties, which can be attached to elements of a component version:\na component version itself the provider of a component version resources sources component references The dedicated elements support this by providing a field labels, which is a list of label definitions. Every label definition has several fields:\nname string\nThe name of the label also determines the interpretation of its value. All labels with a dedicated name must have the same globally unique meaning, enabling a common understanding of label content for tools working of such properties of an element.\nThere are several predefined labels, they just use flat names. To guarantee globally unique meanings of labels a label name may have a hierarchical structure. Names defined in dedicated definition realms must be prefixed by a DNS domain-like string identifying the organization of realm defining the label\u0026rsquo;s value structure. For example: acme.org/maturity/level.\nHereby, the name defines the meaning of the value and its value structure. To support the evolution of the value structure a label field optionally contains a version field, which finally defines the concrete value structure in the context of the meaning of the label name. A version is just a number prefixed with a v. If not specified, the version v1 is assumed.\nversion string (optional) (default: v1)\nThe format version of the label value in the context of the label name.\nvalue any\nThe value of the label according to the specified format version of the label in the context of its name.\nsigning bool (optional)\nBy default, labels are not signature-relevant and they will nor influence the digest of the component version. This allows adding, deleting or modifying labels as part of a process chain during the lifecycle of a component version.\nLabels which should describe relevant and unmodifiable content can be marked to be signing relevant by setting this label field to true.\nmerge merge spec (optional)\nModifiable labels can be changed independently in any transport target location of a component version. This might require to update label values when importing a new setting for a component version. This means a merging of content to reflect the combination of changes in the transport source and target.\nThis is supported by the possibility to specify merge algorithms. The can be bound to a dedicated label incarnation or to the label name.\nMerge Specification A merge specification consists of two fields:\nalgorithm string (optional) (default: default)\nThe name of the algorithm to be used for the merge process.\nconfig any (optional)\nAn algorithm specific configuration to control the merge process.\nThere is an often used configuration field overwrite with a common meaning for all algorithms supporting it. It controls the conflict resolution and has the following values:\nnone: conflicting values prevent the merging. An update transfer process will be aborted.\nlocal: a conflict will be resolved to the local change (in the target environment)\ninbound: a conflict will be resolved to the value provided by the source environment\n\u0026lt;empty\u0026gt;: use a default provided by the dedicated algorithm.\nThe default behaviour might mean to apply a cascaded merge specification, if the merge specification supports to specify appropriate fields to specify this specification (for example a field entries).\nDetermining a Merge Specification A merge specification directly attached to a label is always preferred. If no algorithm is specified a merge assignment for the label name and its version is evaluated. The assignment hint is composed with\nlabel:\u0026lt;*label name*\u003e@%lt;version\u003e The label version is defaulted to v1.\nSupported Merge Algorithms There are some built-in algorithms featuring a flat name. But it will be possible to add arbitrary algorithms using the plugin concept.\nThe following algorithms are possible:\ndefault (default): This handler merges arbitrary label values by deciding for one or none side.\nIt supports the following config structure:\noverwrite string (optional) determines how to handle conflicts.\nnone no change possible, if entry differs the merge is rejected. local the local value is preserved. inbound (default) the inbound value overwrites the local one. mapListMerge: This handler merges values with a list of map values by observing a key field to identify similar map entries. The default entry key is taken from map field name.\nIt supports the following config structure:\nkeyField string (optional)\nthe key field to identify entries in the maps.\noverwrite string (optional) determines how to handle conflicts.\nnone (default) no change possible, if entry differs the merge is rejected. local the local value is preserved. inbound the inbound value overwrites the local one. *entries merge spec (optional)\nThe merge specification (algorithm and config) used to merge conflicting changes in list entries.\nsimpleListMerge: This handler merges simple list labels values.\nIt supports the following config structure:\noverwrite string (optional) determines how to handle conflicts. simpleMapMerge: This handler merges simple map labels values.\nIt supports the following config structure:\noverwrite string (optional) determines how to handle conflicts.\nnone (default) no change possible, if entry differs the merge is rejected. local the local value is preserved. inbound the inbound value overwrites the local one. *entries merge spec (optional)\nThe merge specification (algorithm and config) used to merge conflicting changes in map entries.\nThe following label assignments are configured:\nlabel:routing-slips: simpleMapMerge See Also ","date":"0001-01-01","id":94,"permalink":"/docs/cli-reference/help/ocm-labels/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eLabels are a set of arbitrary properties, which can be attached to elements\nof a component version:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ea component version itself\u003c/li\u003e\n\u003cli\u003ethe provider of a component version\u003c/li\u003e\n\u003cli\u003eresources\u003c/li\u003e\n\u003cli\u003esources\u003c/li\u003e\n\u003cli\u003ecomponent references\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe dedicated elements support this by providing a field \u003ccode\u003elabels\u003c/code\u003e,\nwhich is a list of label definitions. Every label definition has several fields:\u003c/p\u003e","tags":[],"title":"ocm-labels"},{"content":"Description An OCM repository can be configured to propagate change events via a publish/subscribe system, if there is a persistence provider for the dedicated repository type. If available any known publish/subscribe system can be configured with ocm set pubsub and shown with ocm get pubsub. Hereby, the pub/sub system is described by a typed specification.\nThe following list describes the supported publish/subscribe system types, their specification versions, and formats:\nPubSub type compound\nA pub/sub system forwarding events to described sub-level systems.\nThe following versions are supported:\nVersion v1\nIt is described by the following field:\nspecifications list of pubsub specs\nA list of nested sub-level specifications the events should be forwarded to.\nPubSub type redis\na redis pubsub system.\nThe following versions are supported:\nVersion v1\nIt is describe by the following field:\nserverAddr Address of redis server\nchannel pubsub channel\ndatabase database number\nPublishing using the redis pubsub API. For every change a string message with the format : is published. If multiple repositories should be used, each repository should be configured with a different channel.\nThere are persistence providers for the following repository types:\nOCIRegistry See Also ","date":"0001-01-01","id":95,"permalink":"/docs/cli-reference/help/ocm-pubsub/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAn OCM repository can be configured to propagate change events via a\npublish/subscribe system, if there is a persistence provider for the dedicated\nrepository type. If available any known publish/subscribe system can\nbe configured with \u003ca href=\"/docs/cli-reference/set/pubsub/\"\u003eocm set pubsub\u003c/a\u003e and shown with\n\u003ca href=\"/docs/cli-reference/get/pubsub/\"\u003eocm get pubsub\u003c/a\u003e. Hereby, the pub/sub system\nis described by a typed specification.\u003c/p\u003e","tags":[],"title":"ocm-pubsub"},{"content":"Description The command line client supports a special notation scheme for specifying references to OCM components and repositories. This allows for specifying references to any registry supported by the OCM toolset that can host OCM components:\n[+][\u0026lt;type\u003e::][./]\u0026lt;file path\u003e//\u0026lt;component id\u003e[:\u0026lt;version\u003e] or\n[+][\u0026lt;type\u003e::][\u0026lt;json repo spec\u003e//]\u0026lt;component id\u003e[:\u0026lt;version\u003e] or\n[+][\u0026lt;type\u003e::][\u0026lt;scheme\u003e://]\u0026lt;domain\u003e[:\u0026lt;port\u003e][/\u0026lt;repository prefix\u003e]//\u0026lt;component id\u003e[:\u0026lt;version] or\n[+][\u0026lt;type\u003e::][\u0026lt;scheme\u003e://]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;repository prefix\u003e]//\u0026lt;component id\u003e[:\u0026lt;version] Besides dedicated components it is also possible to denote repositories as a whole:\n[+][\u0026lt;type\u003e::][./]\u0026lt;file path\u003e or\n[+][\u0026lt;type\u003e::]\u0026lt;json repo spec\u003e or\n[+][\u0026lt;type\u003e::][\u0026lt;scheme\u003e://]\u0026lt;domain\u003e[:\u0026lt;port\u003e][/\u0026lt;repository prefix\u003e] or\n[+][\u0026lt;type\u003e::][\u0026lt;scheme\u003e://]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;repository prefix\u003e] The optional + is used for file based implementations (Common Transport Format) to indicate the creation of a not yet existing file.\nThe type may contain a file format qualifier separated by a + character. The following formats are supported: directory, tar, tgz\nExamples Complete Component Reference Specifications (including all optional arguments): +ctf+directory::./ocm/ctf//ocm.software/ocmcli:0.7.0 oci::{\u0026#34;baseUrl\u0026#34;:\u0026#34;ghcr.io\u0026#34;,\u0026#34;componentNameMapping\u0026#34;:\u0026#34;urlPath\u0026#34;,\u0026#34;subPath\u0026#34;:\u0026#34;open-component-model\u0026#34;}//ocm.software/ocmcli.0.7.0 oci::https://ghcr.io:443/open-component-model//ocm.software/ocmcli:0.7.0 oci::http://localhost:8080/local-component-repository//ocm.software/ocmcli:0.7.0 --- Short-Hand Component Reference Specifications (omitting optional arguments): ./ocm/ctf//ocm.software/ocmcli:0.7.0 ghcr.io/open-component-model//ocm.software/ocmcli:0.7.0 localhost:8080/local-component-repository//ocm.software/ocmcli:0.7.0 (defaulting to https) http://localhost:8080/local-component-repository//ocm.software/ocmcli:0.7.0\rSee Also ","date":"0001-01-01","id":96,"permalink":"/docs/cli-reference/help/ocm-references/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eThe command line client supports a special notation scheme for specifying\nreferences to OCM components and repositories. This allows for specifying\nreferences to any registry supported by the OCM toolset that can host OCM\ncomponents:\u003c/p\u003e","tags":[],"title":"ocm-references"},{"content":"Description An upload handler is used to process resources using the access method localBlob transferred into an OCM repository. They may decide to store the content in some other storage repository. This may be an additional storage location or it may replace the storage of the resource as local blob. If an additional storage location is chosen, the local access method is kept and the additional location can be registered in the component descriptor as globalAccess attribute of the local access specification.\nFor example, there is a default upload handler responsible for OCI artifact blobs, which provides regular OCI artifacts for a local blob, if the target OCM repository is based on an OCI registry. Hereby, the referenceName attribute will be used to calculate a meaningful OCI repository name based on the repository prefix of the OCM repository (parallel to component-descriptors prefix used to store the component descriptor artifacts).\nHandler Registration Programmatically any kind of handlers can be registered for various upload conditions. But this feature is available as command-line option, also. New handlers can be provided by plugins. In general available handlers, plugin-based or as part of the CLI coding are nameable using an hierarchical namespace. Those names can be used by a \u0026ndash;uploader option to register handlers for various conditions for CLI commands like ocm transfer componentversions or ocm transfer commontransportarchive.\nBesides the activation constraints (resource type and media type of the resource blob), it is possible to pass a target configuration controlling the exact behaviour of the handler for selected artifacts.\nThe following handler names are possible:\nocm/mavenPackage: uploading maven artifacts\nThe ocm/mavenPackage uploader is able to upload maven artifacts (whole GAV only!) as artifact archive according to the maven artifact spec. If registered the default mime type is: application/x-tgz\nIt accepts a plain string for the URL or a config with the following field: \u0026lsquo;url\u0026rsquo;: the URL of the maven repository.\nocm/npmPackage: uploading npm artifacts\nThe ocm/npmPackage uploader is able to upload npm artifacts as artifact archive according to the npm package spec. If registered the default mime type is: application/x-tgz\nIt accepts a plain string for the URL or a config with the following field: \u0026lsquo;url\u0026rsquo;: the URL of the npm repository.\nocm/ociArtifacts: downloading OCI artifacts\nThe ociArtifacts downloader is able to download OCI artifacts as artifact archive according to the OCI distribution spec. The following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar application/vnd.oci.image.manifest.v1+tar+gzip application/vnd.oci.image.index.v1+tar application/vnd.oci.image.index.v1+tar+gzip application/vnd.docker.distribution.manifest.v2+tar application/vnd.docker.distribution.manifest.v2+tar+gzip application/vnd.docker.distribution.manifest.list.v2+tar application/vnd.docker.distribution.manifest.list.v2+tar+gzip By default, it is registered for these mimetypes.\nIt accepts a config with the following fields:\nnamespacePrefix: a namespace prefix used for the uploaded artifacts ociRef: an OCI repository reference repository: an OCI repository specification for the target OCI registry Alternatively, a single string value can be given representing an OCI repository reference.\nplugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\nSee ocm ocm-uploadhandlers for further details on using upload handlers.\nSee Also ","date":"0001-01-01","id":97,"permalink":"/docs/cli-reference/help/ocm-uploadhandlers/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAn upload handler is used to process resources using the access method\n\u003ccode\u003elocalBlob\u003c/code\u003e transferred into an OCM\nrepository. They may decide to store the content in some other\nstorage repository. This may be an additional storage location or it\nmay replace the storage of the resource as local blob.\nIf an additional storage location is chosen, the local access method\nis kept and the additional location can be registered in the component\ndescriptor as \u003ccode\u003eglobalAccess\u003c/code\u003e attribute of the local access\nspecification.\u003c/p\u003e","tags":[],"title":"ocm-uploadhandlers"},{"content":"Usage ocm describe package [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;} {\u0026lt;resource id field\u0026gt;}\rOptions -h, --help help for package --lookup stringArray repository name or spec for closure lookup fallback --repo string repository name or spec\rDescription Describe a TOI package provided by a resource of an OCM component version.\nThe package resource must have the type toiPackage. This is a simple YAML file resource describing the bootstrapping of a dedicated kind of software. See also the topic ocm toi-bootstrapping.\nThe first matching resource of this type is selected. Optionally a set of identity attribute can be specified used to refine the match. This can be the resource name and/or other key/value pairs (\u0026lt;attr\u0026gt;=\u0026lt;value\u0026gt;).\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry If a component lookup for building a reference closure is required the \u0026ndash;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.\nExamples $ ocm toi describe package ghcr.io/mandelsoft/ocm//ocmdemoinstaller:0.0.1-dev\rSee Also ocm describe\t— Describe various elements by using appropriate sub commands. ","date":"0001-01-01","id":98,"permalink":"/docs/cli-reference/describe/package/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm describe package [\u0026lt;options\u0026gt;] {\u0026lt;component-reference\u0026gt;} {\u0026lt;resource id field\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for package\n --lookup stringArray repository name or spec for closure lookup fallback\n --repo string repository name or spec\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eDescribe a TOI package provided by a resource of an OCM component version.\u003c/p\u003e","tags":[],"title":"package"},{"content":"Usage ocm describe plugins [\u0026lt;options\u0026gt;] {\u0026lt;plugin name\u0026gt;}\rOptions -h, --help help for plugins\rDescription Describes provides comprehensive information about the capabilities of a plugin.\nExamples $ ocm describe plugins $ ocm describe plugins demo\rSee Also ocm describe\t— Describe various elements by using appropriate sub commands. ","date":"0001-01-01","id":99,"permalink":"/docs/cli-reference/describe/plugins/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm describe plugins [\u0026lt;options\u0026gt;] {\u0026lt;plugin name\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for plugins\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eDescribes provides comprehensive information about the capabilities of\na plugin.\u003c/p\u003e","tags":[],"title":"plugins"},{"content":"Usage ocm get plugins [\u0026lt;options\u0026gt;] {\u0026lt;plugin name\u0026gt;}\rOptions -h, --help help for plugins -o, --output string output mode (JSON, json, wide, yaml) -s, --sort stringArray sort fields\rDescription Get lists information for all plugins specified, if no plugin is specified all registered ones are listed.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json wide yaml Examples $ ocm get plugins $ ocm get plugins demo -o yaml\rSee Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":100,"permalink":"/docs/cli-reference/get/plugins/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get plugins [\u0026lt;options\u0026gt;] {\u0026lt;plugin name\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for plugins\n -o, --output string output mode (JSON, json, wide, yaml)\n -s, --sort stringArray sort fields\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eGet lists information for all plugins specified, if no plugin is specified\nall registered ones are listed.\u003c/p\u003e","tags":[],"title":"plugins"},{"content":"Usage ocm get pubsub {\u0026lt;ocm repository\u0026gt;}\rOptions -h, --help help for pubsub -o, --output string output mode (JSON, json, yaml) -s, --sort stringArray sort fields\rDescription A repository may be able to store a publish/subscribe specification to propagate the creation or update of component versions. If such an implementation is available and a specification is assigned to the repository, it is shown. The specification can be set with the ocm set pubsub.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json yaml See Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":101,"permalink":"/docs/cli-reference/get/pubsub/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get pubsub {\u0026lt;ocm repository\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for pubsub\n -o, --output string output mode (JSON, json, yaml)\n -s, --sort stringArray sort fields\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eA repository may be able to store a publish/subscribe specification\nto propagate the creation or update of component versions.\nIf such an implementation is available and a specification is\nassigned to the repository, it is shown. The specification\ncan be set with the \u003ca href=\"/docs/cli-reference/set/pubsub/\"\u003eocm set pubsub\u003c/a\u003e.\u003c/p\u003e","tags":[],"title":"pubsub"},{"content":"Usage ocm set pubsub {\u0026lt;ocm repository\u0026gt;} [\u0026lt;pub/sub specification\u0026gt;]\rOptions -d, --delete delete pub/sub configuration -h, --help help for pubsub\rDescription A repository may be able to store a publish/subscribe specification to propagate the creation or update of component versions. If such an implementation is available this command can be used to set the pub/sub specification for a repository. If no specification is given an existing specification will be removed for the given repository. The specification can be queried with the ocm get pubsub. Types and specification formats are shown for the topic ocm ocm-pubsub.\nSee Also ocm set\t— Set information about OCM repositories ","date":"0001-01-01","id":102,"permalink":"/docs/cli-reference/set/pubsub/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm set pubsub {\u0026lt;ocm repository\u0026gt;} [\u0026lt;pub/sub specification\u0026gt;]\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -d, --delete delete pub/sub configuration\n -h, --help help for pubsub\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eA repository may be able to store a publish/subscribe specification\nto propagate the creation or update of component versions.\nIf such an implementation is available this command can be used\nto set the pub/sub specification for a repository.\nIf no specification is given an existing specification\nwill be removed for the given repository.\nThe specification\ncan be queried with the \u003ca href=\"/docs/cli-reference/get/pubsub/\"\u003eocm get pubsub\u003c/a\u003e.\nTypes and specification formats are shown for the topic\n\u003ca href=\"/docs/cli-reference/help/ocm-pubsub/\"\u003eocm ocm-pubsub\u003c/a\u003e.\u003c/p\u003e","tags":[],"title":"pubsub"},{"content":"Usage ocm add references [\u0026lt;options\u0026gt;] [\u0026lt;target\u0026gt;] {\u0026lt;referencefile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\rOptions --addenv access environment for templating --component string component name --dry-run evaluate and print reference specifications --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; reference extra identity (default []) -F, --file string target file/directory (default \u0026#34;component-archive\u0026#34;) -h, --help help for references --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; reference label (leading * indicates signature relevant, optional version separated by @) --name string reference name -O, --output string output file for dry-run -P, --preserve-signature preserve existing signatures --reference YAML reference meta data (yaml) -R, --replace replace existing elements -s, --settings stringArray settings file with variable settings (yaml) --templater string templater to use (go, none, spiff, subst) (default \u0026#34;subst\u0026#34;) --version string reference version\rDescription Add aggregation information specified in a reference file to a component version. So far only component archives are supported as target.\nThis command accepts reference specification files describing the references to add to a component version. Elements must follow the reference meta data description scheme of the component descriptor.\nThe description file might contain:\na single reference a list of references under the key references a list of yaml documents with a single reference or reference list It is possible to describe a single reference via command line options. The meta data of this element is described by the argument of option \u0026ndash;reference, which must be a YAML or JSON string. Alternatively, the name and version can be specified with the options \u0026ndash;name and \u0026ndash;version. With the option \u0026ndash;extra it is possible to add extra identity attributes. Explicitly specified options override values specified by the \u0026ndash;reference option. (Note: Go templates are not supported for YAML-based option values. Besides this restriction, the finally composed element description is still processed by the selected template engine.)\nThe component name can be specified with the option \u0026ndash;component. Therefore, basic references not requiring any additional labels or extra identities can just be specified by those simple value options without the need for the YAML option.\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" The \u0026ndash;replace option allows users to specify whether adding an element with the same name and extra identity but different version as an existing element, append (false) or replace (true) the existing element.\nThe \u0026ndash;preserve-signature option prohibits changes of signature relevant elements.\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" Examples Add a reference directly by options $ ocm add references --file path/to/ca --name myref --component github.com/my/component --version ${VERSION} Add a reference by a description file: *references.yaml*: --- name: myref component: github.com/my/component version: ${VERSION] $ ocm add references path/to/ca references.yaml VERSION=1.0.0\rSee Also ocm add\t— Add elements to a component repository or component version ","date":"0001-01-01","id":103,"permalink":"/docs/cli-reference/add/references/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm add references [\u0026lt;options\u0026gt;] [\u0026lt;target\u0026gt;] {\u0026lt;referencefile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --addenv access environment for templating\n --component string component name\n --dry-run evaluate and print reference specifications\n --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; reference extra identity (default [])\n -F, --file string target file/directory (default \u0026#34;component-archive\u0026#34;)\n -h, --help help for references\n --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; reference label (leading * indicates signature relevant, optional version separated by @)\n --name string reference name\n -O, --output string output file for dry-run\n -P, --preserve-signature preserve existing signatures\n --reference YAML reference meta data (yaml)\n -R, --replace replace existing elements\n -s, --settings stringArray settings file with variable settings (yaml)\n --templater string templater to use (go, none, spiff, subst) (default \u0026#34;subst\u0026#34;)\n --version string reference version\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAdd aggregation information specified in a reference file to a component version.\nSo far only component archives are supported as target.\u003c/p\u003e","tags":[],"title":"references"},{"content":"Usage ocm get references [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}\rOptions -c, --constraints constraints version constraint -h, --help help for references --latest restrict component versions to latest --lookup stringArray repository name or spec for closure lookup fallback -o, --output string output mode (JSON, json, tree, wide, yaml) -r, --recursive follow component reference nesting --repo string repository name or spec -s, --sort stringArray sort fields\rDescription Get references of a component version. References are specified by identities. An identity consists of a name argument followed by optional \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; arguments.\nIf the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry With the option \u0026ndash;recursive the complete reference tree of a component reference is traversed.\nIf a component lookup for building a reference closure is required the \u0026ndash;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.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json tree wide yaml See Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":104,"permalink":"/docs/cli-reference/get/references/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get references [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -c, --constraints constraints version constraint\n -h, --help help for references\n --latest restrict component versions to latest\n --lookup stringArray repository name or spec for closure lookup fallback\n -o, --output string output mode (JSON, json, tree, wide, yaml)\n -r, --recursive follow component reference nesting\n --repo string repository name or spec\n -s, --sort stringArray sort fields\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eGet references of a component version. References are specified\nby identities. An identity consists of\na name argument followed by optional \u003ccode\u003e\u0026lt;key\u0026gt;=\u0026lt;value\u0026gt;\u003c/code\u003e\narguments.\u003c/p\u003e","tags":[],"title":"references"},{"content":"Usage ocm add resource-configuration [\u0026lt;options\u0026gt;] \u0026lt;target\u0026gt; {\u0026lt;configfile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\rOptions --access YAML blob access specification (YAML) --accessComponent string component for access specification --accessHostname string hostname used for access --accessRepository string repository or registry URL --accessType string type of blob access specification --accessVersion string version for access specification --artifactId string maven artifact id --body string body of a http request --bucket string bucket name --classifier string maven classifier --commit string git commit id --digest string blob digest --extension string maven extension name --external flag non-local resource --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; resource extra identity (default []) --globalAccess YAML access specification for global access --groupId string maven group id --header \u0026lt;name\u0026gt;:\u0026lt;value\u0026gt;,\u0026lt;value\u0026gt;,... http headers (default {}) -h, --help help for resource-configuration --hint string (repository) hint for local artifacts --identityPath {\u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;} identity path for specification --input YAML blob input specification (YAML) --inputComponent string component name --inputCompress compress option for input --inputData !bytesBase64 data (string, !!string or !\u0026lt;base64\u0026gt; --inputExcludes stringArray excludes (path) for inputs --inputFollowSymlinks follow symbolic links during archive creation for inputs --inputFormattedJson YAML JSON formatted text --inputHelmRepository string helm repository base URL --inputIncludes stringArray includes (path) for inputs --inputJson YAML JSON formatted text --inputLibraries stringArray library path for inputs --inputPath filepath path field for input --inputPlatforms stringArray input filter for image platforms ([os]/[architecture]) --inputPreserveDir preserve directory in archive for inputs --inputRepository string repository or registry for inputs --inputText string utf8 text --inputType string type of blob input specification --inputValues YAML YAML based generic values for inputs --inputVariants stringArray (platform) variants for inputs --inputVersion string version info for inputs --inputYaml YAML YAML formatted text --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; resource label (leading * indicates signature relevant, optional version separated by @) --mediaType string media type for artifact blob representation --name string resource name --noredirect http redirect behavior --package string package or object name --reference string reference name --region string region name --resource YAML resource meta data (yaml) -s, --settings stringArray settings file with variable settings (yaml) --size int blob size --type string resource type --url string artifact or server url --verb string http request method --version string resource version\rDescription Add a resource specification to a resource config file used by ocm add resources.\nIt is possible to describe a single resource via command line options. The meta data of this element is described by the argument of option \u0026ndash;resource, which must be a YAML or JSON string. Alternatively, the name and version can be specified with the options \u0026ndash;name and \u0026ndash;version. With the option \u0026ndash;extra it is possible to add extra identity attributes. Explicitly specified options override values specified by the \u0026ndash;resource option. (Note: Go templates are not supported for YAML-based option values. Besides this restriction, the finally composed element description is still processed by the selected template engine.)\nThe resource type can be specified with the option \u0026ndash;type. Therefore, the minimal required meta data for elements can be completely specified by dedicated options and don\u0026rsquo;t need the YAML option.\nTo describe the content of this element one of the options \u0026ndash;access or \u0026ndash;input must be given. They take a YAML or JSON value describing an attribute set, also. The structure of those values is similar to the access or input fields of the description file format. Non-local resources can be indicated using the option \u0026ndash;external. Elements must follow the resource meta data description scheme of the component descriptor.\nIf expressions/templates are used in the specification file an appropriate templater and the required settings might be required to provide a correct input validation.\nThis command accepts additional resource specification files describing the sources to add to a component version.\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" The resource specification supports the following blob input types, specified with the field type in the input field:\nInput type binary\nThis blob type is used to provide base64 encoded binary content. The specification supports the following fields:\ndata []byte\nThe binary data to provide.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputData, \u0026ndash;mediaType\nInput type dir\nThe path must denote a directory relative to the resources file, which is packed with tar and optionally compressed if the compress field is set to true. If the field preserveDir is set to true the directory itself is added to the tar. If the field followSymLinks is set to true, symbolic links are not packed but their targets files or folders. With the list fields includeFiles and excludeFiles it is possible to specify which files should be included or excluded. The values are regular expression used to match relative file paths. If no includes are specified all file not explicitly excluded are used.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the file path to directory relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/x-tar and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the file content should be stored compressed or not.\npreserveDir bool\nThis OPTIONAL property describes whether the specified directory with its basename should be included as top level folder.\nfollowSymlinks bool\nThis OPTIONAL property describes whether symbolic links should be followed or included as links.\nexcludeFiles list of regex\nThis OPTIONAL property describes regular expressions used to match files that should NOT be included in the tar file. It takes precedence over the include match.\nincludeFiles list of regex\nThis OPTIONAL property describes regular expressions used to match files that should be included in the tar file. If this option is not given all files not explicitly excluded are used.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputExcludes, \u0026ndash;inputFollowSymlinks, \u0026ndash;inputIncludes, \u0026ndash;inputPath, \u0026ndash;inputPreserveDir, \u0026ndash;mediaType\nInput type docker\nThe path must denote an image tag that can be found in the local docker daemon. The denoted image is packed as OCI artifact set. The OCI image will contain an informational back link to the component version using the manifest annotation software.ocm/component-version.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the image name to import from the local docker daemon.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputPath\nInput type dockermulti\nThis input type describes the composition of a multi-platform OCI image. The various variants are taken from the local docker daemon. They should be built with the \u0026ldquo;buildx\u0026rdquo; command for cross platform docker builds (see https://ocm.software/docs/tutorials/best-practices/#building-multi-architecture-images). The denoted images, as well as the wrapping image index, are packed as OCI artifact set. They will contain an informational back link to the component version using the manifest annotation software.ocm/component-version.\nThis blob type specification supports the following fields:\nvariants []string\nThis REQUIRED property describes a set of image names to import from the local docker daemon used to compose a resulting image index.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputVariants\nInput type file\nThe path must denote a file relative the resources file. The content is compressed if the compress field is set to true.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the path to the file relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;mediaType\nInput type helm\nThe path must denote an helm chart archive or directory relative to the resources file or a chart name in a helm chart repository. The denoted chart is packed as an OCI artifact set. For the filesystem version additional provider info is taken from a file with the same name and the suffix .prov.\nIf the chart should just be stored as plain archive, please use the type file or dir, instead.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the file path to the helm chart relative to the resource file location.\nversion string\nThis OPTIONAL property can be set to configure an explicit version hint. If not specified the version from the chart will be used. Basically, it is a good practice to use the component version for local resources This can be achieved by using templating for this attribute in the resource file.\nhelmRepository string\nThis OPTIONAL property can be set, if the helm chart should be loaded from a helm repository instead of the local filesystem. It describes the base URL of the chart repository. If specified, the path field must describe the name of the chart in the chart repository, and version must describe the version of the chart imported from the chart repository\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\ncaCertFile string\nThis OPTIONAL property can be used to specify a relative filename for the TLS root certificate used to access a helm repository.\ncaCert string\nThis OPTIONAL property can be used to specify a TLS root certificate used to access a helm repository.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputHelmRepository, \u0026ndash;inputPath, \u0026ndash;inputVersion, \u0026ndash;mediaType\nInput type maven\nThe repoUrl is the url pointing either to the http endpoint of a maven repository (e.g. https://repo.maven.apache.org/maven2/) or to a file system based maven repository (e.g. file://local/directory).\nThis blob type specification supports the following fields:\nrepoUrl string\nThis REQUIRED property describes the url from which the resource is to be accessed.\ngroupId string\nThis REQUIRED property describes the groupId of a maven artifact.\nartifactId string\nThis REQUIRED property describes artifactId of a maven artifact.\nversion string\nThis REQUIRED property describes the version of a maven artifact.\nclassifier string\nThis OPTIONAL property describes the classifier of a maven artifact.\nextension string\nThis OPTIONAL property describes the extension of a maven artifact.\nOptions used to configure fields: \u0026ndash;artifactId, \u0026ndash;classifier, \u0026ndash;extension, \u0026ndash;groupId, \u0026ndash;inputPath, \u0026ndash;inputVersion, \u0026ndash;url\nInput type npm\nThe registry is the url pointing to the npm registry from which a resource is downloaded.\nThis blob type specification supports the following fields:\nregistry string\nThis REQUIRED property describes the url from which the resource is to be downloaded.\npackage string\nThis REQUIRED property describes the name of the package to download.\nversion string\nThis is an OPTIONAL property describing the version of the package to download. If not defined, latest will be used automatically.\nOptions used to configure fields: \u0026ndash;inputRepository, \u0026ndash;inputVersion, \u0026ndash;package\nInput type ociArtifact\nThis input type is used to import an OCI image from an OCI registry. If it is a multi-arch image the set of platforms to be imported can be filtered using the \u0026ldquo;platforms\u0026rdquo; attribute. The path must denote an OCI image reference.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the OCI image reference of the image to import.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nplatforms []string\nThis OPTIONAL property can be used to filter index artifacts to include only images for dedicated operating systems/architectures. Elements must meet the syntax [\u0026lt;os\u0026gt;]/[\u0026lt;architecture\u0026gt;].\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;inputPlatforms, \u0026ndash;mediaType\nInput type ociImage\nDEPRECATED: This type is deprecated, please use ociArtifact instead.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;inputPlatforms, \u0026ndash;mediaType\nInput type ocm\nThis input type allows to get a resource artifact from an OCM repository.\nThis blob type specification supports the following fields:\nocmRepository repository specification\nThis REQUIRED property describes the OCM repository specification\ncomponent string\nThis REQUIRED property describes the component na,e\nversion string\nThis REQUIRED property describes the version of a maven artifact.\nresourceRef relative resource reference\nThis REQUIRED property describes the resource reference for the desired resource relative to the given component version .\nOptions used to configure fields: \u0026ndash;identityPath, \u0026ndash;inputComponent, \u0026ndash;inputRepository, \u0026ndash;inputVersion\nInput type spiff\nThe path must denote a spiff template relative the resources file. The content is compressed if the compress field is set to true.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the path to the file relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nvalues map[string]any\nThis OPTIONAL property describes an additional value binding for the template processing. It will be available under the node inputvalues.\nlibraries []string\nThis OPTIONAL property describes a list of spiff libraries to include in template processing.\nThe variable settings from the command line are available as binding, also. They are provided under the node values.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputLibraries, \u0026ndash;inputPath, \u0026ndash;inputValues, \u0026ndash;mediaType\nInput type utf8\nThis blob type is used to provide inline text based content (UTF8). The specification supports the following fields:\ntext string\nThe utf8 string content to provide.\njson JSON or JSON string interpreted as JSON\nThe content emitted as JSON.\nformattedJson YAML/JSON or JSON/YAML string interpreted as JSON\nThe content emitted as formatted JSON.\nyaml AML/JSON or JSON/YAML string interpreted as YAML\nThe content emitted as YAML.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputFormattedJson, \u0026ndash;inputJson, \u0026ndash;inputText, \u0026ndash;inputYaml, \u0026ndash;mediaType\nInput type wget\nThe url is the url pointing to the http endpoint from which a resource is downloaded. The mimeType can be used to specify the MIME type of the resource.\nThis blob type specification supports the following fields:\nurl string\nThis REQUIRED property describes the url from which the resource is to be downloaded.\nmediaType string\nThis OPTIONAL property describes the media type of the resource to be downloaded. If omitted, ocm tries to read the mediaType from the Content-Type header of the http response. If the mediaType cannot be set from the Content-Type header as well, ocm tries to deduct the mediaType from the URL. If that is not possible either, the default media type is defaulted to application/octet-stream.\nheader map[string][]string\nThis OPTIONAL property describes the http headers to be set in the http request to the server.\nverb string\nThis OPTIONAL property describes the http verb (also known as http request method) for the http request. If omitted, the http verb is defaulted to GET.\nbody []byte\nThis OPTIONAL property describes the http body to be included in the request.\nnoredirect bool\nThis OPTIONAL property describes whether http redirects should be disabled. If omitted, it is defaulted to false (so, per default, redirects are enabled).\nOptions used to configure fields: \u0026ndash;body, \u0026ndash;header, \u0026ndash;mediaType, \u0026ndash;noredirect, \u0026ndash;url, \u0026ndash;verb\nThe following list describes the supported access methods, their versions and specification formats. Typically there is special support for the CLI artifact add commands. The access method specification can be put below the access field. If always requires the field type describing the kind and version shown below.\nAccess type gitHub\nThis method implements the access of the content of a git commit stored in a GitHub repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nRepository URL with or without scheme.\nref (optional) string\nOriginal ref used to get the commit from\ncommit string\nThe sha/id of the git commit\nOptions used to configure fields: \u0026ndash;accessHostname, \u0026ndash;accessRepository, \u0026ndash;commit\nAccess type helm\nThis method implements the access of a Helm chart stored in a Helm repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nhelmRepository string\nHelm repository URL.\nhelmChart string\nThe name of the Helm chart and its version separated by a colon.\nversion string\nThe version of the Helm chart if not specified as part of the chart name.\ncaCert string\nAn optional TLS root certificate.\nkeyring string\nAn optional keyring used to verify the chart.\nIt uses the consumer identity type HelmChartRepository with the fields for a hostpath identity matcher (see ocm get credentials).\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type localBlob\nThis method is used to store a resource blob along with the component descriptor on behalf of the hosting OCM repository.\nIts implementation is specific to the implementation of OCM repository used to read the component descriptor. Every repository implementation may decide how and where local blobs are stored, but it MUST provide an implementation for this method.\nRegardless of the chosen implementation the attribute specification is defined globally the same.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nlocalReference string\nRepository type specific location information as string. The value may encode any deep structure, but typically just an access path is sufficient.\nmediaType string\nThe media type of the blob used to store the resource. It may add format information like +tar or +gzip.\nreferenceName (optional) string\nThis optional attribute may contain identity information used by other repositories to restore some global access with an identity related to the original source.\nFor example, if an OCI artifact originally referenced using the access method ociArtifact is stored during some transport step as local artifact, the reference name can be set to its original repository name. An import step into an OCI based OCM repository may then decide to make this artifact available again as regular OCI artifact.\nglobalAccess (optional) access method specification\nIf a resource blob is stored locally, the repository implementation may decide to provide an external access information (independent of the OCM model).\nFor example, an OCI artifact stored as local blob can be additionally stored as regular OCI artifact in an OCI registry.\nThis additional external access information can be added using a second external access method specification.\nOptions used to configure fields: \u0026ndash;globalAccess, \u0026ndash;hint, \u0026ndash;mediaType, \u0026ndash;reference\nAccess type maven\nThis method implements the access of a Maven artifact in a Maven repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nURL of the Maven repository\ngroupId string\nThe groupId of the Maven artifact\nartifactId string\nThe artifactId of the Maven artifact\nversion string\nThe version name of the Maven artifact\nclassifier string\nThe optional classifier of the Maven artifact\nextension string\nThe optional extension of the Maven artifact\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;artifactId, \u0026ndash;classifier, \u0026ndash;extension, \u0026ndash;groupId\nAccess type none\ndummy resource with no access\nAccess type npm\nThis method implements the access of an NPM package in an NPM registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregistry string\nBase URL of the NPM registry.\npackage string\nThe name of the NPM package\nversion string\nThe version name of the NPM package\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type ociArtifact\nThis method implements the access of an OCI artifact stored in an OCI registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI image/artifact reference following the possible docker schemes:\n\u0026lt;repo\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;digest\u0026gt;@\u0026lt;tag\u0026gt; [\u0026lt;port\u0026gt;]/\u0026lt;repo path\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;version\u0026gt;@\u0026lt;tag\u0026gt; Options used to configure fields: \u0026ndash;reference\nAccess type ociBlob\nThis method implements the access of an OCI blob stored in an OCI repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI repository reference (this artifact name used to store the blob).\nmediaType string\nThe media type of the blob\ndigest string\nThe digest of the blob used to access the blob in the OCI repository.\nsize integer\nThe size of the blob\nOptions used to configure fields: \u0026ndash;digest, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;size\nAccess type ocm\nThis method implements the access of any resource artifact stored in an OCM repository. Only repository types supporting remote access should be used.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nocmRepository json\nThe repository spec for the OCM repository\ncomponent string\n(Optional) The name of the component. The default is the own component.\nversion string\n(Optional) The version of the component. The default is the own component version.\nresourceRef relative resource ref\nThe resource reference of the denoted resource relative to the given component version.\nIt uses the consumer identity and credentials for the intermediate repositories and the final resource access.\nOptions used to configure fields: \u0026ndash;accessComponent, \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;identityPath\nAccess type s3\nThis method implements the access of a blob stored in an S3 bucket.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucket string\nThe name of the S3 bucket containing the blob\nkey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nVersion v2\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucketName string\nThe name of the S3 bucket containing the blob\nobjectKey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nOptions used to configure fields: \u0026ndash;accessVersion, \u0026ndash;bucket, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;region\nAccess type wget\nThis method implements access to resources stored on an http server.\nThe following versions are supported:\nVersion v1\nThe url is the url pointing to the http endpoint from which a resource is downloaded. The mimeType can be used to specify the MIME type of the resource.\nThis blob type specification supports the following fields:\nurl string This REQUIRED property describes the url from which the resource is to be downloaded.\nmediaType string This OPTIONAL property describes the media type of the resource to be downloaded. If omitted, ocm tries to read the mediaType from the Content-Type header of the http response. If the mediaType cannot be set from the Content-Type header as well, ocm tries to deduct the mediaType from the URL. If that is not possible either, the default media type is defaulted to application/octet-stream.\nheader map[string][]string This OPTIONAL property describes the http headers to be set in the http request to the server.\nverb string This OPTIONAL property describes the http verb (also known as http request method) for the http request. If omitted, the http verb is defaulted to GET.\nbody []byte This OPTIONAL property describes the http body to be included in the request.\nnoredirect bool This OPTIONAL property describes whether http redirects should be disabled. If omitted, it is defaulted to false (so, per default, redirects are enabled).\nOptions used to configure fields: \u0026ndash;body, \u0026ndash;header, \u0026ndash;mediaType, \u0026ndash;noredirect, \u0026ndash;url, \u0026ndash;verb\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" Examples $ ocm add resource-configuration resources.yaml --name myresource --type PlainText --input \u0026#39;{ \u0026#34;type\u0026#34;: \u0026#34;file\u0026#34;, \u0026#34;path\u0026#34;: \u0026#34;testdata/testcontent\u0026#34;, \u0026#34;mediaType\u0026#34;: \u0026#34;text/plain\u0026#34; }\u0026#39;\rSee Also ocm add\t— Add elements to a component repository or component version ","date":"0001-01-01","id":105,"permalink":"/docs/cli-reference/add/resource-configuration/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm add resource-configuration [\u0026lt;options\u0026gt;] \u0026lt;target\u0026gt; {\u0026lt;configfile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --access YAML blob access specification (YAML)\n --accessComponent string component for access specification\n --accessHostname string hostname used for access\n --accessRepository string repository or registry URL\n --accessType string type of blob access specification\n --accessVersion string version for access specification\n --artifactId string maven artifact id\n --body string body of a http request\n --bucket string bucket name\n --classifier string maven classifier\n --commit string git commit id\n --digest string blob digest\n --extension string maven extension name\n --external flag non-local resource\n --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; resource extra identity (default [])\n --globalAccess YAML access specification for global access\n --groupId string maven group id\n --header \u0026lt;name\u0026gt;:\u0026lt;value\u0026gt;,\u0026lt;value\u0026gt;,... http headers (default {})\n -h, --help help for resource-configuration\n --hint string (repository) hint for local artifacts\n --identityPath {\u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;} identity path for specification\n --input YAML blob input specification (YAML)\n --inputComponent string component name\n --inputCompress compress option for input\n --inputData !bytesBase64 data (string, !!string or !\u0026lt;base64\u0026gt;\n --inputExcludes stringArray excludes (path) for inputs\n --inputFollowSymlinks follow symbolic links during archive creation for inputs\n --inputFormattedJson YAML JSON formatted text\n --inputHelmRepository string helm repository base URL\n --inputIncludes stringArray includes (path) for inputs\n --inputJson YAML JSON formatted text\n --inputLibraries stringArray library path for inputs\n --inputPath filepath path field for input\n --inputPlatforms stringArray input filter for image platforms ([os]/[architecture])\n --inputPreserveDir preserve directory in archive for inputs\n --inputRepository string repository or registry for inputs\n --inputText string utf8 text\n --inputType string type of blob input specification\n --inputValues YAML YAML based generic values for inputs\n --inputVariants stringArray (platform) variants for inputs\n --inputVersion string version info for inputs\n --inputYaml YAML YAML formatted text\n --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; resource label (leading * indicates signature relevant, optional version separated by @)\n --mediaType string media type for artifact blob representation\n --name string resource name\n --noredirect http redirect behavior\n --package string package or object name\n --reference string reference name\n --region string region name\n --resource YAML resource meta data (yaml)\n -s, --settings stringArray settings file with variable settings (yaml)\n --size int blob size\n --type string resource type\n --url string artifact or server url\n --verb string http request method\n --version string resource version\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAdd a resource specification to a resource config file used by \u003ca href=\"/docs/cli-reference/add/resources/\"\u003eocm add resources\u003c/a\u003e.\u003c/p\u003e","tags":[],"title":"resource-configuration"},{"content":"Usage ocm add resources [\u0026lt;options\u0026gt;] [\u0026lt;target\u0026gt;] {\u0026lt;resourcefile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\rOptions --access YAML blob access specification (YAML) --accessComponent string component for access specification --accessHostname string hostname used for access --accessRepository string repository or registry URL --accessType string type of blob access specification --accessVersion string version for access specification --addenv access environment for templating --artifactId string maven artifact id --body string body of a http request --bucket string bucket name --classifier string maven classifier --commit string git commit id --digest string blob digest --dry-run evaluate and print resource specifications --extension string maven extension name --external flag non-local resource --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; resource extra identity (default []) -F, --file string target file/directory (default \u0026#34;component-archive\u0026#34;) --globalAccess YAML access specification for global access --groupId string maven group id --header \u0026lt;name\u0026gt;:\u0026lt;value\u0026gt;,\u0026lt;value\u0026gt;,... http headers (default {}) -h, --help help for resources --hint string (repository) hint for local artifacts --identityPath {\u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;} identity path for specification --input YAML blob input specification (YAML) --inputComponent string component name --inputCompress compress option for input --inputData !bytesBase64 data (string, !!string or !\u0026lt;base64\u0026gt; --inputExcludes stringArray excludes (path) for inputs --inputFollowSymlinks follow symbolic links during archive creation for inputs --inputFormattedJson YAML JSON formatted text --inputHelmRepository string helm repository base URL --inputIncludes stringArray includes (path) for inputs --inputJson YAML JSON formatted text --inputLibraries stringArray library path for inputs --inputPath filepath path field for input --inputPlatforms stringArray input filter for image platforms ([os]/[architecture]) --inputPreserveDir preserve directory in archive for inputs --inputRepository string repository or registry for inputs --inputText string utf8 text --inputType string type of blob input specification --inputValues YAML YAML based generic values for inputs --inputVariants stringArray (platform) variants for inputs --inputVersion string version info for inputs --inputYaml YAML YAML formatted text --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; resource label (leading * indicates signature relevant, optional version separated by @) --mediaType string media type for artifact blob representation --name string resource name --noredirect http redirect behavior -O, --output string output file for dry-run --package string package or object name -P, --preserve-signature preserve existing signatures --reference string reference name --region string region name -R, --replace replace existing elements --resource YAML resource meta data (yaml) -s, --settings stringArray settings file with variable settings (yaml) --size int blob size --skip-digest-generation skip digest creation --templater string templater to use (go, none, spiff, subst) (default \u0026#34;subst\u0026#34;) --type string resource type --url string artifact or server url --verb string http request method --version string resource version\rDescription Adds resources specified in a resource file to a component version. So far, only component archives are supported as target.\nThis command accepts resource specification files describing the resources to add to a component version. Elements must follow the resource meta data description scheme of the component descriptor. Besides referential resources using the access attribute to describe the access method, it is possible to describe local resources fed by local data using the input field (see below).\nThe description file might contain:\na single resource a list of resources under the key resources a list of yaml documents with a single resource or resource list It is possible to describe a single resource via command line options. The meta data of this element is described by the argument of option \u0026ndash;resource, which must be a YAML or JSON string. Alternatively, the name and version can be specified with the options \u0026ndash;name and \u0026ndash;version. With the option \u0026ndash;extra it is possible to add extra identity attributes. Explicitly specified options override values specified by the \u0026ndash;resource option. (Note: Go templates are not supported for YAML-based option values. Besides this restriction, the finally composed element description is still processed by the selected template engine.)\nThe resource type can be specified with the option \u0026ndash;type. Therefore, the minimal required meta data for elements can be completely specified by dedicated options and don\u0026rsquo;t need the YAML option.\nTo describe the content of this element one of the options \u0026ndash;access or \u0026ndash;input must be given. They take a YAML or JSON value describing an attribute set, also. The structure of those values is similar to the access or input fields of the description file format. Non-local resources can be indicated using the option \u0026ndash;external.\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" The resource specification supports the following blob input types, specified with the field type in the input field:\nInput type binary\nThis blob type is used to provide base64 encoded binary content. The specification supports the following fields:\ndata []byte\nThe binary data to provide.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputData, \u0026ndash;mediaType\nInput type dir\nThe path must denote a directory relative to the resources file, which is packed with tar and optionally compressed if the compress field is set to true. If the field preserveDir is set to true the directory itself is added to the tar. If the field followSymLinks is set to true, symbolic links are not packed but their targets files or folders. With the list fields includeFiles and excludeFiles it is possible to specify which files should be included or excluded. The values are regular expression used to match relative file paths. If no includes are specified all file not explicitly excluded are used.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the file path to directory relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/x-tar and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the file content should be stored compressed or not.\npreserveDir bool\nThis OPTIONAL property describes whether the specified directory with its basename should be included as top level folder.\nfollowSymlinks bool\nThis OPTIONAL property describes whether symbolic links should be followed or included as links.\nexcludeFiles list of regex\nThis OPTIONAL property describes regular expressions used to match files that should NOT be included in the tar file. It takes precedence over the include match.\nincludeFiles list of regex\nThis OPTIONAL property describes regular expressions used to match files that should be included in the tar file. If this option is not given all files not explicitly excluded are used.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputExcludes, \u0026ndash;inputFollowSymlinks, \u0026ndash;inputIncludes, \u0026ndash;inputPath, \u0026ndash;inputPreserveDir, \u0026ndash;mediaType\nInput type docker\nThe path must denote an image tag that can be found in the local docker daemon. The denoted image is packed as OCI artifact set. The OCI image will contain an informational back link to the component version using the manifest annotation software.ocm/component-version.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the image name to import from the local docker daemon.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputPath\nInput type dockermulti\nThis input type describes the composition of a multi-platform OCI image. The various variants are taken from the local docker daemon. They should be built with the \u0026ldquo;buildx\u0026rdquo; command for cross platform docker builds (see https://ocm.software/docs/tutorials/best-practices/#building-multi-architecture-images). The denoted images, as well as the wrapping image index, are packed as OCI artifact set. They will contain an informational back link to the component version using the manifest annotation software.ocm/component-version.\nThis blob type specification supports the following fields:\nvariants []string\nThis REQUIRED property describes a set of image names to import from the local docker daemon used to compose a resulting image index.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputVariants\nInput type file\nThe path must denote a file relative the resources file. The content is compressed if the compress field is set to true.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the path to the file relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;mediaType\nInput type helm\nThe path must denote an helm chart archive or directory relative to the resources file or a chart name in a helm chart repository. The denoted chart is packed as an OCI artifact set. For the filesystem version additional provider info is taken from a file with the same name and the suffix .prov.\nIf the chart should just be stored as plain archive, please use the type file or dir, instead.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the file path to the helm chart relative to the resource file location.\nversion string\nThis OPTIONAL property can be set to configure an explicit version hint. If not specified the version from the chart will be used. Basically, it is a good practice to use the component version for local resources This can be achieved by using templating for this attribute in the resource file.\nhelmRepository string\nThis OPTIONAL property can be set, if the helm chart should be loaded from a helm repository instead of the local filesystem. It describes the base URL of the chart repository. If specified, the path field must describe the name of the chart in the chart repository, and version must describe the version of the chart imported from the chart repository\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\ncaCertFile string\nThis OPTIONAL property can be used to specify a relative filename for the TLS root certificate used to access a helm repository.\ncaCert string\nThis OPTIONAL property can be used to specify a TLS root certificate used to access a helm repository.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputHelmRepository, \u0026ndash;inputPath, \u0026ndash;inputVersion, \u0026ndash;mediaType\nInput type maven\nThe repoUrl is the url pointing either to the http endpoint of a maven repository (e.g. https://repo.maven.apache.org/maven2/) or to a file system based maven repository (e.g. file://local/directory).\nThis blob type specification supports the following fields:\nrepoUrl string\nThis REQUIRED property describes the url from which the resource is to be accessed.\ngroupId string\nThis REQUIRED property describes the groupId of a maven artifact.\nartifactId string\nThis REQUIRED property describes artifactId of a maven artifact.\nversion string\nThis REQUIRED property describes the version of a maven artifact.\nclassifier string\nThis OPTIONAL property describes the classifier of a maven artifact.\nextension string\nThis OPTIONAL property describes the extension of a maven artifact.\nOptions used to configure fields: \u0026ndash;artifactId, \u0026ndash;classifier, \u0026ndash;extension, \u0026ndash;groupId, \u0026ndash;inputPath, \u0026ndash;inputVersion, \u0026ndash;url\nInput type npm\nThe registry is the url pointing to the npm registry from which a resource is downloaded.\nThis blob type specification supports the following fields:\nregistry string\nThis REQUIRED property describes the url from which the resource is to be downloaded.\npackage string\nThis REQUIRED property describes the name of the package to download.\nversion string\nThis is an OPTIONAL property describing the version of the package to download. If not defined, latest will be used automatically.\nOptions used to configure fields: \u0026ndash;inputRepository, \u0026ndash;inputVersion, \u0026ndash;package\nInput type ociArtifact\nThis input type is used to import an OCI image from an OCI registry. If it is a multi-arch image the set of platforms to be imported can be filtered using the \u0026ldquo;platforms\u0026rdquo; attribute. The path must denote an OCI image reference.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the OCI image reference of the image to import.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nplatforms []string\nThis OPTIONAL property can be used to filter index artifacts to include only images for dedicated operating systems/architectures. Elements must meet the syntax [\u0026lt;os\u0026gt;]/[\u0026lt;architecture\u0026gt;].\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;inputPlatforms, \u0026ndash;mediaType\nInput type ociImage\nDEPRECATED: This type is deprecated, please use ociArtifact instead.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;inputPlatforms, \u0026ndash;mediaType\nInput type ocm\nThis input type allows to get a resource artifact from an OCM repository.\nThis blob type specification supports the following fields:\nocmRepository repository specification\nThis REQUIRED property describes the OCM repository specification\ncomponent string\nThis REQUIRED property describes the component na,e\nversion string\nThis REQUIRED property describes the version of a maven artifact.\nresourceRef relative resource reference\nThis REQUIRED property describes the resource reference for the desired resource relative to the given component version .\nOptions used to configure fields: \u0026ndash;identityPath, \u0026ndash;inputComponent, \u0026ndash;inputRepository, \u0026ndash;inputVersion\nInput type spiff\nThe path must denote a spiff template relative the resources file. The content is compressed if the compress field is set to true.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the path to the file relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nvalues map[string]any\nThis OPTIONAL property describes an additional value binding for the template processing. It will be available under the node inputvalues.\nlibraries []string\nThis OPTIONAL property describes a list of spiff libraries to include in template processing.\nThe variable settings from the command line are available as binding, also. They are provided under the node values.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputLibraries, \u0026ndash;inputPath, \u0026ndash;inputValues, \u0026ndash;mediaType\nInput type utf8\nThis blob type is used to provide inline text based content (UTF8). The specification supports the following fields:\ntext string\nThe utf8 string content to provide.\njson JSON or JSON string interpreted as JSON\nThe content emitted as JSON.\nformattedJson YAML/JSON or JSON/YAML string interpreted as JSON\nThe content emitted as formatted JSON.\nyaml AML/JSON or JSON/YAML string interpreted as YAML\nThe content emitted as YAML.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputFormattedJson, \u0026ndash;inputJson, \u0026ndash;inputText, \u0026ndash;inputYaml, \u0026ndash;mediaType\nInput type wget\nThe url is the url pointing to the http endpoint from which a resource is downloaded. The mimeType can be used to specify the MIME type of the resource.\nThis blob type specification supports the following fields:\nurl string\nThis REQUIRED property describes the url from which the resource is to be downloaded.\nmediaType string\nThis OPTIONAL property describes the media type of the resource to be downloaded. If omitted, ocm tries to read the mediaType from the Content-Type header of the http response. If the mediaType cannot be set from the Content-Type header as well, ocm tries to deduct the mediaType from the URL. If that is not possible either, the default media type is defaulted to application/octet-stream.\nheader map[string][]string\nThis OPTIONAL property describes the http headers to be set in the http request to the server.\nverb string\nThis OPTIONAL property describes the http verb (also known as http request method) for the http request. If omitted, the http verb is defaulted to GET.\nbody []byte\nThis OPTIONAL property describes the http body to be included in the request.\nnoredirect bool\nThis OPTIONAL property describes whether http redirects should be disabled. If omitted, it is defaulted to false (so, per default, redirects are enabled).\nOptions used to configure fields: \u0026ndash;body, \u0026ndash;header, \u0026ndash;mediaType, \u0026ndash;noredirect, \u0026ndash;url, \u0026ndash;verb\nThe following list describes the supported access methods, their versions and specification formats. Typically there is special support for the CLI artifact add commands. The access method specification can be put below the access field. If always requires the field type describing the kind and version shown below.\nAccess type gitHub\nThis method implements the access of the content of a git commit stored in a GitHub repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nRepository URL with or without scheme.\nref (optional) string\nOriginal ref used to get the commit from\ncommit string\nThe sha/id of the git commit\nOptions used to configure fields: \u0026ndash;accessHostname, \u0026ndash;accessRepository, \u0026ndash;commit\nAccess type helm\nThis method implements the access of a Helm chart stored in a Helm repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nhelmRepository string\nHelm repository URL.\nhelmChart string\nThe name of the Helm chart and its version separated by a colon.\nversion string\nThe version of the Helm chart if not specified as part of the chart name.\ncaCert string\nAn optional TLS root certificate.\nkeyring string\nAn optional keyring used to verify the chart.\nIt uses the consumer identity type HelmChartRepository with the fields for a hostpath identity matcher (see ocm get credentials).\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type localBlob\nThis method is used to store a resource blob along with the component descriptor on behalf of the hosting OCM repository.\nIts implementation is specific to the implementation of OCM repository used to read the component descriptor. Every repository implementation may decide how and where local blobs are stored, but it MUST provide an implementation for this method.\nRegardless of the chosen implementation the attribute specification is defined globally the same.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nlocalReference string\nRepository type specific location information as string. The value may encode any deep structure, but typically just an access path is sufficient.\nmediaType string\nThe media type of the blob used to store the resource. It may add format information like +tar or +gzip.\nreferenceName (optional) string\nThis optional attribute may contain identity information used by other repositories to restore some global access with an identity related to the original source.\nFor example, if an OCI artifact originally referenced using the access method ociArtifact is stored during some transport step as local artifact, the reference name can be set to its original repository name. An import step into an OCI based OCM repository may then decide to make this artifact available again as regular OCI artifact.\nglobalAccess (optional) access method specification\nIf a resource blob is stored locally, the repository implementation may decide to provide an external access information (independent of the OCM model).\nFor example, an OCI artifact stored as local blob can be additionally stored as regular OCI artifact in an OCI registry.\nThis additional external access information can be added using a second external access method specification.\nOptions used to configure fields: \u0026ndash;globalAccess, \u0026ndash;hint, \u0026ndash;mediaType, \u0026ndash;reference\nAccess type maven\nThis method implements the access of a Maven artifact in a Maven repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nURL of the Maven repository\ngroupId string\nThe groupId of the Maven artifact\nartifactId string\nThe artifactId of the Maven artifact\nversion string\nThe version name of the Maven artifact\nclassifier string\nThe optional classifier of the Maven artifact\nextension string\nThe optional extension of the Maven artifact\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;artifactId, \u0026ndash;classifier, \u0026ndash;extension, \u0026ndash;groupId\nAccess type none\ndummy resource with no access\nAccess type npm\nThis method implements the access of an NPM package in an NPM registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregistry string\nBase URL of the NPM registry.\npackage string\nThe name of the NPM package\nversion string\nThe version name of the NPM package\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type ociArtifact\nThis method implements the access of an OCI artifact stored in an OCI registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI image/artifact reference following the possible docker schemes:\n\u0026lt;repo\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;digest\u0026gt;@\u0026lt;tag\u0026gt; [\u0026lt;port\u0026gt;]/\u0026lt;repo path\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;version\u0026gt;@\u0026lt;tag\u0026gt; Options used to configure fields: \u0026ndash;reference\nAccess type ociBlob\nThis method implements the access of an OCI blob stored in an OCI repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI repository reference (this artifact name used to store the blob).\nmediaType string\nThe media type of the blob\ndigest string\nThe digest of the blob used to access the blob in the OCI repository.\nsize integer\nThe size of the blob\nOptions used to configure fields: \u0026ndash;digest, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;size\nAccess type ocm\nThis method implements the access of any resource artifact stored in an OCM repository. Only repository types supporting remote access should be used.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nocmRepository json\nThe repository spec for the OCM repository\ncomponent string\n(Optional) The name of the component. The default is the own component.\nversion string\n(Optional) The version of the component. The default is the own component version.\nresourceRef relative resource ref\nThe resource reference of the denoted resource relative to the given component version.\nIt uses the consumer identity and credentials for the intermediate repositories and the final resource access.\nOptions used to configure fields: \u0026ndash;accessComponent, \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;identityPath\nAccess type s3\nThis method implements the access of a blob stored in an S3 bucket.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucket string\nThe name of the S3 bucket containing the blob\nkey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nVersion v2\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucketName string\nThe name of the S3 bucket containing the blob\nobjectKey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nOptions used to configure fields: \u0026ndash;accessVersion, \u0026ndash;bucket, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;region\nAccess type wget\nThis method implements access to resources stored on an http server.\nThe following versions are supported:\nVersion v1\nThe url is the url pointing to the http endpoint from which a resource is downloaded. The mimeType can be used to specify the MIME type of the resource.\nThis blob type specification supports the following fields:\nurl string This REQUIRED property describes the url from which the resource is to be downloaded.\nmediaType string This OPTIONAL property describes the media type of the resource to be downloaded. If omitted, ocm tries to read the mediaType from the Content-Type header of the http response. If the mediaType cannot be set from the Content-Type header as well, ocm tries to deduct the mediaType from the URL. If that is not possible either, the default media type is defaulted to application/octet-stream.\nheader map[string][]string This OPTIONAL property describes the http headers to be set in the http request to the server.\nverb string This OPTIONAL property describes the http verb (also known as http request method) for the http request. If omitted, the http verb is defaulted to GET.\nbody []byte This OPTIONAL property describes the http body to be included in the request.\nnoredirect bool This OPTIONAL property describes whether http redirects should be disabled. If omitted, it is defaulted to false (so, per default, redirects are enabled).\nOptions used to configure fields: \u0026ndash;body, \u0026ndash;header, \u0026ndash;mediaType, \u0026ndash;noredirect, \u0026ndash;url, \u0026ndash;verb\nThe \u0026ndash;replace option allows users to specify whether adding an element with the same name and extra identity but different version as an existing element, append (false) or replace (true) the existing element.\nThe \u0026ndash;preserve-signature option prohibits changes of signature relevant elements.\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" Examples Add a resource directly by options $ ocm add resources --file path/to/ca --name myresource --type PlainText --input \u0026#39;{ \u0026#34;type\u0026#34;: \u0026#34;file\u0026#34;, \u0026#34;path\u0026#34;: \u0026#34;testdata/testcontent\u0026#34;, \u0026#34;mediaType\u0026#34;: \u0026#34;text/plain\u0026#34; }\u0026#39; Add a resource by a description file: *resources.yaml*: --- name: myrresource type: plainText version: ${version] input: type: file path: testdata/testcontent mediaType: text/plain $ ocm add resources --file path/to/ca resources.yaml VERSION=1.0.0\rSee Also ocm add\t— Add elements to a component repository or component version ","date":"0001-01-01","id":106,"permalink":"/docs/cli-reference/add/resources/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm add resources [\u0026lt;options\u0026gt;] [\u0026lt;target\u0026gt;] {\u0026lt;resourcefile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --access YAML blob access specification (YAML)\n --accessComponent string component for access specification\n --accessHostname string hostname used for access\n --accessRepository string repository or registry URL\n --accessType string type of blob access specification\n --accessVersion string version for access specification\n --addenv access environment for templating\n --artifactId string maven artifact id\n --body string body of a http request\n --bucket string bucket name\n --classifier string maven classifier\n --commit string git commit id\n --digest string blob digest\n --dry-run evaluate and print resource specifications\n --extension string maven extension name\n --external flag non-local resource\n --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; resource extra identity (default [])\n -F, --file string target file/directory (default \u0026#34;component-archive\u0026#34;)\n --globalAccess YAML access specification for global access\n --groupId string maven group id\n --header \u0026lt;name\u0026gt;:\u0026lt;value\u0026gt;,\u0026lt;value\u0026gt;,... http headers (default {})\n -h, --help help for resources\n --hint string (repository) hint for local artifacts\n --identityPath {\u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;} identity path for specification\n --input YAML blob input specification (YAML)\n --inputComponent string component name\n --inputCompress compress option for input\n --inputData !bytesBase64 data (string, !!string or !\u0026lt;base64\u0026gt;\n --inputExcludes stringArray excludes (path) for inputs\n --inputFollowSymlinks follow symbolic links during archive creation for inputs\n --inputFormattedJson YAML JSON formatted text\n --inputHelmRepository string helm repository base URL\n --inputIncludes stringArray includes (path) for inputs\n --inputJson YAML JSON formatted text\n --inputLibraries stringArray library path for inputs\n --inputPath filepath path field for input\n --inputPlatforms stringArray input filter for image platforms ([os]/[architecture])\n --inputPreserveDir preserve directory in archive for inputs\n --inputRepository string repository or registry for inputs\n --inputText string utf8 text\n --inputType string type of blob input specification\n --inputValues YAML YAML based generic values for inputs\n --inputVariants stringArray (platform) variants for inputs\n --inputVersion string version info for inputs\n --inputYaml YAML YAML formatted text\n --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; resource label (leading * indicates signature relevant, optional version separated by @)\n --mediaType string media type for artifact blob representation\n --name string resource name\n --noredirect http redirect behavior\n -O, --output string output file for dry-run\n --package string package or object name\n -P, --preserve-signature preserve existing signatures\n --reference string reference name\n --region string region name\n -R, --replace replace existing elements\n --resource YAML resource meta data (yaml)\n -s, --settings stringArray settings file with variable settings (yaml)\n --size int blob size\n --skip-digest-generation skip digest creation\n --templater string templater to use (go, none, spiff, subst) (default \u0026#34;subst\u0026#34;)\n --type string resource type\n --url string artifact or server url\n --verb string http request method\n --version string resource version\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAdds resources specified in a resource file to a component version.\nSo far, only component archives are supported as target.\u003c/p\u003e","tags":[],"title":"resources"},{"content":"Usage ocm download resources [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}\rOptions --check-verified enable verification store -c, --constraints constraints version constraint -d, --download-handlers use download handler if possible --downloader \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; artifact downloader (\u0026lt;name\u0026gt;[:\u0026lt;artifact type\u0026gt;[:\u0026lt;media type\u0026gt;[:\u0026lt;priority\u0026gt;]]]=\u0026lt;JSON target config\u0026gt;) (default []) -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 --verified string file used to remember verifications for downloads (default \u0026#34;~/.ocm/verified\u0026#34;) --verify verify downloads\rDescription Download resources of a component version. Resources are specified by identities. An identity consists of a name argument followed by optional \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; arguments.\nThe 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:\n\u0026lt;component\u003e/\u0026lt;version\u003e{/\u0026lt;nested component\u003e/\u0026lt;version\u003e} 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 used. If additional identity attributes are required, this name is append by a comma separated list of \u0026lt;name\u0026gt;=\u0026lt;\u0026gt;value\u0026gt; pairs separated by a \u0026ldquo;-\u0026rdquo; from the plain name. This attribute list is alphabetical order:\n\u0026lt;resource name\u003e[-[\u0026lt;name\u003e=\u0026lt;\u003evalue\u003e]{,\u0026lt;name\u003e=\u0026lt;\u003evalue\u003e}] If the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry If the \u0026ndash;downloader option is specified, appropriate downloader handlers are configured for the operation. It has the following format\n\u0026lt;name\u003e:\u0026lt;artifact type\u003e:\u0026lt;media type\u003e=\u0026lt;yaml target config\u003e The downloader name may be a path expression with the following possibilities:\nhelm/artifact: download helm chart resources\nThe helm downloader is able to download helm chart resources as helm chart packages. Thus, the downloader may perform transformations. For example, if the helm chart is currently stored as an oci artifact, the downloader performs the necessary extraction to provide the helm chart package from within that oci artifact.\nThe following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar+gzip application/vnd.cncf.helm.chart.content.v1.tar+gzip It accepts no config.\nlandscaper/blueprint: uploading an OCI artifact to an OCI registry\nThe artifact downloader is able to transfer OCI artifact-like resources into an OCI registry given by the combination of the download target and the registration config.\nIf no config is given, the target must be an OCI reference with a potentially omitted repository. The repo part is derived from the reference hint provided by the resource\u0026rsquo;s access specification.\nIf the config is given, the target is used as repository name prefixed with an optional repository prefix given by the configuration.\nThe following artifact media types are supported:\napplication/vnd.docker.distribution.manifest.v2+tar application/vnd.docker.distribution.manifest.v2+tar+gzip application/vnd.gardener.landscaper.blueprint.layer.v1.tar application/vnd.gardener.landscaper.blueprint.layer.v1.tar+gzip application/vnd.gardener.landscaper.blueprint.v1+tar application/vnd.gardener.landscaper.blueprint.v1+tar+gzip application/vnd.oci.image.manifest.v1+tar application/vnd.oci.image.manifest.v1+tar+gzip application/x-tar application/x-tar+gzip application/x-tgz It accepts a config with the following fields:\nociConfigTypes: a list of accepted OCI config archive mime types defaulted by application/vnd.gardener.landscaper.blueprint.config.v1. This handler is by default registered for the following artifact types: landscaper.gardener.cloud/blueprint,blueprint\noci/artifact: downloading an OCI artifact and optionally re-uploading to an OCI registry\nThe artifact download resources stored as oci artifact. Furthermore, it allows to specify another OCI registry as download destination, thereby, providing a kind of transfer functionality.\nIf no config is given, the target must be an OCI reference with a potentially omitted repository. The repo part is derived from the reference hint provided by the resource\u0026rsquo;s access specification.\nIf the config is given, the target is used as repository name prefixed with an optional repository prefix given by the configuration.\nThe following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar+gzip application/vnd.oci.image.index.v1+tar+gzip It accepts a config with the following fields:\nnamespacePrefix: a namespace prefix used for the uploaded artifacts ociRef: an OCI repository reference repository: an OCI repository specification for the target OCI registry ocm/dirtree: downloading directory tree-like resources\nThe dirtree downloader is able to download directory-tree like resources as directory structure (default) or archive. The following artifact media types are supported:\napplication/vnd.oci.image.manifest.v1+tar+gzip application/x-tgz application/x-tar+gzip application/x-tar By default, it is registered for the following resource types:\ndirectoryTree filesystem It accepts a config with the following fields:\nasArchive: flag to request an archive download ociConfigTypes: a list of accepted OCI config archive mime types defaulted by application/vnd.oci.image.config.v1+json. plugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\nSee ocm ocm-downloadhandlers for further details on using download handlers.\nThe 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 \u0026ndash;download-handlers option. Otherwise the resource as returned by the access method is stored.\nWith the option \u0026ndash;recursive the complete reference tree of a component reference is traversed.\nIf a component lookup for building a reference closure is required the \u0026ndash;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.\nIf the verification store is enabled, resources downloaded from signed or verified component versions are verified against their digests provided by the component version.(not supported for using downloaders for the resource download).\nThe usage of the verification store is enabled by \u0026ndash;check-verified or by specifying a verification file with \u0026ndash;verified.\nSee Also ocm download\t— Download oci artifacts, resources or complete components ","date":"0001-01-01","id":107,"permalink":"/docs/cli-reference/download/resources/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm download resources [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --check-verified enable verification store\n -c, --constraints constraints version constraint\n -d, --download-handlers use download handler if possible\n --downloader \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; artifact downloader (\u0026lt;name\u0026gt;[:\u0026lt;artifact type\u0026gt;[:\u0026lt;media type\u0026gt;[:\u0026lt;priority\u0026gt;]]]=\u0026lt;JSON target config\u0026gt;) (default [])\n -x, --executable download executable for local platform\n -h, --help help for resources\n --latest restrict component versions to latest\n --lookup stringArray repository name or spec for closure lookup fallback\n -O, --outfile string output file or directory\n -r, --recursive follow component reference nesting\n --repo string repository name or spec\n -t, --type stringArray resource type filter\n --verified string file used to remember verifications for downloads (default \u0026#34;~/.ocm/verified\u0026#34;)\n --verify verify downloads\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eDownload resources of a component version. Resources are specified\nby identities. An identity consists of\na name argument followed by optional \u003ccode\u003e\u0026lt;key\u0026gt;=\u0026lt;value\u0026gt;\u003c/code\u003e\narguments.\u003c/p\u003e","tags":[],"title":"resources"},{"content":"Usage ocm get resources [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}\rOptions -c, --constraints constraints version constraint -h, --help help for resources --latest restrict component versions to latest --lookup stringArray repository name or spec for closure lookup fallback -o, --output string output mode (JSON, json, tree, treewide, wide, yaml) -r, --recursive follow component reference nesting --repo string repository name or spec -s, --sort stringArray sort fields\rDescription Get resources of a component version. Resources are specified by identities. An identity consists of a name argument followed by optional \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; arguments.\nIf the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry With the option \u0026ndash;recursive the complete reference tree of a component reference is traversed.\nIf a component lookup for building a reference closure is required the \u0026ndash;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.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json tree treewide wide yaml See Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":108,"permalink":"/docs/cli-reference/get/resources/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get resources [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -c, --constraints constraints version constraint\n -h, --help help for resources\n --latest restrict component versions to latest\n --lookup stringArray repository name or spec for closure lookup fallback\n -o, --output string output mode (JSON, json, tree, treewide, wide, yaml)\n -r, --recursive follow component reference nesting\n --repo string repository name or spec\n -s, --sort stringArray sort fields\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eGet resources of a component version. Resources are specified\nby identities. An identity consists of\na name argument followed by optional \u003ccode\u003e\u0026lt;key\u0026gt;=\u0026lt;value\u0026gt;\u003c/code\u003e\narguments.\u003c/p\u003e","tags":[],"title":"resources"},{"content":"Usage ocm add routingslips [\u0026lt;options\u0026gt;] \u0026lt;component-version\u0026gt; \u0026lt;routing-slip\u0026gt; \u0026lt;type\u0026gt;\rOptions -S, --algorithm string signature handler (default \u0026#34;RSASSA-PKCS1-V1_5\u0026#34;) --comment string comment field value --digest string parent digest to use --entry YAML routing slip entry specification (YAML) -h, --help help for routingslips --links strings links to other slip/entries (\u0026lt;slipname\u0026gt;[@\u0026lt;digest\u0026gt;]) --lookup stringArray repository name or spec for closure lookup fallback --repo string repository name or spec\rDescription Add a routing slip entry for the specified routing slip name to the given component version. The name is typically a DNS domain name followed by some qualifiers separated by a slash (/). It is possible to use arbitrary types, the type is not checked, if it is not known. Accordingly, an arbitrary config given as JSON or YAML can be given to determine the attribute set of the new entry for unknown types.\nThe following list describes the well-known entry types explicitly supported by this version of the CLI, their versions and specification formats. Other kinds of entries can be configured using the \u0026ndash;entry option.\nEntry type comment\nAn unstructured comment as entry in a routing slip.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\ncomment string\nAny text as entry in a routing slip.\nOptions used to configure fields: \u0026ndash;comment\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry If a component lookup for building a reference closure is required the \u0026ndash;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.\nExamples $ ocm add routingslip ghcr.io/mandelsoft/ocm//ocmdemoinstaller:0.0.1-dev mandelsoft.org comment --entry \u0026#34;comment=some text\u0026#34;\rSee Also ocm add\t— Add elements to a component repository or component version ","date":"0001-01-01","id":109,"permalink":"/docs/cli-reference/add/routingslips/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm add routingslips [\u0026lt;options\u0026gt;] \u0026lt;component-version\u0026gt; \u0026lt;routing-slip\u0026gt; \u0026lt;type\u0026gt;\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -S, --algorithm string signature handler (default \u0026#34;RSASSA-PKCS1-V1_5\u0026#34;)\n --comment string comment field value\n --digest string parent digest to use\n --entry YAML routing slip entry specification (YAML)\n -h, --help help for routingslips\n --links strings links to other slip/entries (\u0026lt;slipname\u0026gt;[@\u0026lt;digest\u0026gt;])\n --lookup stringArray repository name or spec for closure lookup fallback\n --repo string repository name or spec\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAdd a routing slip entry for the specified routing slip name to the given\ncomponent version. The name is typically a DNS domain name followed by some\nqualifiers separated by a slash (/). It is possible to use arbitrary types,\nthe type is not checked, if it is not known. Accordingly, an arbitrary config\ngiven as JSON or YAML can be given to determine the attribute set of the new\nentry for unknown types.\u003c/p\u003e","tags":[],"title":"routingslips"},{"content":"Usage ocm get routingslips [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt;}\rOptions --all-columns show all table columns -c, --constraints constraints version constraint --fail-on-error fail on validation error -h, --help help for routingslips --latest restrict component versions to latest --lookup stringArray repository name or spec for closure lookup fallback -o, --output string output mode (JSON, json, wide, yaml) --repo string repository name or spec -s, --sort stringArray sort fields -v, --verify verify signature\rDescription Get all or the selected routing slips for a component version specification.\nIf the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry If a component lookup for building a reference closure is required the \u0026ndash;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.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json wide yaml See Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":110,"permalink":"/docs/cli-reference/get/routingslips/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get routingslips [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --all-columns show all table columns\n -c, --constraints constraints version constraint\n --fail-on-error fail on validation error\n -h, --help help for routingslips\n --latest restrict component versions to latest\n --lookup stringArray repository name or spec for closure lookup fallback\n -o, --output string output mode (JSON, json, wide, yaml)\n --repo string repository name or spec\n -s, --sort stringArray sort fields\n -v, --verify verify signature\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eGet all or the selected routing slips for a component version specification.\u003c/p\u003e","tags":[],"title":"routingslips"},{"content":"Usage ocm create rsakeypair [\u0026lt;private key file\u0026gt; [\u0026lt;public key file\u0026gt;]] {\u0026lt;subject-attribute\u0026gt;=\u0026lt;value\u0026gt;}\rOptions --ca create certificate for a signing authority --ca-cert string certificate authority to sign public key --ca-key string private key for certificate authority -E, --encrypt encrypt private key with new key -e, --encryptionKey string encrypt private key with given key -h, --help help for rsakeypair --root-certs string root certificates used to validate used certificate authority --validity duration certificate validity (default 87600h0m0s)\rDescription Create an RSA public key pair and save to files.\nThe default for the filename to store the private key is rsa.priv. If no public key file is specified, its name will be derived from the filename for the private key (suffix .pub for public key or .cert for certificate). If a certificate authority is given (\u0026ndash;ca-cert) the public key will be signed. In this case a subject (at least common name/issuer) and a private key (\u0026ndash;ca-key) for the ca used to sign the key is required.\nIf only a subject is given and no ca, the public key will be self-signed. A signed public key always contains the complete certificate chain. If a non-self-signed ca is used to sign the key, its certificate chain is verified. Therefore, an additional root certificate (\u0026ndash;root-certs) is required, if no public root certificate was used to create the used ca.\nFor signing the public key the following subject attributes are supported:\nCN, common-name, issuer: Common Name/Issuer O, organization, org: Organization OU, organizational-unit, org-unit: Organizational Unit STREET (multiple): Street Address POSTALCODE, postal-code (multiple): Postal Code L, locality (multiple): Locality S, province, (multiple): Province C, country, (multiple): Country Examples $ ocm create rsakeypair mandelsoft.priv mandelsoft.cert issuer=mandelsoft\rSee Also ocm create\t— Create transport or component archive ","date":"0001-01-01","id":111,"permalink":"/docs/cli-reference/create/rsakeypair/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm create rsakeypair [\u0026lt;private key file\u0026gt; [\u0026lt;public key file\u0026gt;]] {\u0026lt;subject-attribute\u0026gt;=\u0026lt;value\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --ca create certificate for a signing authority\n --ca-cert string certificate authority to sign public key\n --ca-key string private key for certificate authority\n -E, --encrypt encrypt private key with new key\n -e, --encryptionKey string encrypt private key with given key\n -h, --help help for rsakeypair\n --root-certs string root certificates used to validate used certificate authority\n --validity duration certificate validity (default 87600h0m0s)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eCreate an RSA public key pair and save to files.\u003c/p\u003e","tags":[],"title":"rsakeypair"},{"content":"Usage ocm set [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for set\rSee Also Sub Commands ocm set pubsub\t— Set the pubsub spec for an ocm repository ","date":"0001-01-01","id":112,"permalink":"/docs/cli-reference/set/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm set [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for set\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/set/pubsub/\"\u003eocm set \u003cb\u003epubsub\u003c/b\u003e\u003c/a\u003e\t — Set the pubsub spec for an ocm repository\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"set"},{"content":"Usage ocm show [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for show\rSee Also Sub Commands ocm show tags\t— show dedicated tags of OCI artifacts ocm show versions\t— show dedicated versions (semver compliant) ","date":"0001-01-01","id":113,"permalink":"/docs/cli-reference/show/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm show [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for show\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/show/tags/\"\u003eocm show \u003cb\u003etags\u003c/b\u003e\u003c/a\u003e\t — show dedicated tags of OCI artifacts\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/show/versions/\"\u003eocm show \u003cb\u003eversions\u003c/b\u003e\u003c/a\u003e\t — show dedicated versions (semver compliant)\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"show"},{"content":"Usage ocm sign [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for sign\rSee Also Sub Commands ocm sign componentversions\t— Sign component version ocm sign hash\t— sign hash ","date":"0001-01-01","id":114,"permalink":"/docs/cli-reference/sign/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm sign [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for sign\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/sign/componentversions/\"\u003eocm sign \u003cb\u003ecomponentversions\u003c/b\u003e\u003c/a\u003e\t — Sign component version\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/sign/hash/\"\u003eocm sign \u003cb\u003ehash\u003c/b\u003e\u003c/a\u003e\t — sign hash\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"sign"},{"content":"Usage ocm add source-configuration [\u0026lt;options\u0026gt;] \u0026lt;target\u0026gt; {\u0026lt;configfile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\rOptions --access YAML blob access specification (YAML) --accessComponent string component for access specification --accessHostname string hostname used for access --accessRepository string repository or registry URL --accessType string type of blob access specification --accessVersion string version for access specification --artifactId string maven artifact id --body string body of a http request --bucket string bucket name --classifier string maven classifier --commit string git commit id --digest string blob digest --extension string maven extension name --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; source extra identity (default []) --globalAccess YAML access specification for global access --groupId string maven group id --header \u0026lt;name\u0026gt;:\u0026lt;value\u0026gt;,\u0026lt;value\u0026gt;,... http headers (default {}) -h, --help help for source-configuration --hint string (repository) hint for local artifacts --identityPath {\u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;} identity path for specification --input YAML blob input specification (YAML) --inputComponent string component name --inputCompress compress option for input --inputData !bytesBase64 data (string, !!string or !\u0026lt;base64\u0026gt; --inputExcludes stringArray excludes (path) for inputs --inputFollowSymlinks follow symbolic links during archive creation for inputs --inputFormattedJson YAML JSON formatted text --inputHelmRepository string helm repository base URL --inputIncludes stringArray includes (path) for inputs --inputJson YAML JSON formatted text --inputLibraries stringArray library path for inputs --inputPath filepath path field for input --inputPlatforms stringArray input filter for image platforms ([os]/[architecture]) --inputPreserveDir preserve directory in archive for inputs --inputRepository string repository or registry for inputs --inputText string utf8 text --inputType string type of blob input specification --inputValues YAML YAML based generic values for inputs --inputVariants stringArray (platform) variants for inputs --inputVersion string version info for inputs --inputYaml YAML YAML formatted text --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; source label (leading * indicates signature relevant, optional version separated by @) --mediaType string media type for artifact blob representation --name string source name --noredirect http redirect behavior --package string package or object name --reference string reference name --region string region name -s, --settings stringArray settings file with variable settings (yaml) --size int blob size --source YAML source meta data (yaml) --type string source type --url string artifact or server url --verb string http request method --version string source version\rDescription Add a source specification to a source config file used by ocm add sources.\nIt is possible to describe a single source via command line options. The meta data of this element is described by the argument of option \u0026ndash;source, which must be a YAML or JSON string. Alternatively, the name and version can be specified with the options \u0026ndash;name and \u0026ndash;version. With the option \u0026ndash;extra it is possible to add extra identity attributes. Explicitly specified options override values specified by the \u0026ndash;source option. (Note: Go templates are not supported for YAML-based option values. Besides this restriction, the finally composed element description is still processed by the selected template engine.)\nThe source type can be specified with the option \u0026ndash;type. Therefore, the minimal required meta data for elements can be completely specified by dedicated options and don\u0026rsquo;t need the YAML option.\nTo describe the content of this element one of the options \u0026ndash;access or \u0026ndash;input must be given. They take a YAML or JSON value describing an attribute set, also. The structure of those values is similar to the access or input fields of the description file format. Elements must follow the resource meta data description scheme of the component descriptor.\nIf not specified anywhere the artifact type will be defaulted to directoryTree.\nIf expressions/templates are used in the specification file an appropriate templater and the required settings might be required to provide a correct input validation.\nThis command accepts additional source specification files describing the sources to add to a component version.\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" The resource specification supports the following blob input types, specified with the field type in the input field:\nInput type binary\nThis blob type is used to provide base64 encoded binary content. The specification supports the following fields:\ndata []byte\nThe binary data to provide.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputData, \u0026ndash;mediaType\nInput type dir\nThe path must denote a directory relative to the resources file, which is packed with tar and optionally compressed if the compress field is set to true. If the field preserveDir is set to true the directory itself is added to the tar. If the field followSymLinks is set to true, symbolic links are not packed but their targets files or folders. With the list fields includeFiles and excludeFiles it is possible to specify which files should be included or excluded. The values are regular expression used to match relative file paths. If no includes are specified all file not explicitly excluded are used.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the file path to directory relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/x-tar and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the file content should be stored compressed or not.\npreserveDir bool\nThis OPTIONAL property describes whether the specified directory with its basename should be included as top level folder.\nfollowSymlinks bool\nThis OPTIONAL property describes whether symbolic links should be followed or included as links.\nexcludeFiles list of regex\nThis OPTIONAL property describes regular expressions used to match files that should NOT be included in the tar file. It takes precedence over the include match.\nincludeFiles list of regex\nThis OPTIONAL property describes regular expressions used to match files that should be included in the tar file. If this option is not given all files not explicitly excluded are used.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputExcludes, \u0026ndash;inputFollowSymlinks, \u0026ndash;inputIncludes, \u0026ndash;inputPath, \u0026ndash;inputPreserveDir, \u0026ndash;mediaType\nInput type docker\nThe path must denote an image tag that can be found in the local docker daemon. The denoted image is packed as OCI artifact set. The OCI image will contain an informational back link to the component version using the manifest annotation software.ocm/component-version.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the image name to import from the local docker daemon.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputPath\nInput type dockermulti\nThis input type describes the composition of a multi-platform OCI image. The various variants are taken from the local docker daemon. They should be built with the \u0026ldquo;buildx\u0026rdquo; command for cross platform docker builds (see https://ocm.software/docs/tutorials/best-practices/#building-multi-architecture-images). The denoted images, as well as the wrapping image index, are packed as OCI artifact set. They will contain an informational back link to the component version using the manifest annotation software.ocm/component-version.\nThis blob type specification supports the following fields:\nvariants []string\nThis REQUIRED property describes a set of image names to import from the local docker daemon used to compose a resulting image index.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputVariants\nInput type file\nThe path must denote a file relative the resources file. The content is compressed if the compress field is set to true.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the path to the file relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;mediaType\nInput type helm\nThe path must denote an helm chart archive or directory relative to the resources file or a chart name in a helm chart repository. The denoted chart is packed as an OCI artifact set. For the filesystem version additional provider info is taken from a file with the same name and the suffix .prov.\nIf the chart should just be stored as plain archive, please use the type file or dir, instead.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the file path to the helm chart relative to the resource file location.\nversion string\nThis OPTIONAL property can be set to configure an explicit version hint. If not specified the version from the chart will be used. Basically, it is a good practice to use the component version for local resources This can be achieved by using templating for this attribute in the resource file.\nhelmRepository string\nThis OPTIONAL property can be set, if the helm chart should be loaded from a helm repository instead of the local filesystem. It describes the base URL of the chart repository. If specified, the path field must describe the name of the chart in the chart repository, and version must describe the version of the chart imported from the chart repository\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\ncaCertFile string\nThis OPTIONAL property can be used to specify a relative filename for the TLS root certificate used to access a helm repository.\ncaCert string\nThis OPTIONAL property can be used to specify a TLS root certificate used to access a helm repository.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputHelmRepository, \u0026ndash;inputPath, \u0026ndash;inputVersion, \u0026ndash;mediaType\nInput type maven\nThe repoUrl is the url pointing either to the http endpoint of a maven repository (e.g. https://repo.maven.apache.org/maven2/) or to a file system based maven repository (e.g. file://local/directory).\nThis blob type specification supports the following fields:\nrepoUrl string\nThis REQUIRED property describes the url from which the resource is to be accessed.\ngroupId string\nThis REQUIRED property describes the groupId of a maven artifact.\nartifactId string\nThis REQUIRED property describes artifactId of a maven artifact.\nversion string\nThis REQUIRED property describes the version of a maven artifact.\nclassifier string\nThis OPTIONAL property describes the classifier of a maven artifact.\nextension string\nThis OPTIONAL property describes the extension of a maven artifact.\nOptions used to configure fields: \u0026ndash;artifactId, \u0026ndash;classifier, \u0026ndash;extension, \u0026ndash;groupId, \u0026ndash;inputPath, \u0026ndash;inputVersion, \u0026ndash;url\nInput type npm\nThe registry is the url pointing to the npm registry from which a resource is downloaded.\nThis blob type specification supports the following fields:\nregistry string\nThis REQUIRED property describes the url from which the resource is to be downloaded.\npackage string\nThis REQUIRED property describes the name of the package to download.\nversion string\nThis is an OPTIONAL property describing the version of the package to download. If not defined, latest will be used automatically.\nOptions used to configure fields: \u0026ndash;inputRepository, \u0026ndash;inputVersion, \u0026ndash;package\nInput type ociArtifact\nThis input type is used to import an OCI image from an OCI registry. If it is a multi-arch image the set of platforms to be imported can be filtered using the \u0026ldquo;platforms\u0026rdquo; attribute. The path must denote an OCI image reference.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the OCI image reference of the image to import.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nplatforms []string\nThis OPTIONAL property can be used to filter index artifacts to include only images for dedicated operating systems/architectures. Elements must meet the syntax [\u0026lt;os\u0026gt;]/[\u0026lt;architecture\u0026gt;].\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;inputPlatforms, \u0026ndash;mediaType\nInput type ociImage\nDEPRECATED: This type is deprecated, please use ociArtifact instead.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;inputPlatforms, \u0026ndash;mediaType\nInput type ocm\nThis input type allows to get a resource artifact from an OCM repository.\nThis blob type specification supports the following fields:\nocmRepository repository specification\nThis REQUIRED property describes the OCM repository specification\ncomponent string\nThis REQUIRED property describes the component na,e\nversion string\nThis REQUIRED property describes the version of a maven artifact.\nresourceRef relative resource reference\nThis REQUIRED property describes the resource reference for the desired resource relative to the given component version .\nOptions used to configure fields: \u0026ndash;identityPath, \u0026ndash;inputComponent, \u0026ndash;inputRepository, \u0026ndash;inputVersion\nInput type spiff\nThe path must denote a spiff template relative the resources file. The content is compressed if the compress field is set to true.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the path to the file relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nvalues map[string]any\nThis OPTIONAL property describes an additional value binding for the template processing. It will be available under the node inputvalues.\nlibraries []string\nThis OPTIONAL property describes a list of spiff libraries to include in template processing.\nThe variable settings from the command line are available as binding, also. They are provided under the node values.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputLibraries, \u0026ndash;inputPath, \u0026ndash;inputValues, \u0026ndash;mediaType\nInput type utf8\nThis blob type is used to provide inline text based content (UTF8). The specification supports the following fields:\ntext string\nThe utf8 string content to provide.\njson JSON or JSON string interpreted as JSON\nThe content emitted as JSON.\nformattedJson YAML/JSON or JSON/YAML string interpreted as JSON\nThe content emitted as formatted JSON.\nyaml AML/JSON or JSON/YAML string interpreted as YAML\nThe content emitted as YAML.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputFormattedJson, \u0026ndash;inputJson, \u0026ndash;inputText, \u0026ndash;inputYaml, \u0026ndash;mediaType\nInput type wget\nThe url is the url pointing to the http endpoint from which a resource is downloaded. The mimeType can be used to specify the MIME type of the resource.\nThis blob type specification supports the following fields:\nurl string\nThis REQUIRED property describes the url from which the resource is to be downloaded.\nmediaType string\nThis OPTIONAL property describes the media type of the resource to be downloaded. If omitted, ocm tries to read the mediaType from the Content-Type header of the http response. If the mediaType cannot be set from the Content-Type header as well, ocm tries to deduct the mediaType from the URL. If that is not possible either, the default media type is defaulted to application/octet-stream.\nheader map[string][]string\nThis OPTIONAL property describes the http headers to be set in the http request to the server.\nverb string\nThis OPTIONAL property describes the http verb (also known as http request method) for the http request. If omitted, the http verb is defaulted to GET.\nbody []byte\nThis OPTIONAL property describes the http body to be included in the request.\nnoredirect bool\nThis OPTIONAL property describes whether http redirects should be disabled. If omitted, it is defaulted to false (so, per default, redirects are enabled).\nOptions used to configure fields: \u0026ndash;body, \u0026ndash;header, \u0026ndash;mediaType, \u0026ndash;noredirect, \u0026ndash;url, \u0026ndash;verb\nThe following list describes the supported access methods, their versions and specification formats. Typically there is special support for the CLI artifact add commands. The access method specification can be put below the access field. If always requires the field type describing the kind and version shown below.\nAccess type gitHub\nThis method implements the access of the content of a git commit stored in a GitHub repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nRepository URL with or without scheme.\nref (optional) string\nOriginal ref used to get the commit from\ncommit string\nThe sha/id of the git commit\nOptions used to configure fields: \u0026ndash;accessHostname, \u0026ndash;accessRepository, \u0026ndash;commit\nAccess type helm\nThis method implements the access of a Helm chart stored in a Helm repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nhelmRepository string\nHelm repository URL.\nhelmChart string\nThe name of the Helm chart and its version separated by a colon.\nversion string\nThe version of the Helm chart if not specified as part of the chart name.\ncaCert string\nAn optional TLS root certificate.\nkeyring string\nAn optional keyring used to verify the chart.\nIt uses the consumer identity type HelmChartRepository with the fields for a hostpath identity matcher (see ocm get credentials).\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type localBlob\nThis method is used to store a resource blob along with the component descriptor on behalf of the hosting OCM repository.\nIts implementation is specific to the implementation of OCM repository used to read the component descriptor. Every repository implementation may decide how and where local blobs are stored, but it MUST provide an implementation for this method.\nRegardless of the chosen implementation the attribute specification is defined globally the same.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nlocalReference string\nRepository type specific location information as string. The value may encode any deep structure, but typically just an access path is sufficient.\nmediaType string\nThe media type of the blob used to store the resource. It may add format information like +tar or +gzip.\nreferenceName (optional) string\nThis optional attribute may contain identity information used by other repositories to restore some global access with an identity related to the original source.\nFor example, if an OCI artifact originally referenced using the access method ociArtifact is stored during some transport step as local artifact, the reference name can be set to its original repository name. An import step into an OCI based OCM repository may then decide to make this artifact available again as regular OCI artifact.\nglobalAccess (optional) access method specification\nIf a resource blob is stored locally, the repository implementation may decide to provide an external access information (independent of the OCM model).\nFor example, an OCI artifact stored as local blob can be additionally stored as regular OCI artifact in an OCI registry.\nThis additional external access information can be added using a second external access method specification.\nOptions used to configure fields: \u0026ndash;globalAccess, \u0026ndash;hint, \u0026ndash;mediaType, \u0026ndash;reference\nAccess type maven\nThis method implements the access of a Maven artifact in a Maven repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nURL of the Maven repository\ngroupId string\nThe groupId of the Maven artifact\nartifactId string\nThe artifactId of the Maven artifact\nversion string\nThe version name of the Maven artifact\nclassifier string\nThe optional classifier of the Maven artifact\nextension string\nThe optional extension of the Maven artifact\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;artifactId, \u0026ndash;classifier, \u0026ndash;extension, \u0026ndash;groupId\nAccess type none\ndummy resource with no access\nAccess type npm\nThis method implements the access of an NPM package in an NPM registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregistry string\nBase URL of the NPM registry.\npackage string\nThe name of the NPM package\nversion string\nThe version name of the NPM package\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type ociArtifact\nThis method implements the access of an OCI artifact stored in an OCI registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI image/artifact reference following the possible docker schemes:\n\u0026lt;repo\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;digest\u0026gt;@\u0026lt;tag\u0026gt; [\u0026lt;port\u0026gt;]/\u0026lt;repo path\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;version\u0026gt;@\u0026lt;tag\u0026gt; Options used to configure fields: \u0026ndash;reference\nAccess type ociBlob\nThis method implements the access of an OCI blob stored in an OCI repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI repository reference (this artifact name used to store the blob).\nmediaType string\nThe media type of the blob\ndigest string\nThe digest of the blob used to access the blob in the OCI repository.\nsize integer\nThe size of the blob\nOptions used to configure fields: \u0026ndash;digest, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;size\nAccess type ocm\nThis method implements the access of any resource artifact stored in an OCM repository. Only repository types supporting remote access should be used.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nocmRepository json\nThe repository spec for the OCM repository\ncomponent string\n(Optional) The name of the component. The default is the own component.\nversion string\n(Optional) The version of the component. The default is the own component version.\nresourceRef relative resource ref\nThe resource reference of the denoted resource relative to the given component version.\nIt uses the consumer identity and credentials for the intermediate repositories and the final resource access.\nOptions used to configure fields: \u0026ndash;accessComponent, \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;identityPath\nAccess type s3\nThis method implements the access of a blob stored in an S3 bucket.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucket string\nThe name of the S3 bucket containing the blob\nkey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nVersion v2\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucketName string\nThe name of the S3 bucket containing the blob\nobjectKey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nOptions used to configure fields: \u0026ndash;accessVersion, \u0026ndash;bucket, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;region\nAccess type wget\nThis method implements access to resources stored on an http server.\nThe following versions are supported:\nVersion v1\nThe url is the url pointing to the http endpoint from which a resource is downloaded. The mimeType can be used to specify the MIME type of the resource.\nThis blob type specification supports the following fields:\nurl string This REQUIRED property describes the url from which the resource is to be downloaded.\nmediaType string This OPTIONAL property describes the media type of the resource to be downloaded. If omitted, ocm tries to read the mediaType from the Content-Type header of the http response. If the mediaType cannot be set from the Content-Type header as well, ocm tries to deduct the mediaType from the URL. If that is not possible either, the default media type is defaulted to application/octet-stream.\nheader map[string][]string This OPTIONAL property describes the http headers to be set in the http request to the server.\nverb string This OPTIONAL property describes the http verb (also known as http request method) for the http request. If omitted, the http verb is defaulted to GET.\nbody []byte This OPTIONAL property describes the http body to be included in the request.\nnoredirect bool This OPTIONAL property describes whether http redirects should be disabled. If omitted, it is defaulted to false (so, per default, redirects are enabled).\nOptions used to configure fields: \u0026ndash;body, \u0026ndash;header, \u0026ndash;mediaType, \u0026ndash;noredirect, \u0026ndash;url, \u0026ndash;verb\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" Examples $ ocm add source-config sources.yaml --name sources --type filesystem --access \u0026#39;{ \u0026#34;type\u0026#34;: \u0026#34;gitHub\u0026#34;, \u0026#34;repoUrl\u0026#34;: \u0026#34;ocm.software/ocm\u0026#34;, \u0026#34;commit\u0026#34;: \u0026#34;xyz\u0026#34; }\u0026#39;\rSee Also ocm add\t— Add elements to a component repository or component version ","date":"0001-01-01","id":115,"permalink":"/docs/cli-reference/add/source-configuration/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm add source-configuration [\u0026lt;options\u0026gt;] \u0026lt;target\u0026gt; {\u0026lt;configfile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --access YAML blob access specification (YAML)\n --accessComponent string component for access specification\n --accessHostname string hostname used for access\n --accessRepository string repository or registry URL\n --accessType string type of blob access specification\n --accessVersion string version for access specification\n --artifactId string maven artifact id\n --body string body of a http request\n --bucket string bucket name\n --classifier string maven classifier\n --commit string git commit id\n --digest string blob digest\n --extension string maven extension name\n --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; source extra identity (default [])\n --globalAccess YAML access specification for global access\n --groupId string maven group id\n --header \u0026lt;name\u0026gt;:\u0026lt;value\u0026gt;,\u0026lt;value\u0026gt;,... http headers (default {})\n -h, --help help for source-configuration\n --hint string (repository) hint for local artifacts\n --identityPath {\u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;} identity path for specification\n --input YAML blob input specification (YAML)\n --inputComponent string component name\n --inputCompress compress option for input\n --inputData !bytesBase64 data (string, !!string or !\u0026lt;base64\u0026gt;\n --inputExcludes stringArray excludes (path) for inputs\n --inputFollowSymlinks follow symbolic links during archive creation for inputs\n --inputFormattedJson YAML JSON formatted text\n --inputHelmRepository string helm repository base URL\n --inputIncludes stringArray includes (path) for inputs\n --inputJson YAML JSON formatted text\n --inputLibraries stringArray library path for inputs\n --inputPath filepath path field for input\n --inputPlatforms stringArray input filter for image platforms ([os]/[architecture])\n --inputPreserveDir preserve directory in archive for inputs\n --inputRepository string repository or registry for inputs\n --inputText string utf8 text\n --inputType string type of blob input specification\n --inputValues YAML YAML based generic values for inputs\n --inputVariants stringArray (platform) variants for inputs\n --inputVersion string version info for inputs\n --inputYaml YAML YAML formatted text\n --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; source label (leading * indicates signature relevant, optional version separated by @)\n --mediaType string media type for artifact blob representation\n --name string source name\n --noredirect http redirect behavior\n --package string package or object name\n --reference string reference name\n --region string region name\n -s, --settings stringArray settings file with variable settings (yaml)\n --size int blob size\n --source YAML source meta data (yaml)\n --type string source type\n --url string artifact or server url\n --verb string http request method\n --version string source version\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAdd a source specification to a source config file used by \u003ca href=\"/docs/cli-reference/add/sources/\"\u003eocm add sources\u003c/a\u003e.\u003c/p\u003e","tags":[],"title":"source-configuration"},{"content":"Usage ocm add sources [\u0026lt;options\u0026gt;] [\u0026lt;target\u0026gt;] {\u0026lt;resourcefile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\rOptions --access YAML blob access specification (YAML) --accessComponent string component for access specification --accessHostname string hostname used for access --accessRepository string repository or registry URL --accessType string type of blob access specification --accessVersion string version for access specification --addenv access environment for templating --artifactId string maven artifact id --body string body of a http request --bucket string bucket name --classifier string maven classifier --commit string git commit id --digest string blob digest --dry-run evaluate and print source specifications --extension string maven extension name --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; source extra identity (default []) -F, --file string target file/directory (default \u0026#34;component-archive\u0026#34;) --globalAccess YAML access specification for global access --groupId string maven group id --header \u0026lt;name\u0026gt;:\u0026lt;value\u0026gt;,\u0026lt;value\u0026gt;,... http headers (default {}) -h, --help help for sources --hint string (repository) hint for local artifacts --identityPath {\u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;} identity path for specification --input YAML blob input specification (YAML) --inputComponent string component name --inputCompress compress option for input --inputData !bytesBase64 data (string, !!string or !\u0026lt;base64\u0026gt; --inputExcludes stringArray excludes (path) for inputs --inputFollowSymlinks follow symbolic links during archive creation for inputs --inputFormattedJson YAML JSON formatted text --inputHelmRepository string helm repository base URL --inputIncludes stringArray includes (path) for inputs --inputJson YAML JSON formatted text --inputLibraries stringArray library path for inputs --inputPath filepath path field for input --inputPlatforms stringArray input filter for image platforms ([os]/[architecture]) --inputPreserveDir preserve directory in archive for inputs --inputRepository string repository or registry for inputs --inputText string utf8 text --inputType string type of blob input specification --inputValues YAML YAML based generic values for inputs --inputVariants stringArray (platform) variants for inputs --inputVersion string version info for inputs --inputYaml YAML YAML formatted text --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; source label (leading * indicates signature relevant, optional version separated by @) --mediaType string media type for artifact blob representation --name string source name --noredirect http redirect behavior -O, --output string output file for dry-run --package string package or object name -P, --preserve-signature preserve existing signatures --reference string reference name --region string region name -R, --replace replace existing elements -s, --settings stringArray settings file with variable settings (yaml) --size int blob size --source YAML source meta data (yaml) --templater string templater to use (go, none, spiff, subst) (default \u0026#34;subst\u0026#34;) --type string source type --url string artifact or server url --verb string http request method --version string source version\rDescription Add information about the sources, e.g. commits in a Github repository, that have been used to create the resources specified in a resource file to a component version. So far only component archives are supported as target.\nThis command accepts source specification files describing the sources to add to a component version. Elements must follow the source meta data description scheme of the component descriptor. Besides referential sources using the access attribute to describe the access method, it is possible to describe local sources fed by local data using the input field (see below).\nThe description file might contain:\na single source a list of sources under the key sources a list of yaml documents with a single source or source list It is possible to describe a single source via command line options. The meta data of this element is described by the argument of option \u0026ndash;source, which must be a YAML or JSON string. Alternatively, the name and version can be specified with the options \u0026ndash;name and \u0026ndash;version. With the option \u0026ndash;extra it is possible to add extra identity attributes. Explicitly specified options override values specified by the \u0026ndash;source option. (Note: Go templates are not supported for YAML-based option values. Besides this restriction, the finally composed element description is still processed by the selected template engine.)\nThe source type can be specified with the option \u0026ndash;type. Therefore, the minimal required meta data for elements can be completely specified by dedicated options and don\u0026rsquo;t need the YAML option.\nTo describe the content of this element one of the options \u0026ndash;access or \u0026ndash;input must be given. They take a YAML or JSON value describing an attribute set, also. The structure of those values is similar to the access or input fields of the description file format.\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" The resource specification supports the following blob input types, specified with the field type in the input field:\nInput type binary\nThis blob type is used to provide base64 encoded binary content. The specification supports the following fields:\ndata []byte\nThe binary data to provide.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputData, \u0026ndash;mediaType\nInput type dir\nThe path must denote a directory relative to the resources file, which is packed with tar and optionally compressed if the compress field is set to true. If the field preserveDir is set to true the directory itself is added to the tar. If the field followSymLinks is set to true, symbolic links are not packed but their targets files or folders. With the list fields includeFiles and excludeFiles it is possible to specify which files should be included or excluded. The values are regular expression used to match relative file paths. If no includes are specified all file not explicitly excluded are used.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the file path to directory relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/x-tar and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the file content should be stored compressed or not.\npreserveDir bool\nThis OPTIONAL property describes whether the specified directory with its basename should be included as top level folder.\nfollowSymlinks bool\nThis OPTIONAL property describes whether symbolic links should be followed or included as links.\nexcludeFiles list of regex\nThis OPTIONAL property describes regular expressions used to match files that should NOT be included in the tar file. It takes precedence over the include match.\nincludeFiles list of regex\nThis OPTIONAL property describes regular expressions used to match files that should be included in the tar file. If this option is not given all files not explicitly excluded are used.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputExcludes, \u0026ndash;inputFollowSymlinks, \u0026ndash;inputIncludes, \u0026ndash;inputPath, \u0026ndash;inputPreserveDir, \u0026ndash;mediaType\nInput type docker\nThe path must denote an image tag that can be found in the local docker daemon. The denoted image is packed as OCI artifact set. The OCI image will contain an informational back link to the component version using the manifest annotation software.ocm/component-version.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the image name to import from the local docker daemon.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputPath\nInput type dockermulti\nThis input type describes the composition of a multi-platform OCI image. The various variants are taken from the local docker daemon. They should be built with the \u0026ldquo;buildx\u0026rdquo; command for cross platform docker builds (see https://ocm.software/docs/tutorials/best-practices/#building-multi-architecture-images). The denoted images, as well as the wrapping image index, are packed as OCI artifact set. They will contain an informational back link to the component version using the manifest annotation software.ocm/component-version.\nThis blob type specification supports the following fields:\nvariants []string\nThis REQUIRED property describes a set of image names to import from the local docker daemon used to compose a resulting image index.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputVariants\nInput type file\nThe path must denote a file relative the resources file. The content is compressed if the compress field is set to true.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the path to the file relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;mediaType\nInput type helm\nThe path must denote an helm chart archive or directory relative to the resources file or a chart name in a helm chart repository. The denoted chart is packed as an OCI artifact set. For the filesystem version additional provider info is taken from a file with the same name and the suffix .prov.\nIf the chart should just be stored as plain archive, please use the type file or dir, instead.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the file path to the helm chart relative to the resource file location.\nversion string\nThis OPTIONAL property can be set to configure an explicit version hint. If not specified the version from the chart will be used. Basically, it is a good practice to use the component version for local resources This can be achieved by using templating for this attribute in the resource file.\nhelmRepository string\nThis OPTIONAL property can be set, if the helm chart should be loaded from a helm repository instead of the local filesystem. It describes the base URL of the chart repository. If specified, the path field must describe the name of the chart in the chart repository, and version must describe the version of the chart imported from the chart repository\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\ncaCertFile string\nThis OPTIONAL property can be used to specify a relative filename for the TLS root certificate used to access a helm repository.\ncaCert string\nThis OPTIONAL property can be used to specify a TLS root certificate used to access a helm repository.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputHelmRepository, \u0026ndash;inputPath, \u0026ndash;inputVersion, \u0026ndash;mediaType\nInput type maven\nThe repoUrl is the url pointing either to the http endpoint of a maven repository (e.g. https://repo.maven.apache.org/maven2/) or to a file system based maven repository (e.g. file://local/directory).\nThis blob type specification supports the following fields:\nrepoUrl string\nThis REQUIRED property describes the url from which the resource is to be accessed.\ngroupId string\nThis REQUIRED property describes the groupId of a maven artifact.\nartifactId string\nThis REQUIRED property describes artifactId of a maven artifact.\nversion string\nThis REQUIRED property describes the version of a maven artifact.\nclassifier string\nThis OPTIONAL property describes the classifier of a maven artifact.\nextension string\nThis OPTIONAL property describes the extension of a maven artifact.\nOptions used to configure fields: \u0026ndash;artifactId, \u0026ndash;classifier, \u0026ndash;extension, \u0026ndash;groupId, \u0026ndash;inputPath, \u0026ndash;inputVersion, \u0026ndash;url\nInput type npm\nThe registry is the url pointing to the npm registry from which a resource is downloaded.\nThis blob type specification supports the following fields:\nregistry string\nThis REQUIRED property describes the url from which the resource is to be downloaded.\npackage string\nThis REQUIRED property describes the name of the package to download.\nversion string\nThis is an OPTIONAL property describing the version of the package to download. If not defined, latest will be used automatically.\nOptions used to configure fields: \u0026ndash;inputRepository, \u0026ndash;inputVersion, \u0026ndash;package\nInput type ociArtifact\nThis input type is used to import an OCI image from an OCI registry. If it is a multi-arch image the set of platforms to be imported can be filtered using the \u0026ldquo;platforms\u0026rdquo; attribute. The path must denote an OCI image reference.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the OCI image reference of the image to import.\nrepository string\nThis OPTIONAL property can be used to specify the repository hint for the generated local artifact access. It is prefixed by the component name if it does not start with slash \u0026ldquo;/\u0026rdquo;.\nplatforms []string\nThis OPTIONAL property can be used to filter index artifacts to include only images for dedicated operating systems/architectures. Elements must meet the syntax [\u0026lt;os\u0026gt;]/[\u0026lt;architecture\u0026gt;].\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;inputPlatforms, \u0026ndash;mediaType\nInput type ociImage\nDEPRECATED: This type is deprecated, please use ociArtifact instead.\nOptions used to configure fields: \u0026ndash;hint, \u0026ndash;inputCompress, \u0026ndash;inputPath, \u0026ndash;inputPlatforms, \u0026ndash;mediaType\nInput type ocm\nThis input type allows to get a resource artifact from an OCM repository.\nThis blob type specification supports the following fields:\nocmRepository repository specification\nThis REQUIRED property describes the OCM repository specification\ncomponent string\nThis REQUIRED property describes the component na,e\nversion string\nThis REQUIRED property describes the version of a maven artifact.\nresourceRef relative resource reference\nThis REQUIRED property describes the resource reference for the desired resource relative to the given component version .\nOptions used to configure fields: \u0026ndash;identityPath, \u0026ndash;inputComponent, \u0026ndash;inputRepository, \u0026ndash;inputVersion\nInput type spiff\nThe path must denote a spiff template relative the resources file. The content is compressed if the compress field is set to true.\nThis blob type specification supports the following fields:\npath string\nThis REQUIRED property describes the path to the file relative to the resource file location.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nvalues map[string]any\nThis OPTIONAL property describes an additional value binding for the template processing. It will be available under the node inputvalues.\nlibraries []string\nThis OPTIONAL property describes a list of spiff libraries to include in template processing.\nThe variable settings from the command line are available as binding, also. They are provided under the node values.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputLibraries, \u0026ndash;inputPath, \u0026ndash;inputValues, \u0026ndash;mediaType\nInput type utf8\nThis blob type is used to provide inline text based content (UTF8). The specification supports the following fields:\ntext string\nThe utf8 string content to provide.\njson JSON or JSON string interpreted as JSON\nThe content emitted as JSON.\nformattedJson YAML/JSON or JSON/YAML string interpreted as JSON\nThe content emitted as formatted JSON.\nyaml AML/JSON or JSON/YAML string interpreted as YAML\nThe content emitted as YAML.\nmediaType string\nThis OPTIONAL property describes the media type to store with the local blob. The default media type is application/octet-stream and application/gzip if compression is enabled.\ncompress bool\nThis OPTIONAL property describes whether the content should be stored compressed or not.\nOptions used to configure fields: \u0026ndash;inputCompress, \u0026ndash;inputFormattedJson, \u0026ndash;inputJson, \u0026ndash;inputText, \u0026ndash;inputYaml, \u0026ndash;mediaType\nInput type wget\nThe url is the url pointing to the http endpoint from which a resource is downloaded. The mimeType can be used to specify the MIME type of the resource.\nThis blob type specification supports the following fields:\nurl string\nThis REQUIRED property describes the url from which the resource is to be downloaded.\nmediaType string\nThis OPTIONAL property describes the media type of the resource to be downloaded. If omitted, ocm tries to read the mediaType from the Content-Type header of the http response. If the mediaType cannot be set from the Content-Type header as well, ocm tries to deduct the mediaType from the URL. If that is not possible either, the default media type is defaulted to application/octet-stream.\nheader map[string][]string\nThis OPTIONAL property describes the http headers to be set in the http request to the server.\nverb string\nThis OPTIONAL property describes the http verb (also known as http request method) for the http request. If omitted, the http verb is defaulted to GET.\nbody []byte\nThis OPTIONAL property describes the http body to be included in the request.\nnoredirect bool\nThis OPTIONAL property describes whether http redirects should be disabled. If omitted, it is defaulted to false (so, per default, redirects are enabled).\nOptions used to configure fields: \u0026ndash;body, \u0026ndash;header, \u0026ndash;mediaType, \u0026ndash;noredirect, \u0026ndash;url, \u0026ndash;verb\nThe following list describes the supported access methods, their versions and specification formats. Typically there is special support for the CLI artifact add commands. The access method specification can be put below the access field. If always requires the field type describing the kind and version shown below.\nAccess type gitHub\nThis method implements the access of the content of a git commit stored in a GitHub repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nRepository URL with or without scheme.\nref (optional) string\nOriginal ref used to get the commit from\ncommit string\nThe sha/id of the git commit\nOptions used to configure fields: \u0026ndash;accessHostname, \u0026ndash;accessRepository, \u0026ndash;commit\nAccess type helm\nThis method implements the access of a Helm chart stored in a Helm repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nhelmRepository string\nHelm repository URL.\nhelmChart string\nThe name of the Helm chart and its version separated by a colon.\nversion string\nThe version of the Helm chart if not specified as part of the chart name.\ncaCert string\nAn optional TLS root certificate.\nkeyring string\nAn optional keyring used to verify the chart.\nIt uses the consumer identity type HelmChartRepository with the fields for a hostpath identity matcher (see ocm get credentials).\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type localBlob\nThis method is used to store a resource blob along with the component descriptor on behalf of the hosting OCM repository.\nIts implementation is specific to the implementation of OCM repository used to read the component descriptor. Every repository implementation may decide how and where local blobs are stored, but it MUST provide an implementation for this method.\nRegardless of the chosen implementation the attribute specification is defined globally the same.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nlocalReference string\nRepository type specific location information as string. The value may encode any deep structure, but typically just an access path is sufficient.\nmediaType string\nThe media type of the blob used to store the resource. It may add format information like +tar or +gzip.\nreferenceName (optional) string\nThis optional attribute may contain identity information used by other repositories to restore some global access with an identity related to the original source.\nFor example, if an OCI artifact originally referenced using the access method ociArtifact is stored during some transport step as local artifact, the reference name can be set to its original repository name. An import step into an OCI based OCM repository may then decide to make this artifact available again as regular OCI artifact.\nglobalAccess (optional) access method specification\nIf a resource blob is stored locally, the repository implementation may decide to provide an external access information (independent of the OCM model).\nFor example, an OCI artifact stored as local blob can be additionally stored as regular OCI artifact in an OCI registry.\nThis additional external access information can be added using a second external access method specification.\nOptions used to configure fields: \u0026ndash;globalAccess, \u0026ndash;hint, \u0026ndash;mediaType, \u0026ndash;reference\nAccess type maven\nThis method implements the access of a Maven artifact in a Maven repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nrepoUrl string\nURL of the Maven repository\ngroupId string\nThe groupId of the Maven artifact\nartifactId string\nThe artifactId of the Maven artifact\nversion string\nThe version name of the Maven artifact\nclassifier string\nThe optional classifier of the Maven artifact\nextension string\nThe optional extension of the Maven artifact\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;artifactId, \u0026ndash;classifier, \u0026ndash;extension, \u0026ndash;groupId\nAccess type none\ndummy resource with no access\nAccess type npm\nThis method implements the access of an NPM package in an NPM registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregistry string\nBase URL of the NPM registry.\npackage string\nThe name of the NPM package\nversion string\nThe version name of the NPM package\nOptions used to configure fields: \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;package\nAccess type ociArtifact\nThis method implements the access of an OCI artifact stored in an OCI registry.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI image/artifact reference following the possible docker schemes:\n\u0026lt;repo\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;digest\u0026gt;@\u0026lt;tag\u0026gt; [\u0026lt;port\u0026gt;]/\u0026lt;repo path\u0026gt;/\u0026lt;artifact\u0026gt;:\u0026lt;version\u0026gt;@\u0026lt;tag\u0026gt; Options used to configure fields: \u0026ndash;reference\nAccess type ociBlob\nThis method implements the access of an OCI blob stored in an OCI repository.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nimageReference string\nOCI repository reference (this artifact name used to store the blob).\nmediaType string\nThe media type of the blob\ndigest string\nThe digest of the blob used to access the blob in the OCI repository.\nsize integer\nThe size of the blob\nOptions used to configure fields: \u0026ndash;digest, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;size\nAccess type ocm\nThis method implements the access of any resource artifact stored in an OCM repository. Only repository types supporting remote access should be used.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nocmRepository json\nThe repository spec for the OCM repository\ncomponent string\n(Optional) The name of the component. The default is the own component.\nversion string\n(Optional) The version of the component. The default is the own component version.\nresourceRef relative resource ref\nThe resource reference of the denoted resource relative to the given component version.\nIt uses the consumer identity and credentials for the intermediate repositories and the final resource access.\nOptions used to configure fields: \u0026ndash;accessComponent, \u0026ndash;accessRepository, \u0026ndash;accessVersion, \u0026ndash;identityPath\nAccess type s3\nThis method implements the access of a blob stored in an S3 bucket.\nThe following versions are supported:\nVersion v1\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucket string\nThe name of the S3 bucket containing the blob\nkey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nVersion v2\nThe type specific specification fields are:\nregion (optional) string\nOCI repository reference (this artifact name used to store the blob).\nbucketName string\nThe name of the S3 bucket containing the blob\nobjectKey string\nThe key of the desired blob\nversion (optional) string\nThe key of the desired blob\nmediaType (optional) string\nThe media type of the content\nOptions used to configure fields: \u0026ndash;accessVersion, \u0026ndash;bucket, \u0026ndash;mediaType, \u0026ndash;reference, \u0026ndash;region\nAccess type wget\nThis method implements access to resources stored on an http server.\nThe following versions are supported:\nVersion v1\nThe url is the url pointing to the http endpoint from which a resource is downloaded. The mimeType can be used to specify the MIME type of the resource.\nThis blob type specification supports the following fields:\nurl string This REQUIRED property describes the url from which the resource is to be downloaded.\nmediaType string This OPTIONAL property describes the media type of the resource to be downloaded. If omitted, ocm tries to read the mediaType from the Content-Type header of the http response. If the mediaType cannot be set from the Content-Type header as well, ocm tries to deduct the mediaType from the URL. If that is not possible either, the default media type is defaulted to application/octet-stream.\nheader map[string][]string This OPTIONAL property describes the http headers to be set in the http request to the server.\nverb string This OPTIONAL property describes the http verb (also known as http request method) for the http request. If omitted, the http verb is defaulted to GET.\nbody []byte This OPTIONAL property describes the http body to be included in the request.\nnoredirect bool This OPTIONAL property describes whether http redirects should be disabled. If omitted, it is defaulted to false (so, per default, redirects are enabled).\nOptions used to configure fields: \u0026ndash;body, \u0026ndash;header, \u0026ndash;mediaType, \u0026ndash;noredirect, \u0026ndash;url, \u0026ndash;verb\nThe \u0026ndash;replace option allows users to specify whether adding an element with the same name and extra identity but different version as an existing element, append (false) or replace (true) the existing element.\nThe \u0026ndash;preserve-signature option prohibits changes of signature relevant elements.\nAll yaml/json defined resources can be templated. Variables are specified as regular arguments following the syntax \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;. Additionally settings can be specified by a yaml file using the \u0026ndash;settings option. With the option \u0026ndash;addenv environment variables are added to the binding. Values are overwritten in the order environment, settings file, command line settings.\nNote: Variable names are case-sensitive.\nExample:\n\u0026lt;command\u003e \u0026lt;options\u003e -- MY_VAL=test \u0026lt;args\u003e There are several templaters that can be selected by the \u0026ndash;templater option:\ngo go templating supports complex values.\nkey: subkey: \"abc {{.MY_VAL}}\" none do not do any substitution.\nspiff spiff templating.\nIt supports complex values. the settings are accessible using the binding values.\nkey: subkey: \"abc (( values.MY_VAL ))\" subst simple value substitution with the drone/envsubst templater.\nIt supports string values, only. Complex settings will be json encoded.\nkey: subkey: \"abc ${MY_VAL}\" Examples $ ocm add sources --file path/to/cafile sources.yaml\rSee Also ocm add\t— Add elements to a component repository or component version ","date":"0001-01-01","id":116,"permalink":"/docs/cli-reference/add/sources/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm add sources [\u0026lt;options\u0026gt;] [\u0026lt;target\u0026gt;] {\u0026lt;resourcefile\u0026gt; | \u0026lt;var\u0026gt;=\u0026lt;value\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e --access YAML blob access specification (YAML)\n --accessComponent string component for access specification\n --accessHostname string hostname used for access\n --accessRepository string repository or registry URL\n --accessType string type of blob access specification\n --accessVersion string version for access specification\n --addenv access environment for templating\n --artifactId string maven artifact id\n --body string body of a http request\n --bucket string bucket name\n --classifier string maven classifier\n --commit string git commit id\n --digest string blob digest\n --dry-run evaluate and print source specifications\n --extension string maven extension name\n --extra \u0026lt;name\u0026gt;=\u0026lt;value\u0026gt; source extra identity (default [])\n -F, --file string target file/directory (default \u0026#34;component-archive\u0026#34;)\n --globalAccess YAML access specification for global access\n --groupId string maven group id\n --header \u0026lt;name\u0026gt;:\u0026lt;value\u0026gt;,\u0026lt;value\u0026gt;,... http headers (default {})\n -h, --help help for sources\n --hint string (repository) hint for local artifacts\n --identityPath {\u0026lt;name\u0026gt;=\u0026lt;value\u0026gt;} identity path for specification\n --input YAML blob input specification (YAML)\n --inputComponent string component name\n --inputCompress compress option for input\n --inputData !bytesBase64 data (string, !!string or !\u0026lt;base64\u0026gt;\n --inputExcludes stringArray excludes (path) for inputs\n --inputFollowSymlinks follow symbolic links during archive creation for inputs\n --inputFormattedJson YAML JSON formatted text\n --inputHelmRepository string helm repository base URL\n --inputIncludes stringArray includes (path) for inputs\n --inputJson YAML JSON formatted text\n --inputLibraries stringArray library path for inputs\n --inputPath filepath path field for input\n --inputPlatforms stringArray input filter for image platforms ([os]/[architecture])\n --inputPreserveDir preserve directory in archive for inputs\n --inputRepository string repository or registry for inputs\n --inputText string utf8 text\n --inputType string type of blob input specification\n --inputValues YAML YAML based generic values for inputs\n --inputVariants stringArray (platform) variants for inputs\n --inputVersion string version info for inputs\n --inputYaml YAML YAML formatted text\n --label \u0026lt;name\u0026gt;=\u0026lt;YAML\u0026gt; source label (leading * indicates signature relevant, optional version separated by @)\n --mediaType string media type for artifact blob representation\n --name string source name\n --noredirect http redirect behavior\n -O, --output string output file for dry-run\n --package string package or object name\n -P, --preserve-signature preserve existing signatures\n --reference string reference name\n --region string region name\n -R, --replace replace existing elements\n -s, --settings stringArray settings file with variable settings (yaml)\n --size int blob size\n --source YAML source meta data (yaml)\n --templater string templater to use (go, none, spiff, subst) (default \u0026#34;subst\u0026#34;)\n --type string source type\n --url string artifact or server url\n --verb string http request method\n --version string source version\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eAdd information about the sources, e.g. commits in a Github repository,\nthat have been used to create the resources specified in a resource file to a component version.\nSo far only component archives are supported as target.\u003c/p\u003e","tags":[],"title":"sources"},{"content":"Usage ocm get sources [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}\rOptions -c, --constraints constraints version constraint -h, --help help for sources --latest restrict component versions to latest --lookup stringArray repository name or spec for closure lookup fallback -o, --output string output mode (JSON, json, tree, wide, yaml) -r, --recursive follow component reference nesting --repo string repository name or spec -s, --sort stringArray sort fields\rDescription Get sources of a component version. Sources are specified by identities. An identity consists of a name argument followed by optional \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; arguments.\nIf the option \u0026ndash;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 \u0026ndash;latest only the latest matching versions will be selected.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry With the option \u0026ndash;recursive the complete reference tree of a component reference is traversed.\nIf a component lookup for building a reference closure is required the \u0026ndash;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.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json tree wide yaml See Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":117,"permalink":"/docs/cli-reference/get/sources/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get sources [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;name\u0026gt; { \u0026lt;key\u0026gt;=\u0026lt;value\u0026gt; }}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -c, --constraints constraints version constraint\n -h, --help help for sources\n --latest restrict component versions to latest\n --lookup stringArray repository name or spec for closure lookup fallback\n -o, --output string output mode (JSON, json, tree, wide, yaml)\n -r, --recursive follow component reference nesting\n --repo string repository name or spec\n -s, --sort stringArray sort fields\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eGet sources of a component version. Sources are specified\nby identities. An identity consists of\na name argument followed by optional \u003ccode\u003e\u0026lt;key\u0026gt;=\u0026lt;value\u0026gt;\u003c/code\u003e\narguments.\u003c/p\u003e","tags":[],"title":"sources"},{"content":"Usage ocm show tags [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;version pattern\u0026gt;}\rOptions -h, --help help for tags -l, --latest show only latest tags --repo string repository name or spec -o, --semantic show semantic tags -s, --semver show only semver compliant tags\rDescription Match tags of an artifact against some patterns.\nIf the repository/registry option is specified, the given names are interpreted relative to the specified registry using the syntax\n\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as extended OCI artifact references.\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e]/\u0026lt;OCI repository name\u003e[:\u0026lt;tag\u003e][@\u0026lt;digest\u003e] The \u0026ndash;repo option takes a repository/OCI registry specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz are possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nArtifactSet: v1 CommonTransportFormat: v1 DockerDaemon: v1 Empty: v1 OCIRegistry: v1 oci: v1 ociRegistry Examples $ ocm show tags ghcr.io/open-component-model/ocm/ocm.software/ocmcli/ocmcli-image $ ocm oci show tags ghcr.io/open-component-model/ocm/ocm.software/ocmcli/ocmcli-image\rSee Also ocm show\t— Show tags or versions ","date":"0001-01-01","id":118,"permalink":"/docs/cli-reference/show/tags/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm show tags [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;version pattern\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for tags\n -l, --latest show only latest tags\n --repo string repository name or spec\n -o, --semantic show semantic tags\n -s, --semver show only semver compliant tags\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eMatch tags of an artifact against some patterns.\u003c/p\u003e","tags":[],"title":"tags"},{"content":"","date":"0001-01-01","id":119,"permalink":"/tags/","summary":"","tags":[],"title":"Tags"},{"content":"Description Tiny OCM Installer (TOI) is a small toolset on top of the Open Component Model. It provides a possibility to run images taken from a component version with user configuration and feed them with the content of this component version. It is some basic mechanism, which can be used to execute simple installation steps based on content described by the Open Component Model (see ocm bootstrap package).\nTherefore, a dedicated resource type toiPackage is defined, which describes an installation package to be handled by TOI. When calling the ocm bootstrap package command it is selected by a resource identity pattern. The first resource in given component version matching the pattern is used. A possible use case could be to provide different packages for different environments. The resource can use an identity attribute platform=\u0026lt;value\u0026gt;. By specifying just the platform attribute, the appropriate package will be chosen.\nThe bootstrap command uses this package resource to determine a TOI executor together with executor configuration and additional client specific settings to describe a dedicated installation.\nTo do this the package describes dedicated actions that can be executed by the bootstrap command. Every action (for example install) refers to an executor, which is executed to perform the action.\nAn executor is basically an image following the TOI specification for passing information into the image execution and receiving results from the execution. An executor specification can be described in two ways:\nit either directly describes a resource of type ociImage or it describes a resource of type toiExecutor, which defines the image to use and some default settings. It furthermore describes the features and requirements of the executor image. The package describes configuration values for every configured executor as well as general credentials requirements and required user configuration which must be passed along with the bootstrap command. The executor specification may then optionally map this package global settings into executor specific views.\nAfter validation of the input and its mapping to an executor specific format, finally, a container with the selected executor image is created, that contains the content of the initial component version in form of a Common Transport Archive and all the specified configuration data.\nThe execution of the container may do the needful to achieve the goal of the requested action and provide some labeled output files, which will be passed to the caller.\nThe toiPackage Resource This resource describes an installable software package, whose content is contained in the component version, which contains the package resource.\nIt is a plain yaml resource with the media types media type application/x-yaml, text/yaml or\napplication/vnd.toi.ocm.software.package.v1+yaml) containing information required to control the instantiation of an executor.\nIt has the following format:\ndescription (optional) string\nA short description of the installation package and some configuration hints.\nexecutors []ExecutorSpecification\nconfigTemplate (optional) yaml\nThis is a spiff template used to generate The user config that is finally passed to the executor. If no template is specified the user parameter input will be processed directly without template.\nconfigScheme (optional) yaml\nThis is a JSONSCHEMA used to validate the user input prior to merging with the template\ntemplateLibraries (optional) []ResourceReference\nThis is a list of resources whose content is used as additional stubs for the template processing.\ncredentials (optional) map[string]CredentialRequest\nHere the package may request the provisioning of some credentials with a dedicated name/purpose and structure. If specified the bootstrap command requites the specification of a credentials file providing the information how to satisfy those credential requests.\nadditionalResources (optional) map[string]AdditionalResource)\nA set of additional resources specified by an OCM resource reference or direct data as byte, string or yaml. The key describes the meaning of the resource. The following keys have a special meaning:\nconfigFile: an example template for a parameter file credentialsFile: an example template for a credentials file Those templates can be downloaded with ocm bootstrap configuration.\nExecutorSpecification The executor specification describes the available actions and their mapping to executors. It uses the following fields:\nactions []string\nThe list of actions this executor can be used for. If nothings is specified the executor will be used for all actions. The first matching executor entry will be used to execute an action by the bootstrap command\nresourceRef []ResourceReference\nAn OCM resource reference describing a component version resource relative to the component version containing the package resource.\nconfig (optional) yaml\nThis is optional static executor config passed to the executor as is. It is to describe the set of elements on which the actual execution of the executor should work on.\nparameterMapping (optional) spiff yaml\nThis is an optional spiff template used to process the actual package parameter set passed by the caller to transform it to the requirements of the actual executor.\nA package has a global parameter setting, but possibly multiple different executors for different actions. They might have different requirements/formats concerning the parameter input. Therefore, the executor specification allows to map the provided user input, accordingly.\ncredentialMapping (optional) map[string]string\nThis is an optional mapping to map credential names used by the package to the needs of dedicated executors.\nA package has global parameter setting, but possibly multiple different executors for different action. They might have different requirements/formats concerning the parameter input. There the executor specification allows to map the provided user input, accordingly\nimage (development) object\nInstead of a resourceRef it is possible to directly specify an absolute image.\nATTENTION: this is intended for development purposes, ONLY. Do not use it for final component versions.\nIt has the field ref and the optional field digest.\noutputs (optional) map[string]string\nThis field can be used to map the names of outputs provided by a dedicated executor outputs to package outputs.\nResourceReference An OCM resource reference describes a resource of a component version. It is always evaluated relative to the component version providing the resource that contains the resource reference. It uses the following fields:\nresourcePath (optional) []Identity\nThis is sequence of reference identities used to follow a chain of component version references starting with the actual component version. If not specified the specified resource will be taken from the actual component version.\nresource Identity\nThis is the identity of the resource in the selected component version.\nAdditionalResource This field has either the fields of a ResourceReference to refer to the content of an OCM resource or the field:\ncontent string|[]byte|YAML\nEither a resource reference or the field content must be given. The content field may contain a string or an inline YAML document. For larger content the resource reference form should be preferred.\nIdentity An identity specification is a map[string]string. It describes the identity attributes of a desired resource in a component version. It always has at least one identity attribute name, which is the resource name field of the desired resource. If this resource defines additional identity attributes, the complete set must be specified.\nInput Mapping for Executors An optional parameterMapping in the executor section can be used to process the global package user-specified parameters to provide specific values expected by the executor.\nThis is done by a spiff template. Here special functions are provided to access specific content:\nhasCredentials(string[,string]) bool\nThis function can be used to check whether dedicated credentials are effectively provided for the actual installation.\nThe name is the name of the credentials as described in the credentials request section optionally mapped to the name used for the executor (field credentialMapping).\nIf the second argument is given, it checks for the named property in the credential set.\ngetCredentials(string[,string]) map[string]string | string\nThis functions provides the property set of the provided credentials.\nIf the second argument is given, it returns the named property in the selected credential set.\nIf the property name is an asterisks (*) a single property is expected, whose value is returned.\nUser Config vs Executor Config An executor is typically able to handle a complete class of installations. It describes a dedicated installation mechanism, but not a dedicated installation source. Although, there might be specialized images for dedicated installation sources, in general the idea is to provide more general executors, for example an helm executor, which is able to handle any helm chart, not just a dedicated helm deployment.\nBecause of this, there is a clear separation between an installation specific configuration, which is provided by the user calling the TOI commands, and the parameterization of the executor, which is completely specified in the package.\nThe task of the package is to represent a dedicated deployment source. As such it has to provide information to tell the executor what to install, while the user configuration is used to describe the instance specific settings.\nBack to the example of a helm installer executor, the executor config contained in the package resource describes the helm chart, which should be installed and the way how the user input is mapped to chart values. Here, also the localizations are described in an executor specific way.\nTherefore, an executor expects a dedicated configuration format, which can be specified in the executor resource in form of a JSON scheme.\nThe package then may provide a package specific scheme for the instance configuration. This value-set is dependent on the installation source (the helm chart in this example).\nFor further details you have to refer to the dedicated executor and package definitions.\nThe toiExecutor Resource Instead of directly describing an image resource in the package file, it is possible to refer to a resource of type toiExecutor. This is a yaml file with the media type application/x-yaml, text/yaml or application/vnd.toi.ocm.software.package.v1+yaml) containing common information about the executor. If this flavor is used by the package, this information is used to validate settings in the package specification.\nIt has the following format:\nimageRef ResourceReference\nThis field reference the image resource relative to the component version providing the executor resource\nconfigTemplate (optional) yaml\nThis a spiff template used to generate The executor config from the package specification that is finally passed to the executor. If no template is specified the executor config specified in the package will be processed directly without template.\nconfigScheme (optional) yaml\nThis is a JSONSCHEMA used to validate the executor config from the package prior to merging with the template\ntemplateLibraries (optional) []ResourceReference\nThis is a list of resources whose content is used as additional stubs for the template processing.\ncredentials (optional) map[string]CredentialRequest\nHere the executor may request the provisioning of some credentials with a dedicated name/purpose and structure. If specified it will be propagated to a using package. It this uses an own credentials section, this one will be filtered and checked for the actual executor.\noutputs (optional) map[string]OutputSpecification\nThis field can be used to describe the provided outputs of this executor. The OutputSpecification contains only the field description, so far. It is intended to be extended to contain further information to more formally describe the type of output.\nimage (development) object\nInstead of an imageRef it is possible to directly specify an absolute image.\nATTENTION: this is intended for development purposes, ONLY. Do not use it for final component versions.\nIt has the field ref and the optional field digest.\nClient Parameters Common to all executors a parameter file can be provided by the caller. The package specification may provide a spiff template for this parameter file. It can be used, for example to provide useful defaults. The actually provided content is merged with this template.\nTo validate user configuration a JSON scheme can be provided. The user input is validated first against this scheme before the actual merge is done.\nCredentials Additionally credentials can be requested to be provided by a client. This is done with the credentials field. It is a map of credentials names and their meaning and/or handling.\nIt uses the following fields:\ndescription string\nThis field should describe the purpose of the credential.\nproperties map[string]string\nThis field should describe the used credential fields\nconsumerId map[string]\nThis field can be used to optionally define a consumer id that should be set in the OCM support library, if used by the executor. At least the field type and one additional field must be set.\nCredentials are provided in an ocm config file (see ocm configfile). It uses a memory credential repository with the name default to store the credentials under the given name. Additionally appropriate consumer ids will be propagated, if requested in the credentials request config.\nExecutor Image Contract The executor image is called with the action as additional argument. It is expected that is defines a default entry point and a potentially empty list of standard arguments.\nIt is called with two arguments:\nname of the action to execute\nidentity of the component version containing the package the executor is executed for.\nThis can be used to access the component descriptor to get access to further described resources in the executor config\nThe container used to execute the executor image gets prepared a standard filesystem structure used to provide all the executor inputs before the execution and reading provided executor outputs after the execution.\n/ └── toi ├── inputs │ ├── config configuration from package specification │ ├── ocmrepo OCM filesystem repository containing the complete │ │ component version of the package │ └── parameters merged complete parameter file ├── outputs │ ├── \u0026lt;out\u003e any number of arbitrary output data provided │ │ by executor │ └── ... └── run good practice: typical location for the executed command After processing it is possible to return named outputs. The name of an output must be a filename. The executor section in the package specification maps those files to logical outputs in the outputs section.\n\u0026lt;file name by executor\u003e -\u003e \u0026lt;logical output name\u003e Basically the output may contain any data, but is strongly recommended to use yaml or json files, only. This enables further formal processing by the TOI toolset.\nExamples description: | This package is just an example. executors: - actions: - install resourceRef: resource: name: installerimage config: level: info # parameterMapping: # optional spiff mapping of Package configuration to # .... # executor parameters outputs: test: bla credentials: target: description: kubeconfig for target kubernetes cluster consumerId: type: Kubernetes purpose: target configTemplate: parameters: username: admin password: (( \u0026amp;merge )) configScheme: type: object required: - parameters additionalProperties: false properties: parameters: type: object required: - password additionalProperties: false properties: username: type: string password: type: string additionalResources: configFile: resource: name: config-file\rSee Also ","date":"0001-01-01","id":120,"permalink":"/docs/cli-reference/help/toi-bootstrapping/","summary":"\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eTiny OCM Installer (TOI) is a small toolset on top of the Open Component Model.\nIt provides a possibility to run images taken from a component version with user\nconfiguration and feed them with the content of this component version.\nIt is some basic mechanism, which can be used to execute simple installation\nsteps based on content described by the Open Component Model\n(see \u003ca href=\"https://github.com/open-component-model/ocm/blob/main/docs/reference/ocm_bootstrap_package.md\"\u003eocm bootstrap package\u003c/a\u003e).\u003c/p\u003e","tags":[],"title":"toi-bootstrapping"},{"content":"Usage ocm transfer [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for transfer\rSee Also Sub Commands ocm transfer artifacts\t— transfer OCI artifacts ocm transfer commontransportarchive\t— transfer transport archive ocm transfer componentarchive\t— transfer component archive to some component repository ocm transfer componentversions\t— transfer component version ","date":"0001-01-01","id":121,"permalink":"/docs/cli-reference/transfer/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm transfer [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for transfer\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/transfer/artifacts/\"\u003eocm transfer \u003cb\u003eartifacts\u003c/b\u003e\u003c/a\u003e\t — transfer OCI artifacts\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/transfer/commontransportarchive/\"\u003eocm transfer \u003cb\u003ecommontransportarchive\u003c/b\u003e\u003c/a\u003e\t — transfer transport archive\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/transfer/componentarchive/\"\u003eocm transfer \u003cb\u003ecomponentarchive\u003c/b\u003e\u003c/a\u003e\t — transfer component archive to some component repository\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/transfer/componentversions/\"\u003eocm transfer \u003cb\u003ecomponentversions\u003c/b\u003e\u003c/a\u003e\t — transfer component version\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"transfer"},{"content":"Usage ocm create transportarchive [\u0026lt;options\u0026gt;] \u0026lt;path\u0026gt;\rOptions -f, --force remove existing content -h, --help help for transportarchive -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\rDescription Create a new empty OCM/OCI transport archive. This might be either a directory prepared to host artifact content or a tar/tgz file.\nSee Also ocm create\t— Create transport or component archive ","date":"0001-01-01","id":122,"permalink":"/docs/cli-reference/create/transportarchive/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm create transportarchive [\u0026lt;options\u0026gt;] \u0026lt;path\u0026gt;\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -f, --force remove existing content\n -h, --help help for transportarchive\n -t, --type string archive format (directory, tar, tgz) (default \u0026#34;directory\u0026#34;)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eCreate a new empty OCM/OCI transport archive. This might be either a directory prepared\nto host artifact content or a tar/tgz file.\u003c/p\u003e","tags":[],"title":"transportarchive"},{"content":"Usage ocm get verified [\u0026lt;options\u0026gt;] {\u0026lt;component / version}\rOptions -h, --help help for verified -o, --output string output mode (JSON, json, wide, yaml) -s, --sort stringArray sort fields --verified string verified file (default \u0026#34;~/.ocm/verified\u0026#34;)\rDescription Get lists remembered verified component versions.\nWith the option \u0026ndash;output the output mode can be selected. The following modes are supported:\n(default) JSON json wide yaml Examples $ ocm get verified $ ocm get verified -f verified.yaml acme.org/component -o yaml\rSee Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":123,"permalink":"/docs/cli-reference/get/verified/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm get verified [\u0026lt;options\u0026gt;] {\u0026lt;component / version}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for verified\n -o, --output string output mode (JSON, json, wide, yaml)\n -s, --sort stringArray sort fields\n --verified string verified file (default \u0026#34;~/.ocm/verified\u0026#34;)\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eGet lists remembered verified component versions.\u003c/p\u003e","tags":[],"title":"verified"},{"content":"Usage ocm verify [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\rOptions -h, --help help for verify\rSee Also Sub Commands ocm verify componentversions\t— Verify signature of component version ","date":"0001-01-01","id":124,"permalink":"/docs/cli-reference/verify/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm verify [\u0026lt;options\u0026gt;] \u0026lt;sub command\u0026gt; ...\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for verify\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"see-also\"\u003eSee Also\u003c/h3\u003e\n\u003ch5 id=\"sub-commands\"\u003eSub Commands\u003c/h5\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/docs/cli-reference/verify/componentversions/\"\u003eocm verify \u003cb\u003ecomponentversions\u003c/b\u003e\u003c/a\u003e\t — Verify signature of component version\u003c/li\u003e\n\u003c/ul\u003e","tags":[],"title":"verify"},{"content":"Usage ocm show versions [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;version pattern\u0026gt;}\rOptions -h, --help help for versions -l, --latest show only latest version --repo string repository name or spec -s, --semantic show semantic version\rDescription Match versions of a component against some patterns.\nIf the \u0026ndash;repo option is specified, the given names are interpreted relative to the specified repository using the syntax\n\u0026lt;component\u003e[:\u0026lt;version\u003e] If no \u0026ndash;repo option is specified the given names are interpreted as located OCM component version references:\n[\u0026lt;repo type\u003e::]\u0026lt;host\u003e[:\u0026lt;port\u003e][/\u0026lt;base path\u003e]//\u0026lt;component\u003e[:\u0026lt;version\u003e] Additionally there is a variant to denote common transport archives and general repository specifications\n[\u0026lt;repo type\u003e::]\u0026lt;filepath\u003e|\u0026lt;spec json\u003e[//\u0026lt;component\u003e[:\u0026lt;version\u003e]] The \u0026ndash;repo option takes an OCM repository specification:\n[\u0026lt;repo type\u003e::]\u0026lt;configured name\u003e|\u0026lt;file path\u003e|\u0026lt;spec json\u003e For the Common Transport Format the types directory, tar or tgz is possible.\nUsing the JSON variant any repository types supported by the linked library can be used:\nDedicated OCM repository types:\nComponentArchive: v1 OCI Repository types (using standard component repository to OCI mapping):\nCommonTransportFormat: v1 OCIRegistry: v1 oci: v1 ociRegistry Examples $ ocm show versions ghcr.io/mandelsoft/cnudie//github.com/mandelsoft/playground\rSee Also ocm show\t— Show tags or versions ","date":"0001-01-01","id":125,"permalink":"/docs/cli-reference/show/versions/","summary":"\u003ch3 id=\"usage\"\u003eUsage\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003eocm show versions [\u0026lt;options\u0026gt;] \u0026lt;component\u0026gt; {\u0026lt;version pattern\u0026gt;}\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"options\"\u003eOptions\u003c/h3\u003e\n\r\n\r\n\r\n\u003cdiv class=\"expressive-code\"\u003e\r\n \u003cfigure class=\"frame not-content\"\u003e\r\n \u003cfigcaption class=\"header\"\u003e\r\n \u003cspan class=\"title\"\u003e\u003c/span\u003e\r\n \u003c/figcaption\u003e\r\n \u003cpre tabindex=\"0\"\u003e\u003ccode\u003e -h, --help help for versions\n -l, --latest show only latest version\n --repo string repository name or spec\n -s, --semantic show semantic version\u003c/code\u003e\u003c/pre\u003e\r\n \u003c/figure\u003e\r\n\u003c/div\u003e\r\n\u003ch3 id=\"description\"\u003eDescription\u003c/h3\u003e\n\u003cp\u003eMatch versions of a component against some patterns.\u003c/p\u003e","tags":[],"title":"versions"}] \ No newline at end of file diff --git a/sitemap.xml b/sitemap.xml index a5febb6c..a7356e39 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/component-descriptors/version-2/2023-01-17T10:22:20+00:00monthly0.5https://ocm.software/docs/component-descriptors/version-3/2023-01-17T10:22:23+00:00monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/2024-07-10T08:48:23+00:00monthly0.5https://ocm.software/docs/overview/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/overview/about/monthly0.5https://ocm.software/docs/overview/benefits-of-ocm/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/overview/important-terms/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/overview/specification/monthly0.5https://ocm.software/docs/getting-started/2023-11-07T11:45:27+00:00monthly0.5https://ocm.software/docs/getting-started/installing-the-ocm-cli/monthly0.5https://ocm.software/docs/getting-started/getting-started-with-ocm/2023-03-13T09:38:41+01:00monthly0.5https://ocm.software/docs/getting-started/getting-started-with-ocm/prerequisites/2023-03-13T09:38:41+01:00monthly0.5https://ocm.software/docs/getting-started/getting-started-with-ocm/create-a-component-version/2023-03-13T09:38:41+01:00monthly0.5https://ocm.software/docs/getting-started/getting-started-with-ocm/display-and-examine-component-versions/2023-03-13T09:38:41+01:00monthly0.5https://ocm.software/docs/getting-started/getting-started-with-ocm/transport-ocm-component-versions/2023-03-13T09:38:41+01:00monthly0.5https://ocm.software/docs/getting-started/getting-started-with-ocm/sign-component-versions/2023-03-13T09:38:41+01:00monthly0.5https://ocm.software/docs/controller/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/controller/architecture/2023-10-20T11:24:41+01:00monthly0.5https://ocm.software/docs/controller/installation/2023-06-27T16:16:48+01:00monthly0.5https://ocm.software/docs/component-descriptors/2023-01-17T10:22:05+00:00monthly0.5https://ocm.software/docs/controller/controller-reference/2022-01-25T14:40:56+01:00monthly0.5https://ocm.software/docs/controller/controller-reference/api-reference/2022-01-25T14:40:56+01:00monthly0.5https://ocm.software/docs/controller/controller-reference/api-reference/ocm-controller-api-v1/2024-03-12T11:20:59+01:00monthly0.5https://ocm.software/docs/controller/controller-reference/api-reference/replication-controller-api-v1/2023-07-10T11:34:56+01:00monthly0.5https://ocm.software/docs/controller/controller-reference/ocm-controller/2022-01-25T14:40:56+01:00monthly0.5https://ocm.software/docs/controller/controller-reference/ocm-controller/component-version/2023-06-28T09:30:27+01:00monthly0.5https://ocm.software/docs/controller/controller-reference/replication-controller/2022-01-25T14:40:56+01:00monthly0.5https://ocm.software/docs/controller/controller-reference/replication-controller/component-subscription/2023-07-11T16:07:00+01:00monthly0.5https://ocm.software/docs/tutorials/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/air-gapped-gitops-with-ocm-flux/monthly0.5https://ocm.software/docs/tutorials/best-practices/2023-03-13T12:00:26+01:00monthly0.5https://ocm.software/docs/tutorials/build-deploy-infrastructure-via-helm-charts-with-ocm/2024-03-19T10:36:48+01:00monthly0.5https://ocm.software/docs/tutorials/structuring-and-deploying-software-products-with-ocm/monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/deploying-applications-with-ocm-gitops/monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/gitops-driven-configuration-of-ocm-applications/monthly0.5https://ocm.software/docs/tutorials/input-and-access-types/monthly0.5https://ocm.software/docs/examples/2023-11-07T11:45:27+00:00monthly0.5https://ocm.software/docs/examples/secure-software-delivery-with-flux-and-ocm/2023-11-07T11:45:27+00:00monthly0.5https://ocm.software/docs/roadmap/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/roadmap/our-roadmap/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/support/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/support/how-to-get-support/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/support/community/2022-08-12T10:38:22+01:00monthly0.5https://ocm.software/docs/contribution/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/contribution/contributing-guideline/monthly0.5https://ocm.software/docs/contribution/security-guideline/2022-08-12T10:38:22+01:00monthly0.5https://ocm.software/mpas/getting_started/2023-09-12T10:37:58+01:00monthly0.5https://ocm.software/mpas/installation/2023-09-12T10:37:58+01:00monthly0.5https://ocm.software/mpas/core_concepts/2023-09-12T10:37:58+01:00monthly0.5https://ocm.software/mpas/bootstrap/2023-09-12T10:37:58+01:00monthly0.5https://ocm.software/mpas/demo_of_mpas/2024-04-02T12:45:27+00:00monthly0.5https://ocm.software/docs/examples/credentials-in-an-.ocmconfig-file/2024-09-04T13:54:01+02:00monthly0.5https://ocm.software/docs/2024-09-04T13:54:01+02:00monthly0.5https://ocm.software/mpas/2024-04-02T12:45:27+00:00monthly0.5https://ocm.software/2020-10-06T08:47:36+00:00monthly0.5https://ocm.software/docs/cli-reference/add/monthly0.5https://ocm.software/docs/cli-reference/describe/artifacts/monthly0.5https://ocm.software/docs/cli-reference/download/artifacts/monthly0.5https://ocm.software/docs/cli-reference/get/artifacts/monthly0.5https://ocm.software/docs/cli-reference/transfer/artifacts/monthly0.5https://ocm.software/docs/cli-reference/help/attributes/monthly0.5https://ocm.software/docs/cli-reference/clean/cache/monthly0.5https://ocm.software/docs/cli-reference/describe/cache/monthly0.5https://ocm.software/categories/monthly0.5https://ocm.software/docs/cli-reference/check/monthly0.5https://ocm.software/docs/cli-reference/clean/monthly0.5https://ocm.software/docs/cli-reference/download/cli/monthly0.5https://ocm.software/docs/cli-reference/monthly0.5https://ocm.software/docs/cli-reference/transfer/commontransportarchive/monthly0.5https://ocm.software/docs/cli-reference/create/componentarchive/monthly0.5https://ocm.software/docs/cli-reference/transfer/componentarchive/monthly0.5https://ocm.software/docs/cli-reference/add/componentversions/monthly0.5https://ocm.software/docs/cli-reference/check/componentversions/monthly0.5https://ocm.software/docs/cli-reference/download/componentversions/monthly0.5https://ocm.software/docs/cli-reference/get/componentversions/monthly0.5https://ocm.software/docs/cli-reference/list/componentversions/monthly0.5https://ocm.software/docs/cli-reference/sign/componentversions/monthly0.5https://ocm.software/docs/cli-reference/transfer/componentversions/monthly0.5https://ocm.software/docs/cli-reference/verify/componentversions/monthly0.5https://ocm.software/docs/cli-reference/get/config/monthly0.5https://ocm.software/docs/cli-reference/help/configfile/monthly0.5https://ocm.software/contributors/monthly0.5https://ocm.software/docs/cli-reference/create/monthly0.5https://ocm.software/docs/cli-reference/help/credential-handling/monthly0.5https://ocm.software/docs/cli-reference/get/credentials/monthly0.5https://ocm.software/docs/cli-reference/describe/monthly0.5https://ocm.software/docs/cli-reference/download/monthly0.5https://ocm.software/docs/cli-reference/get/monthly0.5https://ocm.software/docs/cli-reference/sign/hash/monthly0.5https://ocm.software/docs/cli-reference/help/monthly0.5https://ocm.software/docs/cli-reference/list/monthly0.5https://ocm.software/docs/cli-reference/help/logging/monthly0.5https://ocm.software/docs/cli-reference/help/oci-references/monthly0.5https://ocm.software/docs/cli-reference/help/ocm-accessmethods/monthly0.5https://ocm.software/docs/cli-reference/help/ocm-downloadhandlers/monthly0.5https://ocm.software/docs/cli-reference/help/ocm-labels/monthly0.5https://ocm.software/docs/cli-reference/help/ocm-pubsub/monthly0.5https://ocm.software/docs/cli-reference/help/ocm-references/monthly0.5https://ocm.software/docs/cli-reference/help/ocm-uploadhandlers/monthly0.5https://ocm.software/docs/cli-reference/describe/package/monthly0.5https://ocm.software/docs/cli-reference/describe/plugins/monthly0.5https://ocm.software/docs/cli-reference/get/plugins/monthly0.5https://ocm.software/docs/cli-reference/get/pubsub/monthly0.5https://ocm.software/docs/cli-reference/set/pubsub/monthly0.5https://ocm.software/docs/cli-reference/add/references/monthly0.5https://ocm.software/docs/cli-reference/get/references/monthly0.5https://ocm.software/docs/cli-reference/add/resource-configuration/monthly0.5https://ocm.software/docs/cli-reference/add/resources/monthly0.5https://ocm.software/docs/cli-reference/download/resources/monthly0.5https://ocm.software/docs/cli-reference/get/resources/monthly0.5https://ocm.software/docs/cli-reference/add/routingslips/monthly0.5https://ocm.software/docs/cli-reference/get/routingslips/monthly0.5https://ocm.software/docs/cli-reference/create/rsakeypair/monthly0.5https://ocm.software/docs/cli-reference/set/monthly0.5https://ocm.software/docs/cli-reference/show/monthly0.5https://ocm.software/docs/cli-reference/sign/monthly0.5https://ocm.software/docs/cli-reference/add/source-configuration/monthly0.5https://ocm.software/docs/cli-reference/add/sources/monthly0.5https://ocm.software/docs/cli-reference/get/sources/monthly0.5https://ocm.software/docs/cli-reference/show/tags/monthly0.5https://ocm.software/tags/monthly0.5https://ocm.software/docs/cli-reference/help/toi-bootstrapping/monthly0.5https://ocm.software/docs/cli-reference/transfer/monthly0.5https://ocm.software/docs/cli-reference/create/transportarchive/monthly0.5https://ocm.software/docs/cli-reference/get/verified/monthly0.5https://ocm.software/docs/cli-reference/verify/monthly0.5https://ocm.software/docs/cli-reference/show/versions/monthly0.5 \ No newline at end of file +https://ocm.software/docs/component-descriptors/version-2/2023-01-17T10:22:20+00:00monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/2024-07-10T08:48:23+00:00monthly0.5https://ocm.software/docs/overview/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/overview/about/monthly0.5https://ocm.software/docs/overview/benefits-of-ocm/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/overview/important-terms/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/overview/specification/monthly0.5https://ocm.software/docs/getting-started/2023-11-07T11:45:27+00:00monthly0.5https://ocm.software/docs/getting-started/installing-the-ocm-cli/monthly0.5https://ocm.software/docs/getting-started/getting-started-with-ocm/2023-03-13T09:38:41+01:00monthly0.5https://ocm.software/docs/getting-started/getting-started-with-ocm/prerequisites/2023-03-13T09:38:41+01:00monthly0.5https://ocm.software/docs/getting-started/getting-started-with-ocm/create-a-component-version/2023-03-13T09:38:41+01:00monthly0.5https://ocm.software/docs/getting-started/getting-started-with-ocm/display-and-examine-component-versions/2023-03-13T09:38:41+01:00monthly0.5https://ocm.software/docs/getting-started/getting-started-with-ocm/transport-ocm-component-versions/2023-03-13T09:38:41+01:00monthly0.5https://ocm.software/docs/getting-started/getting-started-with-ocm/sign-component-versions/2023-03-13T09:38:41+01:00monthly0.5https://ocm.software/docs/controller/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/controller/architecture/2023-10-20T11:24:41+01:00monthly0.5https://ocm.software/docs/controller/installation/2023-06-27T16:16:48+01:00monthly0.5https://ocm.software/docs/component-descriptors/2023-01-17T10:22:05+00:00monthly0.5https://ocm.software/docs/controller/controller-reference/2022-01-25T14:40:56+01:00monthly0.5https://ocm.software/docs/controller/controller-reference/api-reference/2022-01-25T14:40:56+01:00monthly0.5https://ocm.software/docs/controller/controller-reference/api-reference/ocm-controller-api-v1/2024-03-12T11:20:59+01:00monthly0.5https://ocm.software/docs/controller/controller-reference/api-reference/replication-controller-api-v1/2023-07-10T11:34:56+01:00monthly0.5https://ocm.software/docs/controller/controller-reference/ocm-controller/2022-01-25T14:40:56+01:00monthly0.5https://ocm.software/docs/controller/controller-reference/ocm-controller/component-version/2023-06-28T09:30:27+01:00monthly0.5https://ocm.software/docs/controller/controller-reference/replication-controller/2022-01-25T14:40:56+01:00monthly0.5https://ocm.software/docs/controller/controller-reference/replication-controller/component-subscription/2023-07-11T16:07:00+01:00monthly0.5https://ocm.software/docs/tutorials/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/air-gapped-gitops-with-ocm-flux/monthly0.5https://ocm.software/docs/tutorials/best-practices/2023-03-13T12:00:26+01:00monthly0.5https://ocm.software/docs/tutorials/build-deploy-infrastructure-via-helm-charts-with-ocm/2024-03-19T10:36:48+01:00monthly0.5https://ocm.software/docs/tutorials/structuring-and-deploying-software-products-with-ocm/monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/deploying-applications-with-ocm-gitops/monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/gitops-driven-configuration-of-ocm-applications/monthly0.5https://ocm.software/docs/tutorials/input-and-access-types/monthly0.5https://ocm.software/docs/examples/2023-11-07T11:45:27+00:00monthly0.5https://ocm.software/docs/examples/secure-software-delivery-with-flux-and-ocm/2023-11-07T11:45:27+00:00monthly0.5https://ocm.software/docs/roadmap/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/roadmap/our-roadmap/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/support/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/support/how-to-get-support/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/support/community/2022-08-12T10:38:22+01:00monthly0.5https://ocm.software/docs/contribution/2020-10-06T08:48:23+00:00monthly0.5https://ocm.software/docs/contribution/contributing-guideline/monthly0.5https://ocm.software/docs/contribution/security-guideline/2022-08-12T10:38:22+01:00monthly0.5https://ocm.software/mpas/getting_started/2023-09-12T10:37:58+01:00monthly0.5https://ocm.software/mpas/installation/2023-09-12T10:37:58+01:00monthly0.5https://ocm.software/mpas/core_concepts/2023-09-12T10:37:58+01:00monthly0.5https://ocm.software/mpas/bootstrap/2023-09-12T10:37:58+01:00monthly0.5https://ocm.software/mpas/demo_of_mpas/2024-04-02T12:45:27+00:00monthly0.5https://ocm.software/docs/examples/credentials-in-an-.ocmconfig-file/2024-09-04T13:54:01+02:00monthly0.5https://ocm.software/docs/2024-09-04T13:54:01+02:00monthly0.5https://ocm.software/mpas/2024-04-02T12:45:27+00:00monthly0.5https://ocm.software/2020-10-06T08:47:36+00:00monthly0.5https://ocm.software/docs/cli-reference/add/monthly0.5https://ocm.software/docs/cli-reference/describe/artifacts/monthly0.5https://ocm.software/docs/cli-reference/download/artifacts/monthly0.5https://ocm.software/docs/cli-reference/get/artifacts/monthly0.5https://ocm.software/docs/cli-reference/transfer/artifacts/monthly0.5https://ocm.software/docs/cli-reference/help/attributes/monthly0.5https://ocm.software/docs/cli-reference/clean/cache/monthly0.5https://ocm.software/docs/cli-reference/describe/cache/monthly0.5https://ocm.software/categories/monthly0.5https://ocm.software/docs/cli-reference/check/monthly0.5https://ocm.software/docs/cli-reference/clean/monthly0.5https://ocm.software/docs/cli-reference/download/cli/monthly0.5https://ocm.software/docs/cli-reference/monthly0.5https://ocm.software/docs/cli-reference/transfer/commontransportarchive/monthly0.5https://ocm.software/docs/cli-reference/create/componentarchive/monthly0.5https://ocm.software/docs/cli-reference/transfer/componentarchive/monthly0.5https://ocm.software/docs/cli-reference/add/componentversions/monthly0.5https://ocm.software/docs/cli-reference/check/componentversions/monthly0.5https://ocm.software/docs/cli-reference/download/componentversions/monthly0.5https://ocm.software/docs/cli-reference/get/componentversions/monthly0.5https://ocm.software/docs/cli-reference/list/componentversions/monthly0.5https://ocm.software/docs/cli-reference/sign/componentversions/monthly0.5https://ocm.software/docs/cli-reference/transfer/componentversions/monthly0.5https://ocm.software/docs/cli-reference/verify/componentversions/monthly0.5https://ocm.software/docs/cli-reference/get/config/monthly0.5https://ocm.software/docs/cli-reference/help/configfile/monthly0.5https://ocm.software/contributors/monthly0.5https://ocm.software/docs/cli-reference/create/monthly0.5https://ocm.software/docs/cli-reference/help/credential-handling/monthly0.5https://ocm.software/docs/cli-reference/get/credentials/monthly0.5https://ocm.software/docs/cli-reference/describe/monthly0.5https://ocm.software/docs/cli-reference/download/monthly0.5https://ocm.software/docs/cli-reference/get/monthly0.5https://ocm.software/docs/cli-reference/sign/hash/monthly0.5https://ocm.software/docs/cli-reference/help/monthly0.5https://ocm.software/docs/cli-reference/list/monthly0.5https://ocm.software/docs/cli-reference/help/logging/monthly0.5https://ocm.software/docs/cli-reference/help/oci-references/monthly0.5https://ocm.software/docs/cli-reference/help/ocm-accessmethods/monthly0.5https://ocm.software/docs/cli-reference/help/ocm-downloadhandlers/monthly0.5https://ocm.software/docs/cli-reference/help/ocm-labels/monthly0.5https://ocm.software/docs/cli-reference/help/ocm-pubsub/monthly0.5https://ocm.software/docs/cli-reference/help/ocm-references/monthly0.5https://ocm.software/docs/cli-reference/help/ocm-uploadhandlers/monthly0.5https://ocm.software/docs/cli-reference/describe/package/monthly0.5https://ocm.software/docs/cli-reference/describe/plugins/monthly0.5https://ocm.software/docs/cli-reference/get/plugins/monthly0.5https://ocm.software/docs/cli-reference/get/pubsub/monthly0.5https://ocm.software/docs/cli-reference/set/pubsub/monthly0.5https://ocm.software/docs/cli-reference/add/references/monthly0.5https://ocm.software/docs/cli-reference/get/references/monthly0.5https://ocm.software/docs/cli-reference/add/resource-configuration/monthly0.5https://ocm.software/docs/cli-reference/add/resources/monthly0.5https://ocm.software/docs/cli-reference/download/resources/monthly0.5https://ocm.software/docs/cli-reference/get/resources/monthly0.5https://ocm.software/docs/cli-reference/add/routingslips/monthly0.5https://ocm.software/docs/cli-reference/get/routingslips/monthly0.5https://ocm.software/docs/cli-reference/create/rsakeypair/monthly0.5https://ocm.software/docs/cli-reference/set/monthly0.5https://ocm.software/docs/cli-reference/show/monthly0.5https://ocm.software/docs/cli-reference/sign/monthly0.5https://ocm.software/docs/cli-reference/add/source-configuration/monthly0.5https://ocm.software/docs/cli-reference/add/sources/monthly0.5https://ocm.software/docs/cli-reference/get/sources/monthly0.5https://ocm.software/docs/cli-reference/show/tags/monthly0.5https://ocm.software/tags/monthly0.5https://ocm.software/docs/cli-reference/help/toi-bootstrapping/monthly0.5https://ocm.software/docs/cli-reference/transfer/monthly0.5https://ocm.software/docs/cli-reference/create/transportarchive/monthly0.5https://ocm.software/docs/cli-reference/get/verified/monthly0.5https://ocm.software/docs/cli-reference/verify/monthly0.5https://ocm.software/docs/cli-reference/show/versions/monthly0.5 \ No newline at end of file