From 8b327ad592dbf944b7e708c550991fce322cf39d Mon Sep 17 00:00:00 2001 From: morri-son Date: Mon, 16 Sep 2024 07:44:15 +0000 Subject: [PATCH] deploy: 19218cb76339f0c10fdb495baa6d85a2d04092d9 --- .../add/componentversions/index.html | 14 +- docs/cli-reference/add/index.html | 4 +- docs/cli-reference/add/index.xml | 2 +- docs/cli-reference/add/references/index.html | 8 +- .../add/resource-configuration/index.html | 12 +- docs/cli-reference/add/resources/index.html | 10 +- .../cli-reference/add/routingslips/index.html | 8 +- docs/cli-reference/add/sitemap.xml | 2 +- .../add/source-configuration/index.html | 12 +- docs/cli-reference/add/sources/index.html | 10 +- .../check/componentversions/index.html | 8 +- docs/cli-reference/check/index.html | 4 +- docs/cli-reference/check/index.xml | 2 +- docs/cli-reference/check/sitemap.xml | 2 +- docs/cli-reference/clean/cache/index.html | 8 +- docs/cli-reference/clean/index.html | 4 +- docs/cli-reference/clean/index.xml | 2 +- docs/cli-reference/clean/sitemap.xml | 2 +- .../create/componentarchive/index.html | 8 +- docs/cli-reference/create/index.html | 4 +- docs/cli-reference/create/index.xml | 2 +- .../create/rsakeypair/index.html | 8 +- docs/cli-reference/create/sitemap.xml | 2 +- .../create/transportarchive/index.html | 8 +- .../describe/artifacts/index.html | 8 +- docs/cli-reference/describe/cache/index.html | 8 +- docs/cli-reference/describe/index.html | 4 +- docs/cli-reference/describe/index.xml | 2 +- .../cli-reference/describe/package/index.html | 10 +- .../cli-reference/describe/plugins/index.html | 8 +- docs/cli-reference/describe/sitemap.xml | 2 +- .../download/artifacts/index.html | 8 +- docs/cli-reference/download/cli/index.html | 8 +- .../download/componentversions/index.html | 8 +- docs/cli-reference/download/index.html | 4 +- docs/cli-reference/download/index.xml | 2 +- .../download/resources/index.html | 10 +- docs/cli-reference/download/sitemap.xml | 2 +- docs/cli-reference/get/artifacts/index.html | 8 +- .../get/componentversions/index.html | 8 +- docs/cli-reference/get/config/index.html | 8 +- docs/cli-reference/get/credentials/index.html | 8 +- docs/cli-reference/get/index.html | 4 +- docs/cli-reference/get/index.xml | 2 +- docs/cli-reference/get/plugins/index.html | 8 +- docs/cli-reference/get/pubsub/index.html | 10 +- docs/cli-reference/get/references/index.html | 8 +- docs/cli-reference/get/resources/index.html | 8 +- .../cli-reference/get/routingslips/index.html | 8 +- docs/cli-reference/get/sitemap.xml | 2 +- docs/cli-reference/get/sources/index.html | 8 +- docs/cli-reference/get/verified/index.html | 8 +- docs/cli-reference/help/attributes/index.html | 10 +- docs/cli-reference/help/configfile/index.html | 10 +- .../help/credential-handling/index.html | 8 +- docs/cli-reference/help/index.html | 4 +- docs/cli-reference/help/index.xml | 4 +- docs/cli-reference/help/logging/index.html | 8 +- .../help/oci-references/index.html | 6 +- .../help/ocm-accessmethods/index.html | 8 +- .../help/ocm-downloadhandlers/index.html | 12 +- docs/cli-reference/help/ocm-labels/index.html | 6 +- docs/cli-reference/help/ocm-pubsub/index.html | 10 +- .../help/ocm-references/index.html | 6 +- .../help/ocm-uploadhandlers/index.html | 10 +- docs/cli-reference/help/sitemap.xml | 2 +- .../help/toi-bootstrapping/index.html | 14 +- docs/cli-reference/index.html | 14 +- docs/cli-reference/index.xml | 2 +- .../list/componentversions/index.html | 8 +- docs/cli-reference/list/index.html | 4 +- docs/cli-reference/list/index.xml | 2 +- docs/cli-reference/list/sitemap.xml | 2 +- docs/cli-reference/set/index.html | 4 +- docs/cli-reference/set/index.xml | 2 +- docs/cli-reference/set/pubsub/index.html | 10 +- docs/cli-reference/set/sitemap.xml | 2 +- docs/cli-reference/show/index.html | 4 +- docs/cli-reference/show/index.xml | 2 +- docs/cli-reference/show/sitemap.xml | 2 +- docs/cli-reference/show/tags/index.html | 8 +- docs/cli-reference/show/versions/index.html | 8 +- .../sign/componentversions/index.html | 8 +- docs/cli-reference/sign/hash/index.html | 8 +- docs/cli-reference/sign/index.html | 4 +- docs/cli-reference/sign/index.xml | 2 +- docs/cli-reference/sign/sitemap.xml | 2 +- docs/cli-reference/sitemap.xml | 2 +- .../transfer/artifacts/index.html | 8 +- .../commontransportarchive/index.html | 10 +- .../transfer/componentarchive/index.html | 8 +- .../transfer/componentversions/index.html | 10 +- docs/cli-reference/transfer/index.html | 4 +- docs/cli-reference/transfer/index.xml | 2 +- docs/cli-reference/transfer/sitemap.xml | 2 +- .../verify/componentversions/index.html | 8 +- docs/cli-reference/verify/index.html | 4 +- docs/cli-reference/verify/index.xml | 2 +- docs/cli-reference/verify/sitemap.xml | 2 +- docs/component-descriptors/index.html | 4 +- .../version-2/index.html | 4 +- .../version-3/index.html | 4 +- .../contributing-guideline/index.html | 6 +- docs/contribution/index.html | 4 +- docs/contribution/index.xml | 2 +- .../security-guideline/index.html | 4 +- docs/contribution/sitemap.xml | 2 +- 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 +- docs/examples/index.html | 4 +- .../index.html | 6 +- .../create-a-component-version/index.html | 4 +- .../index.html | 4 +- .../getting-started-with-ocm/index.html | 4 +- .../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 | 6 +- docs/overview/benefits-of-ocm/index.html | 4 +- docs/overview/important-terms/index.html | 4 +- docs/overview/index.html | 4 +- docs/overview/index.xml | 2 +- docs/overview/sitemap.xml | 2 +- docs/overview/specification/index.html | 4 +- docs/overview/specification/schema-v2.html | 2 +- .../specification/schema-v3alpha1.html | 2 +- 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 | 22 +-- .../index.html | 12 +- docs/tutorials/index.html | 8 +- docs/tutorials/index.xml | 2 +- .../input-and-access-types/index.html | 4 +- .../index.html | 8 +- .../index.html | 6 +- .../index.html | 4 +- docs/tutorials/ocm-and-gitops/index.html | 4 +- docs/tutorials/sitemap.xml | 2 +- .../index.html | 8 +- index.xml | 2 +- mpas/core_concepts/index.html | 2 +- mpas/getting_started/index.html | 133 +++++++++--------- mpas/installation/index.html | 2 +- mpas/sitemap.xml | 2 +- search-index.json | 2 +- sitemap.xml | 2 +- 162 files changed, 501 insertions(+), 502 deletions(-) diff --git a/docs/cli-reference/add/componentversions/index.html b/docs/cli-reference/add/componentversions/index.html index 4fe55af0..68b2c690 100644 --- a/docs/cli-reference/add/componentversions/index.html +++ b/docs/cli-reference/add/componentversions/index.html @@ -1,10 +1,10 @@ componentversions | Open Component Model -
+
-
Docs

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
@@ -32,12 +32,12 @@
 components will be added by value.
The –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.
The source, resource and reference list can be composed according to the commands
-ocm add sources, ocm add resources, ocm add references,
+ocm add sources, ocm add resources, ocm add references,
 respectively.
The description file might contain:
  • a 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 –schema option
 of the command. By default, v2 is used.
Various elements support to add arbitrary information by using labels
-(see ocm ocm-labels).
The –type option accepts a file format for the
+(see ocm ocm-labels).
The –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:
  • directory
  • tar
  • tgz
The default format is directory.
If the option –scheme is given, the specified component descriptor format is used/generated.
The following schema versions are supported for explicit conversions:
  • ocm.software/v3alpha1
  • v2 (default)
All yaml/json defined resources can be templated.
 Variables are specified as regular arguments following the syntax <name>=<value>.
@@ -75,7 +75,7 @@
 ‘url’: the URL of the maven repository.
  • plugin: [downloaders provided by plugins]
    sub namespace of the form <plugin name>/<handler>
  • ocm/ociArtifacts: downloading OCI artifacts
    The ociArtifacts downloader is able to download OCI artifacts
 as artifact archive according to the OCI distribution spec.
 The following artifact media types are supported:
    • application/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.
    It accepts a config with the following fields:
    • namespacePrefix: 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.
    • See ocm ocm-uploadhandlers for further details on using
+reference.
    See ocm ocm-uploadhandlers for further details on using
 upload handlers.
    Examples
    
 $ ocm add componentversions --file ctf --version 1.0 component-constructor.yaml
 
@@ -106,4 +106,4 @@
 
 
 The resource <code>text</code> is taken from a file <code>testdata</code> located
-next to the description file.
    See Also
    • ocm add — Add elements to a component repository or component version
    Prev
    componentarchive
    Next
    componentversions
    \ No newline at end of file +next to the description file.

    See Also

    Prev
    componentarchive
    Next
    componentversions
    \ No newline at end of file diff --git a/docs/cli-reference/add/index.html b/docs/cli-reference/add/index.html index 8f0bcb46..0aae12ca 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/index.xml b/docs/cli-reference/add/index.xml index 140f20af..dbf3a151 100644 --- a/docs/cli-reference/add/index.xml +++ b/docs/cli-reference/add/index.xml @@ -1 +1 @@ -add on Open Component Modelhttps://ocm.software/docs/cli-reference/add/Recent content in add on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsWed, 17 Apr 2024 18:02:57 +0200componentversionshttps://ocm.software/docs/cli-reference/add/componentversions/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/add/componentversions/Usage ocm add componentversions [&lt;options&gt;] [--version &lt;version&gt;] [&lt;ctf archive&gt;] {&lt;component-constructor.yaml&gt;} 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 -c, --create (re)create archive --dry-run evaluate and print component specifications -F, --file string target file/directory (default &#34;transport-archive&#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 -R, --replace replace existing elements -S, --scheme string schema version (default &#34;v2&#34;) -s, --settings stringArray settings file with variable settings (yaml) --templater string templater to use (go, none, spiff, subst) (default &#34;subst&#34;) -t, --type string archive format (directory, tar, tgz) (default &#34;directory&#34;) --uploader &lt;name&gt;=&lt;value&gt; repository uploader (&lt;name&gt;[:&lt;artifact type&gt;[:&lt;media type&gt;]]=&lt;JSON target config) (default []) -v, --version string default version for components Description Add component versions specified by a constructor file to a Common Transport Archive.referenceshttps://ocm.software/docs/cli-reference/add/references/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/add/references/Usage ocm add references [&lt;options&gt;] [&lt;target&gt;] {&lt;referencefile&gt; | &lt;var&gt;=&lt;value&gt;} Options --addenv access environment for templating --component string component name --dry-run evaluate and print reference specifications --extra &lt;name&gt;=&lt;value&gt; reference extra identity (default []) -F, --file string target file/directory (default &#34;component-archive&#34;) -h, --help help for references --label &lt;name&gt;=&lt;YAML&gt; reference label (leading * indicates signature relevant, optional version separated by @) --name string reference name -O, --output string output file for dry-run --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 &#34;subst&#34;) --version string reference version Description Add aggregation information specified in a reference file to a component version.resource-configurationhttps://ocm.software/docs/cli-reference/add/resource-configuration/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/add/resource-configuration/Usage ocm add resource-configuration [&lt;options&gt;] &lt;target&gt; {&lt;configfile&gt; | &lt;var&gt;=&lt;value&gt;} 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 --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 &lt;name&gt;=&lt;value&gt; resource extra identity (default []) --globalAccess YAML access specification for global access --groupId string maven group id --header &lt;name&gt;:&lt;value&gt;,&lt;value&gt;,.resourceshttps://ocm.software/docs/cli-reference/add/resources/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/add/resources/Usage ocm add resources [&lt;options&gt;] [&lt;target&gt;] {&lt;resourcefile&gt; | &lt;var&gt;=&lt;value&gt;} 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 --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 &lt;name&gt;=&lt;value&gt; resource extra identity (default []) -F, --file string target file/directory (default &#34;component-archive&#34;) --globalAccess YAML access specification for global access --groupId string maven group id --header &lt;name&gt;:&lt;value&gt;,&lt;value&gt;,.routingslipshttps://ocm.software/docs/cli-reference/add/routingslips/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/add/routingslips/Usage ocm add routingslips [&lt;options&gt;] &lt;component-version&gt; &lt;routing-slip&gt; &lt;type&gt; Options -S, --algorithm string signature handler (default &#34;RSASSA-PKCS1-V1_5&#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 (&lt;slipname&gt;[@&lt;digest&gt;]) --lookup stringArray repository name or spec for closure lookup fallback --repo string repository name or spec Description Add a routing slip entry for the specified routing slip name to the given component version.source-configurationhttps://ocm.software/docs/cli-reference/add/source-configuration/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/add/source-configuration/Usage ocm add source-configuration [&lt;options&gt;] &lt;target&gt; {&lt;configfile&gt; | &lt;var&gt;=&lt;value&gt;} 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 --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 &lt;name&gt;=&lt;value&gt; source extra identity (default []) --globalAccess YAML access specification for global access --groupId string maven group id --header &lt;name&gt;:&lt;value&gt;,&lt;value&gt;,.sourceshttps://ocm.software/docs/cli-reference/add/sources/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/add/sources/Usage ocm add sources [&lt;options&gt;] [&lt;target&gt;] {&lt;resourcefile&gt; | &lt;var&gt;=&lt;value&gt;} 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 --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 &lt;name&gt;=&lt;value&gt; source extra identity (default []) -F, --file string target file/directory (default &#34;component-archive&#34;) --globalAccess YAML access specification for global access --groupId string maven group id --header &lt;name&gt;:&lt;value&gt;,&lt;value&gt;,. \ No newline at end of file +add on Open Component Modelhttps://ocm.software/docs/cli-reference/add/Recent content in add on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model Contributorscomponentversionshttps://ocm.software/docs/cli-reference/add/componentversions/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/add/componentversions/Usage ocm add componentversions [&lt;options&gt;] [--version &lt;version&gt;] [&lt;ctf archive&gt;] {&lt;component-constructor.yaml&gt;} 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 -c, --create (re)create archive --dry-run evaluate and print component specifications -F, --file string target file/directory (default &#34;transport-archive&#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 -R, --replace replace existing elements -S, --scheme string schema version (default &#34;v2&#34;) -s, --settings stringArray settings file with variable settings (yaml) --templater string templater to use (go, none, spiff, subst) (default &#34;subst&#34;) -t, --type string archive format (directory, tar, tgz) (default &#34;directory&#34;) --uploader &lt;name&gt;=&lt;value&gt; repository uploader (&lt;name&gt;[:&lt;artifact type&gt;[:&lt;media type&gt;]]=&lt;JSON target config) (default []) -v, --version string default version for components Description Add component versions specified by a constructor file to a Common Transport Archive.referenceshttps://ocm.software/docs/cli-reference/add/references/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/add/references/Usage ocm add references [&lt;options&gt;] [&lt;target&gt;] {&lt;referencefile&gt; | &lt;var&gt;=&lt;value&gt;} Options --addenv access environment for templating --component string component name --dry-run evaluate and print reference specifications --extra &lt;name&gt;=&lt;value&gt; reference extra identity (default []) -F, --file string target file/directory (default &#34;component-archive&#34;) -h, --help help for references --label &lt;name&gt;=&lt;YAML&gt; reference label (leading * indicates signature relevant, optional version separated by @) --name string reference name -O, --output string output file for dry-run --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 &#34;subst&#34;) --version string reference version Description Add aggregation information specified in a reference file to a component version.resource-configurationhttps://ocm.software/docs/cli-reference/add/resource-configuration/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/add/resource-configuration/Usage ocm add resource-configuration [&lt;options&gt;] &lt;target&gt; {&lt;configfile&gt; | &lt;var&gt;=&lt;value&gt;} 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 --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 &lt;name&gt;=&lt;value&gt; resource extra identity (default []) --globalAccess YAML access specification for global access --groupId string maven group id --header &lt;name&gt;:&lt;value&gt;,&lt;value&gt;,.resourceshttps://ocm.software/docs/cli-reference/add/resources/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/add/resources/Usage ocm add resources [&lt;options&gt;] [&lt;target&gt;] {&lt;resourcefile&gt; | &lt;var&gt;=&lt;value&gt;} 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 --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 &lt;name&gt;=&lt;value&gt; resource extra identity (default []) -F, --file string target file/directory (default &#34;component-archive&#34;) --globalAccess YAML access specification for global access --groupId string maven group id --header &lt;name&gt;:&lt;value&gt;,&lt;value&gt;,.routingslipshttps://ocm.software/docs/cli-reference/add/routingslips/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/add/routingslips/Usage ocm add routingslips [&lt;options&gt;] &lt;component-version&gt; &lt;routing-slip&gt; &lt;type&gt; Options -S, --algorithm string signature handler (default &#34;RSASSA-PKCS1-V1_5&#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 (&lt;slipname&gt;[@&lt;digest&gt;]) --lookup stringArray repository name or spec for closure lookup fallback --repo string repository name or spec Description Add a routing slip entry for the specified routing slip name to the given component version.source-configurationhttps://ocm.software/docs/cli-reference/add/source-configuration/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/add/source-configuration/Usage ocm add source-configuration [&lt;options&gt;] &lt;target&gt; {&lt;configfile&gt; | &lt;var&gt;=&lt;value&gt;} 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 --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 &lt;name&gt;=&lt;value&gt; source extra identity (default []) --globalAccess YAML access specification for global access --groupId string maven group id --header &lt;name&gt;:&lt;value&gt;,&lt;value&gt;,.sourceshttps://ocm.software/docs/cli-reference/add/sources/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/add/sources/Usage ocm add sources [&lt;options&gt;] [&lt;target&gt;] {&lt;resourcefile&gt; | &lt;var&gt;=&lt;value&gt;} 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 --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 &lt;name&gt;=&lt;value&gt; source extra identity (default []) -F, --file string target file/directory (default &#34;component-archive&#34;) --globalAccess YAML access specification for global access --groupId string maven group id --header &lt;name&gt;:&lt;value&gt;,&lt;value&gt;,. \ 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 bcf58d3b..59e02135 100644 --- a/docs/cli-reference/add/references/index.html +++ b/docs/cli-reference/add/references/index.html @@ -1,10 +1,10 @@ references | Open Component Model -
    +
    -
    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 [])
@@ -73,4 +73,4 @@
 name: myref
 component: github.com/my/component
 version: ${VERSION]
-$ ocm add references  path/to/ca  references.yaml VERSION=1.0.0

    See Also

    • ocm add — Add elements to a component repository or component version
    Prev
    pubsub
    Next
    references
    \ No newline at end of file +$ ocm add references path/to/ca references.yaml VERSION=1.0.0

    See Also

    Prev
    pubsub
    Next
    references
    \ No newline at end of file diff --git a/docs/cli-reference/add/resource-configuration/index.html b/docs/cli-reference/add/resource-configuration/index.html index 2b2683fe..2389d8fe 100644 --- a/docs/cli-reference/add/resource-configuration/index.html +++ b/docs/cli-reference/add/resource-configuration/index.html @@ -1,10 +1,10 @@ resource-configuration | Open Component Model -
    +
    -
    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
@@ -59,7 +59,7 @@
       --type string                         resource type
       --url string                          artifact or server url
       --verb string                         http request method
-      --version string                      resource version

    Description

    Add a resource specification to a resource config file used by ocm add resources.

    It is possible to describe a single resource via command line options. + --version string resource version

    Description

    Add a resource specification to a resource config file used by ocm add resources.

    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 –resource, which must be a YAML or JSON string. Alternatively, the name and version can be specified with the @@ -198,7 +198,7 @@ If always requires the field type describing the kind and version shown below.

    • Access type S3

      This method implements the access of a blob stored in an S3 bucket.

      The following versions are supported:

      • Version v1

        The type specific specification fields are:

        • region (optional) string

          OCI repository reference (this artifact name used to store the blob).

        • bucket string

          The name of the S3 bucket containing the blob

        • key string

          The key of the desired blob

        • version (optional) string

          The key of the desired blob

        • mediaType (optional) string

          The media type of the content

      • Version v2

        The type specific specification fields are:

        • region (optional) string

          OCI repository reference (this artifact name used to store the blob).

        • bucketName string

          The name of the S3 bucket containing the blob

        • objectKey string

          The key of the desired blob

        • version (optional) string

          The key of the desired blob

        • mediaType (optional) string

          The media type of the content

    • Access type gitHub

      This method implements the access of the content of a git commit stored in a GitHub repository.

      The following versions are supported:

      • Version v1

        The type specific specification fields are:

        • repoUrl string

          Repository URL with or without scheme.

        • ref (optional) string

          Original ref used to get the commit from

        • commit string

          The sha/id of the git commit

      Options used to configure fields: –accessHostname, –accessRepository, –commit

    • Access type helm

      This method implements the access of a Helm chart stored in a Helm repository.

      The following versions are supported:

      • Version v1

        The type specific specification fields are:

        • helmRepository string

          Helm repository URL.

        • helmChart string

          The name of the Helm chart and its version separated by a colon.

        • version string

          The version of the Helm chart if not specified as part of the chart name.

        • caCert string

          An optional TLS root certificate.

        • keyring string

          An optional keyring used to verify the chart.

        It uses the consumer identity type HelmChartRepository with the fields -for a hostpath identity matcher (see ocm get credentials).

      Options used to configure fields: –accessRepository, –accessVersion, –package

    • Access type localBlob

      This method is used to store a resource blob along with the component descriptor +for a hostpath identity matcher (see ocm get credentials).

    Options used to configure fields: –accessRepository, –accessVersion, –package

  • Access type localBlob

    This method is used to store a resource blob along with the component descriptor on behalf of the hosting OCM repository.

    Its 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, @@ -245,4 +245,4 @@ key: subkey: "abc ${MY_VAL}"

    • Examples

    
-$ ocm add resource-configuration resources.yaml --name myresource --type PlainText --input '{ "type": "file", "path": "testdata/testcontent", "mediaType": "text/plain" }'

    See Also

    • ocm add — Add elements to a component repository or component version
    Prev
    references
    Next
    resources
    \ No newline at end of file +$ ocm add resource-configuration resources.yaml --name myresource --type PlainText --input '{ "type": "file", "path": "testdata/testcontent", "mediaType": "text/plain" }'

    See Also

    Prev
    references
    Next
    resources
    \ No newline at end of file diff --git a/docs/cli-reference/add/resources/index.html b/docs/cli-reference/add/resources/index.html index 34396e01..f9f4ea26 100644 --- a/docs/cli-reference/add/resources/index.html +++ b/docs/cli-reference/add/resources/index.html @@ -1,10 +1,10 @@ resources | Open Component Model -
    +
    -
    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
@@ -206,7 +206,7 @@
 If always requires the field type describing the kind and version
 shown below.
    • Access type S3
      This method implements the access of a blob stored in an S3 bucket.
      The following versions are supported:
      • Version v1
        The type specific specification fields are:
        • region (optional) string
          OCI repository reference (this artifact name used to store the blob).
        • bucket string
          The name of the S3 bucket containing the blob
        • key string
          The key of the desired blob
        • version (optional) string
          The key of the desired blob
        • mediaType (optional) string
          The media type of the content
      • Version v2
        The type specific specification fields are:
        • region (optional) string
          OCI repository reference (this artifact name used to store the blob).
        • bucketName string
          The name of the S3 bucket containing the blob
        • objectKey string
          The key of the desired blob
        • version (optional) string
          The key of the desired blob
        • mediaType (optional) string
          The media type of the content
    • Access type gitHub
      This method implements the access of the content of a git commit stored in a
 GitHub repository.
      The following versions are supported:
      • Version v1
        The type specific specification fields are:
        • repoUrl string
          Repository URL with or without scheme.
        • ref (optional) string
          Original ref used to get the commit from
        • commit string
          The sha/id of the git commit
      Options used to configure fields: –accessHostname, –accessRepository, –commit
    • Access type helm
      This method implements the access of a Helm chart stored in a Helm repository.
      The following versions are supported:
      • Version v1
        The type specific specification fields are:
        • helmRepository string
          Helm repository URL.
        • helmChart string
          The name of the Helm chart and its version separated by a colon.
        • version string
          The version of the Helm chart if not specified as part of the chart name.
        • caCert string
          An optional TLS root certificate.
        • keyring string
          An optional keyring used to verify the chart.
        It uses the consumer identity type HelmChartRepository with the fields
-for a hostpath identity matcher (see ocm get credentials).
      Options used to configure fields: –accessRepository, –accessVersion, –package
    • Access type localBlob
      This method is used to store a resource blob along with the component descriptor
+for a hostpath identity matcher (see ocm get credentials).
    Options used to configure fields: –accessRepository, –accessVersion, –package
  • Access type localBlob
    This method is used to store a resource blob along with the component descriptor
 on behalf of the hosting OCM repository.
    Its 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,
@@ -269,4 +269,4 @@
   type: file
   path: testdata/testcontent
   mediaType: text/plain
-$ ocm add resources --file path/to/ca  resources.yaml VERSION=1.0.0

    • See Also

    • ocm add — Add elements to a component repository or component version
    Prev
    resource-configuration
    Next
    resources
    \ No newline at end of file +$ ocm add resources --file path/to/ca resources.yaml VERSION=1.0.0

    See Also

    Prev
    resource-configuration
    Next
    resources
    \ No newline at end of file diff --git a/docs/cli-reference/add/routingslips/index.html b/docs/cli-reference/add/routingslips/index.html index 1a6ecc92..ceed860e 100644 --- a/docs/cli-reference/add/routingslips/index.html +++ b/docs/cli-reference/add/routingslips/index.html @@ -1,10 +1,10 @@ routingslips | Open Component Model -
    +
    -
    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)
@@ -31,4 +31,4 @@
 it only contains a single component version. Therefore, in this scenario
 this option must always be specified to be able to follow component
 references.
    Examples
    
-$ ocm add routingslip ghcr.io/mandelsoft/ocm//ocmdemoinstaller:0.0.1-dev mandelsoft.org comment --entry "comment=some text"
    See Also
    • ocm add — Add elements to a component repository or component version
    Prev
    resources
    Next
    routingslips
    \ No newline at end of file +$ ocm add routingslip ghcr.io/mandelsoft/ocm//ocmdemoinstaller:0.0.1-dev mandelsoft.org comment --entry "comment=some text"

    See Also

    Prev
    resources
    Next
    routingslips
    \ No newline at end of file diff --git a/docs/cli-reference/add/sitemap.xml b/docs/cli-reference/add/sitemap.xml index 68020afb..f1a07275 100644 --- a/docs/cli-reference/add/sitemap.xml +++ b/docs/cli-reference/add/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/cli-reference/add/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/references/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/resource-configuration/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/resources/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/routingslips/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/source-configuration/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/sources/2024-04-17T18:02:57+02:00monthly0.5 \ No newline at end of file +https://ocm.software/docs/cli-reference/add/componentversions/monthly0.5https://ocm.software/docs/cli-reference/add/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/add/routingslips/monthly0.5https://ocm.software/docs/cli-reference/add/source-configuration/monthly0.5https://ocm.software/docs/cli-reference/add/sources/monthly0.5 \ No newline at end of file diff --git a/docs/cli-reference/add/source-configuration/index.html b/docs/cli-reference/add/source-configuration/index.html index b05e8eb8..48d0472d 100644 --- a/docs/cli-reference/add/source-configuration/index.html +++ b/docs/cli-reference/add/source-configuration/index.html @@ -1,10 +1,10 @@ source-configuration | Open Component Model -
    +
    -
    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
@@ -58,7 +58,7 @@
       --type string                         source type
       --url string                          artifact or server url
       --verb string                         http request method
-      --version string                      source version

    Description

    Add a source specification to a source config file used by ocm add sources.

    It is possible to describe a single source via command line options. + --version string source version

    Description

    Add a source specification to a source config file used by ocm add sources.

    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 –source, which must be a YAML or JSON string. Alternatively, the name and version can be specified with the @@ -196,7 +196,7 @@ If always requires the field type describing the kind and version shown below.

    • Access type S3

      This method implements the access of a blob stored in an S3 bucket.

      The following versions are supported:

      • Version v1

        The type specific specification fields are:

        • region (optional) string

          OCI repository reference (this artifact name used to store the blob).

        • bucket string

          The name of the S3 bucket containing the blob

        • key string

          The key of the desired blob

        • version (optional) string

          The key of the desired blob

        • mediaType (optional) string

          The media type of the content

      • Version v2

        The type specific specification fields are:

        • region (optional) string

          OCI repository reference (this artifact name used to store the blob).

        • bucketName string

          The name of the S3 bucket containing the blob

        • objectKey string

          The key of the desired blob

        • version (optional) string

          The key of the desired blob

        • mediaType (optional) string

          The media type of the content

    • Access type gitHub

      This method implements the access of the content of a git commit stored in a GitHub repository.

      The following versions are supported:

      • Version v1

        The type specific specification fields are:

        • repoUrl string

          Repository URL with or without scheme.

        • ref (optional) string

          Original ref used to get the commit from

        • commit string

          The sha/id of the git commit

      Options used to configure fields: –accessHostname, –accessRepository, –commit

    • Access type helm

      This method implements the access of a Helm chart stored in a Helm repository.

      The following versions are supported:

      • Version v1

        The type specific specification fields are:

        • helmRepository string

          Helm repository URL.

        • helmChart string

          The name of the Helm chart and its version separated by a colon.

        • version string

          The version of the Helm chart if not specified as part of the chart name.

        • caCert string

          An optional TLS root certificate.

        • keyring string

          An optional keyring used to verify the chart.

        It uses the consumer identity type HelmChartRepository with the fields -for a hostpath identity matcher (see ocm get credentials).

      Options used to configure fields: –accessRepository, –accessVersion, –package

    • Access type localBlob

      This method is used to store a resource blob along with the component descriptor +for a hostpath identity matcher (see ocm get credentials).

    Options used to configure fields: –accessRepository, –accessVersion, –package

  • Access type localBlob

    This method is used to store a resource blob along with the component descriptor on behalf of the hosting OCM repository.

    Its 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, @@ -243,4 +243,4 @@ key: subkey: "abc ${MY_VAL}"

    • Examples

    
-$ ocm add source-config sources.yaml --name sources --type filesystem --access '{ "type": "gitHub", "repoUrl": "ocm.software/ocm", "commit": "xyz" }'

    See Also

    • ocm add — Add elements to a component repository or component version
    Prev
    rsakeypair
    Next
    sources
    \ No newline at end of file +$ ocm add source-config sources.yaml --name sources --type filesystem --access '{ "type": "gitHub", "repoUrl": "ocm.software/ocm", "commit": "xyz" }'

    See Also

    Prev
    rsakeypair
    Next
    sources
    \ No newline at end of file diff --git a/docs/cli-reference/add/sources/index.html b/docs/cli-reference/add/sources/index.html index dc1147cb..b7539d92 100644 --- a/docs/cli-reference/add/sources/index.html +++ b/docs/cli-reference/add/sources/index.html @@ -1,10 +1,10 @@ sources | Open Component Model -
    +
    -
    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
@@ -204,7 +204,7 @@
 If always requires the field type describing the kind and version
 shown below.
    • Access type S3
      This method implements the access of a blob stored in an S3 bucket.
      The following versions are supported:
      • Version v1
        The type specific specification fields are:
        • region (optional) string
          OCI repository reference (this artifact name used to store the blob).
        • bucket string
          The name of the S3 bucket containing the blob
        • key string
          The key of the desired blob
        • version (optional) string
          The key of the desired blob
        • mediaType (optional) string
          The media type of the content
      • Version v2
        The type specific specification fields are:
        • region (optional) string
          OCI repository reference (this artifact name used to store the blob).
        • bucketName string
          The name of the S3 bucket containing the blob
        • objectKey string
          The key of the desired blob
        • version (optional) string
          The key of the desired blob
        • mediaType (optional) string
          The media type of the content
    • Access type gitHub
      This method implements the access of the content of a git commit stored in a
 GitHub repository.
      The following versions are supported:
      • Version v1
        The type specific specification fields are:
        • repoUrl string
          Repository URL with or without scheme.
        • ref (optional) string
          Original ref used to get the commit from
        • commit string
          The sha/id of the git commit
      Options used to configure fields: –accessHostname, –accessRepository, –commit
    • Access type helm
      This method implements the access of a Helm chart stored in a Helm repository.
      The following versions are supported:
      • Version v1
        The type specific specification fields are:
        • helmRepository string
          Helm repository URL.
        • helmChart string
          The name of the Helm chart and its version separated by a colon.
        • version string
          The version of the Helm chart if not specified as part of the chart name.
        • caCert string
          An optional TLS root certificate.
        • keyring string
          An optional keyring used to verify the chart.
        It uses the consumer identity type HelmChartRepository with the fields
-for a hostpath identity matcher (see ocm get credentials).
      Options used to configure fields: –accessRepository, –accessVersion, –package
    • Access type localBlob
      This method is used to store a resource blob along with the component descriptor
+for a hostpath identity matcher (see ocm get credentials).
    Options used to configure fields: –accessRepository, –accessVersion, –package
  • Access type localBlob
    This method is used to store a resource blob along with the component descriptor
 on behalf of the hosting OCM repository.
    Its 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,
@@ -253,4 +253,4 @@
   key:
     subkey: "abc ${MY_VAL}"

    • Examples

    
-$ ocm add sources --file path/to/cafile sources.yaml

    See Also

    • ocm add — Add elements to a component repository or component version
    Prev
    source-configuration
    Next
    sources
    \ No newline at end of file +$ ocm add sources --file path/to/cafile sources.yaml

    See Also

    Prev
    source-configuration
    Next
    sources
    \ No newline at end of file diff --git a/docs/cli-reference/check/componentversions/index.html b/docs/cli-reference/check/componentversions/index.html index d20016b7..c39827ae 100644 --- a/docs/cli-reference/check/componentversions/index.html +++ b/docs/cli-reference/check/componentversions/index.html @@ -1,10 +1,10 @@ componentversions | Open Component Model -
    +
    -
    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
@@ -21,4 +21,4 @@
 This means that they are using local access methods, only.
    With the option –output the output mode can be selected.
 The following modes are supported:
    •  (default)
    • JSON
    • json
    • wide
    • yaml
    Examples
    
 $ ocm check componentversion ghcr.io/mandelsoft/kubelink
-$ ocm get componentversion --repo OCIRegistry::ghcr.io mandelsoft/kubelink
    See Also
    • ocm check — check components in OCM repository
    Prev
    componentversions
    Next
    componentversions
    \ No newline at end of file +$ ocm get componentversion --repo OCIRegistry::ghcr.io mandelsoft/kubelink

    See Also

    • ocm check — check components in OCM repository
    Prev
    componentversions
    Next
    componentversions
    \ No newline at end of file diff --git a/docs/cli-reference/check/index.html b/docs/cli-reference/check/index.html index 2bf068b8..fa39991e 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/check/index.xml b/docs/cli-reference/check/index.xml index f887760b..605f9452 100644 --- a/docs/cli-reference/check/index.xml +++ b/docs/cli-reference/check/index.xml @@ -1 +1 @@ -check on Open Component Modelhttps://ocm.software/docs/cli-reference/check/Recent content in check on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsWed, 17 Apr 2024 18:02:57 +0200componentversionshttps://ocm.software/docs/cli-reference/check/componentversions/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/check/componentversions/Usage ocm check componentversions [&lt;options&gt;] {&lt;component-reference&gt;} 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 -o, --output string output mode (JSON, json, wide, yaml) --repo string repository name or spec -s, --sort stringArray sort fields Description This command checks, whether component versions are completely contained in an OCM repository with all its dependent component references. \ No newline at end of file +check on Open Component Modelhttps://ocm.software/docs/cli-reference/check/Recent content in check on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model Contributorscomponentversionshttps://ocm.software/docs/cli-reference/check/componentversions/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/check/componentversions/Usage ocm check componentversions [&lt;options&gt;] {&lt;component-reference&gt;} 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 -o, --output string output mode (JSON, json, wide, yaml) --repo string repository name or spec -s, --sort stringArray sort fields Description This command checks, whether component versions are completely contained in an OCM repository with all its dependent component references. \ No newline at end of file diff --git a/docs/cli-reference/check/sitemap.xml b/docs/cli-reference/check/sitemap.xml index c10f24b8..201e45bb 100644 --- a/docs/cli-reference/check/sitemap.xml +++ b/docs/cli-reference/check/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/cli-reference/check/componentversions/2024-04-17T18:02:57+02:00monthly0.5 \ No newline at end of file +https://ocm.software/docs/cli-reference/check/componentversions/monthly0.5 \ 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 20255a06..bfc5f2c6 100644 --- a/docs/cli-reference/clean/cache/index.html +++ b/docs/cli-reference/clean/cache/index.html @@ -1,10 +1,10 @@ cache | Open Component Model -
    +
    -
    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 +$ 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 7adb40f7..3ff4ec8d 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/clean/index.xml b/docs/cli-reference/clean/index.xml index d4dce27b..04e1f994 100644 --- a/docs/cli-reference/clean/index.xml +++ b/docs/cli-reference/clean/index.xml @@ -1 +1 @@ -clean on Open Component Modelhttps://ocm.software/docs/cli-reference/clean/Recent content in clean on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsWed, 17 Apr 2024 18:02:57 +0200cachehttps://ocm.software/docs/cli-reference/clean/cache/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/clean/cache/Usage ocm clean cache [&lt;options&gt;] 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). \ No newline at end of file +clean on Open Component Modelhttps://ocm.software/docs/cli-reference/clean/Recent content in clean on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model Contributorscachehttps://ocm.software/docs/cli-reference/clean/cache/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/clean/cache/Usage ocm clean cache [&lt;options&gt;] 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). \ No newline at end of file diff --git a/docs/cli-reference/clean/sitemap.xml b/docs/cli-reference/clean/sitemap.xml index ae930c7c..26b5e7fc 100644 --- a/docs/cli-reference/clean/sitemap.xml +++ b/docs/cli-reference/clean/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/cli-reference/clean/cache/2024-04-17T18:02:57+02:00monthly0.5 \ No newline at end of file +https://ocm.software/docs/cli-reference/clean/cache/monthly0.5 \ 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 fe0664d8..e0b6f90e 100644 --- a/docs/cli-reference/create/componentarchive/index.html +++ b/docs/cli-reference/create/componentarchive/index.html @@ -1,10 +1,10 @@ componentarchive | Open Component Model -
    +
    -
    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
@@ -13,4 +13,4 @@
 to host component version content or a tar/tgz file (see option –type).
    A provider must be specified, additional provider labels are optional.
    The –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:
    • directory
    • tar
    • tgz
    The default format is directory.
    If the option –scheme is given, the specified component descriptor format is used/generated.
    The following schema versions are supported for explicit conversions:
    • ocm.software/v3alpha1
    • v2 (default)
    Examples
    
-$ ocm create componentarchive --file myfirst --provider acme.org --provider email=alice@acme.org acme.org/demo 1.0
    See Also
    • ocm create — Create transport or component archive
    Prev
    commontransportarchive
    Next
    componentarchive
    \ No newline at end of file +$ ocm create componentarchive --file myfirst --provider acme.org --provider email=alice@acme.org acme.org/demo 1.0

    See Also

    • ocm create — Create transport or component archive
    Prev
    commontransportarchive
    Next
    componentarchive
    \ No newline at end of file diff --git a/docs/cli-reference/create/index.html b/docs/cli-reference/create/index.html index 98a90eda..cbe28bd1 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/index.xml b/docs/cli-reference/create/index.xml index 481f3bf5..533fdbce 100644 --- a/docs/cli-reference/create/index.xml +++ b/docs/cli-reference/create/index.xml @@ -1 +1 @@ -create on Open Component Modelhttps://ocm.software/docs/cli-reference/create/Recent content in create on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsWed, 17 Apr 2024 18:02:57 +0200componentarchivehttps://ocm.software/docs/cli-reference/create/componentarchive/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/create/componentarchive/Usage ocm create componentarchive [&lt;options&gt;] &lt;component&gt; &lt;version&gt; --provider &lt;provider-name&gt; {--provider &lt;label&gt;=&lt;value&gt;} {&lt;label&gt;=&lt;value&gt;} Options -F, --file string target file/directory (default &#34;component-archive&#34;) -f, --force remove existing content -h, --help help for componentarchive -p, --provider stringArray provider attribute -S, --scheme string schema version (default &#34;v2&#34;) -t, --type string archive format (directory, tar, tgz) (default &#34;directory&#34;) Description Create a new component archive.rsakeypairhttps://ocm.software/docs/cli-reference/create/rsakeypair/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/create/rsakeypair/Usage ocm create rsakeypair [&lt;private key file&gt; [&lt;public key file&gt;]] {&lt;subject-attribute&gt;=&lt;value&gt;} 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 -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) Description Create an RSA public key pair and save to files.transportarchivehttps://ocm.software/docs/cli-reference/create/transportarchive/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/create/transportarchive/Usage ocm create transportarchive [&lt;options&gt;] &lt;path&gt; Options -f, --force remove existing content -h, --help help for transportarchive -t, --type string archive format (directory, tar, tgz) (default &#34;directory&#34;) Description Create a new empty OCM/OCI transport archive. \ No newline at end of file +create on Open Component Modelhttps://ocm.software/docs/cli-reference/create/Recent content in create on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model Contributorscomponentarchivehttps://ocm.software/docs/cli-reference/create/componentarchive/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/create/componentarchive/Usage ocm create componentarchive [&lt;options&gt;] &lt;component&gt; &lt;version&gt; --provider &lt;provider-name&gt; {--provider &lt;label&gt;=&lt;value&gt;} {&lt;label&gt;=&lt;value&gt;} Options -F, --file string target file/directory (default &#34;component-archive&#34;) -f, --force remove existing content -h, --help help for componentarchive -p, --provider stringArray provider attribute -S, --scheme string schema version (default &#34;v2&#34;) -t, --type string archive format (directory, tar, tgz) (default &#34;directory&#34;) Description Create a new component archive.rsakeypairhttps://ocm.software/docs/cli-reference/create/rsakeypair/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/create/rsakeypair/Usage ocm create rsakeypair [&lt;private key file&gt; [&lt;public key file&gt;]] {&lt;subject-attribute&gt;=&lt;value&gt;} 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 -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) Description Create an RSA public key pair and save to files.transportarchivehttps://ocm.software/docs/cli-reference/create/transportarchive/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/create/transportarchive/Usage ocm create transportarchive [&lt;options&gt;] &lt;path&gt; Options -f, --force remove existing content -h, --help help for transportarchive -t, --type string archive format (directory, tar, tgz) (default &#34;directory&#34;) Description Create a new empty OCM/OCI transport archive. \ 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 55f15213..9083b0fb 100644 --- a/docs/cli-reference/create/rsakeypair/index.html +++ b/docs/cli-reference/create/rsakeypair/index.html @@ -1,10 +1,10 @@ rsakeypair | Open Component Model -
    +
    -
    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
@@ -22,4 +22,4 @@
 non-self-signed ca is used to sign the key, its certificate chain is verified.
 Therefore, an additional root certificate (–root-certs) is required,
 if no public root certificate was used to create the used ca.
    For signing the public key the following subject attributes are supported:
    • CN, 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
    See Also
    • ocm create — Create transport or component archive
    Prev
    routingslips
    Next
    source-configuration
    \ No newline at end of file +$ ocm create rsakeypair mandelsoft.priv mandelsoft.cert issuer=mandelsoft

    See Also

    • ocm create — Create transport or component archive
    Prev
    routingslips
    Next
    source-configuration
    \ No newline at end of file diff --git a/docs/cli-reference/create/sitemap.xml b/docs/cli-reference/create/sitemap.xml index 0c508ec5..4fafae1a 100644 --- a/docs/cli-reference/create/sitemap.xml +++ b/docs/cli-reference/create/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/cli-reference/create/componentarchive/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/create/rsakeypair/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/create/transportarchive/2024-04-17T18:02:57+02:00monthly0.5 \ No newline at end of file +https://ocm.software/docs/cli-reference/create/componentarchive/monthly0.5https://ocm.software/docs/cli-reference/create/rsakeypair/monthly0.5https://ocm.software/docs/cli-reference/create/transportarchive/monthly0.5 \ No newline at end of file diff --git a/docs/cli-reference/create/transportarchive/index.html b/docs/cli-reference/create/transportarchive/index.html index f573fd93..389d908c 100644 --- a/docs/cli-reference/create/transportarchive/index.html +++ b/docs/cli-reference/create/transportarchive/index.html @@ -1,10 +1,10 @@ transportarchive | Open Component Model -
    +
    -
    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 +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 f35ec73a..9087355d 100644 --- a/docs/cli-reference/describe/artifacts/index.html +++ b/docs/cli-reference/describe/artifacts/index.html @@ -1,10 +1,10 @@ artifacts | Open Component Model -
    +
    -
    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 @@ -16,4 +16,4 @@ linked library can be used:

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

    With the option –output the output mode can be selected. The following modes are supported:

    • (default)
    • JSON
    • json
    • yaml

    Examples

    
 $ ocm describe artifact ghcr.io/mandelsoft/kubelink
-$ ocm describe artifact --repo OCIRegistry::ghcr.io mandelsoft/kubelink

    See Also

    • ocm describe — Describe various elements by using appropriate sub commands.
    Prev
    Security Guideline
    Next
    artifacts
    \ No newline at end of file +$ ocm describe artifact --repo OCIRegistry::ghcr.io mandelsoft/kubelink

    See Also

    • ocm describe — Describe various elements by using appropriate sub commands.
    Prev
    Security Guideline
    Next
    artifacts
    \ No newline at end of file diff --git a/docs/cli-reference/describe/cache/index.html b/docs/cli-reference/describe/cache/index.html index 07b677b5..c11f4aa2 100644 --- a/docs/cli-reference/describe/cache/index.html +++ b/docs/cli-reference/describe/cache/index.html @@ -1,8 +1,8 @@ cache | Open Component Model -
    +
    -
    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 +
    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 d2d1eef2..ea8a9dae 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/index.xml b/docs/cli-reference/describe/index.xml index 2dd1fbf6..6a67fd54 100644 --- a/docs/cli-reference/describe/index.xml +++ b/docs/cli-reference/describe/index.xml @@ -1 +1 @@ -describe on Open Component Modelhttps://ocm.software/docs/cli-reference/describe/Recent content in describe on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsWed, 17 Apr 2024 18:02:57 +0200artifactshttps://ocm.software/docs/cli-reference/describe/artifacts/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/describe/artifacts/Usage ocm describe artifacts [&lt;options&gt;] {&lt;artifact-reference&gt;} 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 all tagged artifacts are listed.cachehttps://ocm.software/docs/cli-reference/describe/cache/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/describe/cache/Usage ocm describe cache [&lt;options&gt;] Options -h, --help help for cache Description Show details about the OCI blob cache (if given).packagehttps://ocm.software/docs/cli-reference/describe/package/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/describe/package/Usage ocm describe package [&lt;options&gt;] {&lt;component-reference&gt;} {&lt;resource id field&gt;} 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.pluginshttps://ocm.software/docs/cli-reference/describe/plugins/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/describe/plugins/Usage ocm describe plugins [&lt;options&gt;] {&lt;plugin name&gt;} Options -h, --help help for plugins Description Describes provides comprehensive information about the capabilities of a plugin. \ No newline at end of file +describe on Open Component Modelhttps://ocm.software/docs/cli-reference/describe/Recent content in describe on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model Contributorsartifactshttps://ocm.software/docs/cli-reference/describe/artifacts/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/describe/artifacts/Usage ocm describe artifacts [&lt;options&gt;] {&lt;artifact-reference&gt;} 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 all tagged artifacts are listed.cachehttps://ocm.software/docs/cli-reference/describe/cache/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/describe/cache/Usage ocm describe cache [&lt;options&gt;] Options -h, --help help for cache Description Show details about the OCI blob cache (if given).packagehttps://ocm.software/docs/cli-reference/describe/package/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/describe/package/Usage ocm describe package [&lt;options&gt;] {&lt;component-reference&gt;} {&lt;resource id field&gt;} 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.pluginshttps://ocm.software/docs/cli-reference/describe/plugins/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/describe/plugins/Usage ocm describe plugins [&lt;options&gt;] {&lt;plugin name&gt;} Options -h, --help help for plugins Description Describes provides comprehensive information about the capabilities of a plugin. \ 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 6456a496..1ff6b681 100644 --- a/docs/cli-reference/describe/package/index.html +++ b/docs/cli-reference/describe/package/index.html @@ -1,14 +1,14 @@ package | Open Component Model -
    +
    -
    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 -of software. See also the topic ocm toi-bootstrapping.

    The first matching resource of this type is selected. Optionally a set of +of software. See also the topic ocm toi-bootstrapping.

    The 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 (<attr>=<value>).

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

    <component>[:<version>]

    If no –repo option is specified the given names are interpreted @@ -23,4 +23,4 @@ it only contains a single component version. Therefore, in this scenario this option must always be specified to be able to follow component references.

    Examples

    
-$ ocm toi describe package ghcr.io/mandelsoft/ocm//ocmdemoinstaller:0.0.1-dev

    See Also

    • ocm describe — Describe various elements by using appropriate sub commands.
    Prev
    ocm-uploadhandlers
    Next
    plugins
    \ No newline at end of file +$ ocm toi describe package ghcr.io/mandelsoft/ocm//ocmdemoinstaller:0.0.1-dev

    See Also

    • ocm describe — Describe various elements by using appropriate sub commands.
    Prev
    ocm-uploadhandlers
    Next
    plugins
    \ No newline at end of file diff --git a/docs/cli-reference/describe/plugins/index.html b/docs/cli-reference/describe/plugins/index.html index 335dcbd0..c5a98547 100644 --- a/docs/cli-reference/describe/plugins/index.html +++ b/docs/cli-reference/describe/plugins/index.html @@ -1,10 +1,10 @@ plugins | Open Component Model -
    +
    -
    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 +$ 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/describe/sitemap.xml b/docs/cli-reference/describe/sitemap.xml index cf2aa0ff..e10045f3 100644 --- a/docs/cli-reference/describe/sitemap.xml +++ b/docs/cli-reference/describe/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/cli-reference/describe/artifacts/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/describe/cache/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/describe/package/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/describe/plugins/2024-04-17T18:02:57+02:00monthly0.5 \ No newline at end of file +https://ocm.software/docs/cli-reference/describe/artifacts/monthly0.5https://ocm.software/docs/cli-reference/describe/cache/monthly0.5https://ocm.software/docs/cli-reference/describe/package/monthly0.5https://ocm.software/docs/cli-reference/describe/plugins/monthly0.5 \ 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 0d213490..29630744 100644 --- a/docs/cli-reference/download/artifacts/index.html +++ b/docs/cli-reference/download/artifacts/index.html @@ -1,10 +1,10 @@ artifacts | Open Component Model -
    +
    -
    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
@@ -19,4 +19,4 @@
 be a layered filesystem (for example OCI Image) and provided the effective
 filesystem content.
    The –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:
    • directory
    • tar
    • tgz
    The default format is directory.
    See Also
    • ocm download — Download oci artifacts, resources or complete components
    Prev
    artifacts
    Next
    artifacts
    \ No newline at end of file +archive does not exist yet. The following formats are supported:

    • directory
    • tar
    • tgz

    The default format is directory.

    See Also

    • ocm download — Download oci artifacts, resources or complete components
    Prev
    artifacts
    Next
    artifacts
    \ No newline at end of file diff --git a/docs/cli-reference/download/cli/index.html b/docs/cli-reference/download/cli/index.html index 0d5b9154..d257bf80 100644 --- a/docs/cli-reference/download/cli/index.html +++ b/docs/cli-reference/download/cli/index.html @@ -1,10 +1,10 @@ cli | Open Component Model -
    +
    -
    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
@@ -31,4 +31,4 @@
 signed or verified component versions are verified against their digests
 provided by the component version.(not supported for using downloaders for the
 resource download).
    The usage of the verification store is enabled by –use-verified or by
-specifying a verification file with –verified.
    See Also
    • ocm download — Download oci artifacts, resources or complete components
    Prev
    cache
    Next
    commontransportarchive
    \ No newline at end of file +specifying a verification file with –verified.

    See Also

    • ocm download — Download oci artifacts, resources or complete components
    Prev
    cache
    Next
    commontransportarchive
    \ No newline at end of file diff --git a/docs/cli-reference/download/componentversions/index.html b/docs/cli-reference/download/componentversions/index.html index 0763af51..f2afeef7 100644 --- a/docs/cli-reference/download/componentversions/index.html +++ b/docs/cli-reference/download/componentversions/index.html @@ -1,10 +1,10 @@ componentversions | Open Component Model -
    +
    -
    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 @@ -15,4 +15,4 @@ tar or tgz is possible.

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

    Dedicated OCM repository types:

    • ComponentArchive: v1

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

    • CommonTransportFormat: v1
    • OCIRegistry: v1
    • oci: v1
    • ociRegistry

    The –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:

    • directory
    • tar
    • tgz

    The default format is directory.

    See Also

    • ocm download — Download oci artifacts, resources or complete components
    Prev
    componentversions
    Next
    componentversions
    \ No newline at end of file +archive does not exist yet. The following formats are supported:

    • directory
    • tar
    • tgz

    The default format is directory.

    See Also

    • ocm download — Download oci artifacts, resources or complete components
    Prev
    componentversions
    Next
    componentversions
    \ No newline at end of file diff --git a/docs/cli-reference/download/index.html b/docs/cli-reference/download/index.html index 466cf882..2491c7a4 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/index.xml b/docs/cli-reference/download/index.xml index 35f955e4..38576270 100644 --- a/docs/cli-reference/download/index.xml +++ b/docs/cli-reference/download/index.xml @@ -1 +1 @@ -download on Open Component Modelhttps://ocm.software/docs/cli-reference/download/Recent content in download on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsWed, 17 Apr 2024 18:02:57 +0200artifactshttps://ocm.software/docs/cli-reference/download/artifacts/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/download/artifacts/Usage ocm download artifacts [&lt;options&gt;] {&lt;artifact&gt;} 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 &#34;directory&#34;) Description Download artifacts from an OCI registry.clihttps://ocm.software/docs/cli-reference/download/cli/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/download/cli/Usage ocm download cli [&lt;options&gt;] [&lt;component&gt; {&lt;name&gt; { &lt;key&gt;=&lt;value&gt; }}] Options -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 &#34;~/.componentversionshttps://ocm.software/docs/cli-reference/download/componentversions/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/download/componentversions/Usage ocm download componentversions [&lt;options&gt;] {&lt;components&gt;} 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 &#34;directory&#34;) Description Download component versions from an OCM repository.resourceshttps://ocm.software/docs/cli-reference/download/resources/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/download/resources/Usage ocm download resources [&lt;options&gt;] &lt;component&gt; {&lt;name&gt; { &lt;key&gt;=&lt;value&gt; }} Options --check-verified enable verification store -c, --constraints constraints version constraint -d, --download-handlers use download handler if possible --downloader &lt;name&gt;=&lt;value&gt; artifact downloader (&lt;name&gt;[:&lt;artifact type&gt;[:&lt;media type&gt;]]=&lt;JSON target config) (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 &#34;~/. \ No newline at end of file +download on Open Component Modelhttps://ocm.software/docs/cli-reference/download/Recent content in download on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model Contributorsartifactshttps://ocm.software/docs/cli-reference/download/artifacts/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/download/artifacts/Usage ocm download artifacts [&lt;options&gt;] {&lt;artifact&gt;} 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 &#34;directory&#34;) Description Download artifacts from an OCI registry.clihttps://ocm.software/docs/cli-reference/download/cli/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/download/cli/Usage ocm download cli [&lt;options&gt;] [&lt;component&gt; {&lt;name&gt; { &lt;key&gt;=&lt;value&gt; }}] Options -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 &#34;~/.componentversionshttps://ocm.software/docs/cli-reference/download/componentversions/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/download/componentversions/Usage ocm download componentversions [&lt;options&gt;] {&lt;components&gt;} 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 &#34;directory&#34;) Description Download component versions from an OCM repository.resourceshttps://ocm.software/docs/cli-reference/download/resources/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/download/resources/Usage ocm download resources [&lt;options&gt;] &lt;component&gt; {&lt;name&gt; { &lt;key&gt;=&lt;value&gt; }} Options --check-verified enable verification store -c, --constraints constraints version constraint -d, --download-handlers use download handler if possible --downloader &lt;name&gt;=&lt;value&gt; artifact downloader (&lt;name&gt;[:&lt;artifact type&gt;[:&lt;media type&gt;]]=&lt;JSON target config) (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 &#34;~/. \ 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 e91f08c9..6d8be1a4 100644 --- a/docs/cli-reference/download/resources/index.html +++ b/docs/cli-reference/download/resources/index.html @@ -1,10 +1,10 @@ resources | Open Component Model -
    +
    -
    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>]]=<JSON target config) (default [])
@@ -54,7 +54,7 @@
 by the resource’s access specification.
    If the config is given, the target is used as repository name prefixed with an
 optional repository prefix given by the configuration.
    The following artifact media types are supported:
    • application/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:
    • ociConfigTypes: 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
    See ocm ocm-downloadhandlers for further details on using
+landscaper.gardener.cloud/blueprint,blueprint
    See ocm ocm-downloadhandlers for further details on using
 download handlers.
    The library supports some downloads with semantics based on resource types. For example a helm chart
 can be download directly as helm chart archive, even if stored as OCI artifact.
 This is handled by download handler. Their usage can be enabled with the –download-handlers
@@ -69,4 +69,4 @@
 signed or verified component versions are verified against their digests
 provided by the component version.(not supported for using downloaders for the
 resource download).
    The usage of the verification store is enabled by –check-verified or by
-specifying a verification file with –verified.
    See Also
    • ocm download — Download oci artifacts, resources or complete components
    Prev
    resources
    Next
    resources
    \ No newline at end of file +specifying a verification file with –verified.

    See Also

    • ocm download — Download oci artifacts, resources or complete components
    Prev
    resources
    Next
    resources
    \ No newline at end of file diff --git a/docs/cli-reference/download/sitemap.xml b/docs/cli-reference/download/sitemap.xml index bb4c25b8..7adced8a 100644 --- a/docs/cli-reference/download/sitemap.xml +++ b/docs/cli-reference/download/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/cli-reference/download/artifacts/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/download/cli/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/download/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/download/resources/2024-04-17T18:02:57+02:00monthly0.5 \ No newline at end of file +https://ocm.software/docs/cli-reference/download/artifacts/monthly0.5https://ocm.software/docs/cli-reference/download/cli/monthly0.5https://ocm.software/docs/cli-reference/download/componentversions/monthly0.5https://ocm.software/docs/cli-reference/download/resources/monthly0.5 \ No newline at end of file diff --git a/docs/cli-reference/get/artifacts/index.html b/docs/cli-reference/get/artifacts/index.html index 00988bb7..ce287075 100644 --- a/docs/cli-reference/get/artifacts/index.html +++ b/docs/cli-reference/get/artifacts/index.html @@ -1,10 +1,10 @@ artifacts | Open Component Model -
    +
    -
    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
@@ -17,4 +17,4 @@
 linked library can be used:
    • ArtifactSet: v1
    • CommonTransportFormat: v1
    • DockerDaemon: v1
    • Empty: v1
    • OCIRegistry: v1
    • oci: v1
    • ociRegistry
    With the option –recursive the complete reference tree of a index is traversed.
    With the option –output the output mode can be selected.
 The following modes are supported:
    •  (default)
    • JSON
    • json
    • tree
    • wide
    • yaml
    Examples
    
 $ ocm get artifact ghcr.io/mandelsoft/kubelink
-$ ocm get artifact --repo OCIRegistry::ghcr.io mandelsoft/kubelink
    See Also
    • ocm get — Get information about artifacts and components
    Prev
    artifacts
    Next
    artifacts
    \ No newline at end of file +$ ocm get artifact --repo OCIRegistry::ghcr.io mandelsoft/kubelink

    See Also

    • ocm get — Get information about artifacts and components
    Prev
    artifacts
    Next
    artifacts
    \ No newline at end of file diff --git a/docs/cli-reference/get/componentversions/index.html b/docs/cli-reference/get/componentversions/index.html index fc701f10..18768aad 100644 --- a/docs/cli-reference/get/componentversions/index.html +++ b/docs/cli-reference/get/componentversions/index.html @@ -1,10 +1,10 @@ componentversions | Open Component Model -
    +
    -
    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
@@ -37,4 +37,4 @@
 The following schema versions are supported for explicit conversions:
    • ocm.software/v3alpha1
    • v2
    With the option –output the output mode can be selected.
 The following modes are supported:
    •  (default)
    • JSON
    • json
    • tree
    • wide
    • yaml
    Examples
    
 $ ocm get componentversion ghcr.io/mandelsoft/kubelink
-$ ocm get componentversion --repo OCIRegistry::ghcr.io mandelsoft/kubelink
    See Also
    • ocm get — Get information about artifacts and components
    Prev
    componentversions
    Next
    componentversions
    \ No newline at end of file +$ ocm get componentversion --repo OCIRegistry::ghcr.io mandelsoft/kubelink

    See Also

    • ocm get — Get information about artifacts and components
    Prev
    componentversions
    Next
    componentversions
    \ No newline at end of file diff --git a/docs/cli-reference/get/config/index.html b/docs/cli-reference/get/config/index.html index 6cdcb623..2139cde4 100644 --- a/docs/cli-reference/get/config/index.html +++ b/docs/cli-reference/get/config/index.html @@ -1,12 +1,12 @@ config | Open Component Model -
    +
    -
    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 a single configuration object.

    With the option –output the output mode can be selected. -The following modes are supported:

    • (default)
    • JSON
    • json
    • yaml

    See Also

    • ocm get — Get information about artifacts and components
    Prev
    componentversions
    Next
    configfile
    \ No newline at end of file +The following modes are supported:

    • (default)
    • JSON
    • json
    • yaml

    See Also

    • ocm get — Get information about artifacts and components
    Prev
    componentversions
    Next
    configfile
    \ No newline at end of file diff --git a/docs/cli-reference/get/credentials/index.html b/docs/cli-reference/get/credentials/index.html index cb318103..4cd6ff4f 100644 --- a/docs/cli-reference/get/credentials/index.html +++ b/docs/cli-reference/get/credentials/index.html @@ -1,10 +1,10 @@ credentials | Open Component Model -
    +
    -
    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:

    • Buildcredentials.ocm.software: Gardener config credential matcher

      It matches the Buildcredentials.ocm.software consumer type and additionally acts like @@ -18,4 +18,4 @@ the hostpath type.

      Credential consumers of the consumer type wget evaluate the following credential properties:

      • username: 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:

    • exact: exact match of given pattern set

    • hostpath: Host and path based credential matcher

      This matcher works on the following properties:

      • type (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

    The 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 –matcher.

    See Also

    • ocm get — Get information about artifacts and components
    Prev
    credential-handling
    Next
    hash
    \ No newline at end of file +The usage of a dedicated matcher can be enforced by the option –matcher.

    See Also

    • ocm get — Get information about artifacts and components
    Prev
    credential-handling
    Next
    hash
    \ No newline at end of file diff --git a/docs/cli-reference/get/index.html b/docs/cli-reference/get/index.html index 3ecb165a..0416c7c6 100644 --- a/docs/cli-reference/get/index.html +++ b/docs/cli-reference/get/index.html @@ -3,5 +3,5 @@ -
    Docs

    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/index.xml b/docs/cli-reference/get/index.xml index 0d74265d..84d3e885 100644 --- a/docs/cli-reference/get/index.xml +++ b/docs/cli-reference/get/index.xml @@ -1 +1 @@ -get on Open Component Modelhttps://ocm.software/docs/cli-reference/get/Recent content in get on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsWed, 17 Apr 2024 18:02:57 +0200artifactshttps://ocm.software/docs/cli-reference/get/artifacts/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/get/artifacts/Usage ocm get artifacts [&lt;options&gt;] {&lt;artifact-reference&gt;} 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 --repo string repository name or spec -s, --sort stringArray sort fields Description Get lists all artifact versions specified, if only a repository is specified all tagged artifacts are listed.componentversionshttps://ocm.software/docs/cli-reference/get/componentversions/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/get/componentversions/Usage ocm get componentversions [&lt;options&gt;] {&lt;component-reference&gt;} 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 -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 Description Get lists all component versions specified, if only a component is specified all versions are listed.confighttps://ocm.software/docs/cli-reference/get/config/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/get/config/Usage ocm get config &lt;options&gt; 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 a single configuration object.credentialshttps://ocm.software/docs/cli-reference/get/credentials/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/get/credentials/Usage ocm get credentials {&lt;consumer property&gt;=&lt;value&gt;} 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.pluginshttps://ocm.software/docs/cli-reference/get/plugins/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/get/plugins/Usage ocm get plugins [&lt;options&gt;] {&lt;plugin name&gt;} 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.pubsubhttps://ocm.software/docs/cli-reference/get/pubsub/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/get/pubsub/Usage ocm get pubsub {&lt;ocm repository&gt;} 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.referenceshttps://ocm.software/docs/cli-reference/get/references/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/get/references/Usage ocm get references [&lt;options&gt;] &lt;component&gt; {&lt;name&gt; { &lt;key&gt;=&lt;value&gt; }} 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 -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 Description Get references of a component version.resourceshttps://ocm.software/docs/cli-reference/get/resources/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/get/resources/Usage ocm get resources [&lt;options&gt;] &lt;component&gt; {&lt;name&gt; { &lt;key&gt;=&lt;value&gt; }} 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 -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 Description Get resources of a component version.routingslipshttps://ocm.software/docs/cli-reference/get/routingslips/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/get/routingslips/Usage ocm get routingslips [&lt;options&gt;] &lt;component&gt; {&lt;name&gt;} Options --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 Description Get all or the selected routing slips for a component version specification.sourceshttps://ocm.software/docs/cli-reference/get/sources/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/get/sources/Usage ocm get sources [&lt;options&gt;] &lt;component&gt; {&lt;name&gt; { &lt;key&gt;=&lt;value&gt; }} 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 -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 Description Get sources of a component version. \ No newline at end of file +get on Open Component Modelhttps://ocm.software/docs/cli-reference/get/Recent content in get on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model Contributorsartifactshttps://ocm.software/docs/cli-reference/get/artifacts/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/get/artifacts/Usage ocm get artifacts [&lt;options&gt;] {&lt;artifact-reference&gt;} 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 --repo string repository name or spec -s, --sort stringArray sort fields Description Get lists all artifact versions specified, if only a repository is specified all tagged artifacts are listed.componentversionshttps://ocm.software/docs/cli-reference/get/componentversions/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/get/componentversions/Usage ocm get componentversions [&lt;options&gt;] {&lt;component-reference&gt;} 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 -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 Description Get lists all component versions specified, if only a component is specified all versions are listed.confighttps://ocm.software/docs/cli-reference/get/config/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/get/config/Usage ocm get config &lt;options&gt; 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 a single configuration object.credentialshttps://ocm.software/docs/cli-reference/get/credentials/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/get/credentials/Usage ocm get credentials {&lt;consumer property&gt;=&lt;value&gt;} 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.pluginshttps://ocm.software/docs/cli-reference/get/plugins/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/get/plugins/Usage ocm get plugins [&lt;options&gt;] {&lt;plugin name&gt;} 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.pubsubhttps://ocm.software/docs/cli-reference/get/pubsub/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/get/pubsub/Usage ocm get pubsub {&lt;ocm repository&gt;} 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.referenceshttps://ocm.software/docs/cli-reference/get/references/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/get/references/Usage ocm get references [&lt;options&gt;] &lt;component&gt; {&lt;name&gt; { &lt;key&gt;=&lt;value&gt; }} 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 -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 Description Get references of a component version.resourceshttps://ocm.software/docs/cli-reference/get/resources/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/get/resources/Usage ocm get resources [&lt;options&gt;] &lt;component&gt; {&lt;name&gt; { &lt;key&gt;=&lt;value&gt; }} 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 -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 Description Get resources of a component version.routingslipshttps://ocm.software/docs/cli-reference/get/routingslips/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/get/routingslips/Usage ocm get routingslips [&lt;options&gt;] &lt;component&gt; {&lt;name&gt;} Options --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 Description Get all or the selected routing slips for a component version specification.sourceshttps://ocm.software/docs/cli-reference/get/sources/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/get/sources/Usage ocm get sources [&lt;options&gt;] &lt;component&gt; {&lt;name&gt; { &lt;key&gt;=&lt;value&gt; }} 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 -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 Description Get sources of a component version. \ 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 5c86d4ca..ad292ca2 100644 --- a/docs/cli-reference/get/plugins/index.html +++ b/docs/cli-reference/get/plugins/index.html @@ -1,13 +1,13 @@ plugins | Open Component Model -
    +
    -
    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. The following modes are supported:

    • (default)
    • JSON
    • json
    • wide
    • yaml

    Examples

    
 $ ocm get plugins
-$ ocm get plugins demo -o yaml

    See Also

    • ocm get — Get information about artifacts and components
    Prev
    plugins
    Next
    pubsub
    \ No newline at end of file +$ ocm get plugins demo -o yaml

    See Also

    • ocm get — Get information about artifacts and components
    Prev
    plugins
    Next
    pubsub
    \ No newline at end of file diff --git a/docs/cli-reference/get/pubsub/index.html b/docs/cli-reference/get/pubsub/index.html index f73d4e86..bc597b88 100644 --- a/docs/cli-reference/get/pubsub/index.html +++ b/docs/cli-reference/get/pubsub/index.html @@ -1,14 +1,14 @@ pubsub | Open Component Model -
    +
    -
    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. 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.

    With the option –output the output mode can be selected. -The following modes are supported:

    • (default)
    • JSON
    • json
    • yaml

    See Also

    • ocm get — Get information about artifacts and components
    Prev
    plugins
    Next
    pubsub
    \ No newline at end of file +can be set with the ocm set pubsub.

    With the option –output the output mode can be selected. +The following modes are supported:

    • (default)
    • JSON
    • json
    • yaml

    See Also

    • ocm get — Get information about artifacts and components
    Prev
    plugins
    Next
    pubsub
    \ No newline at end of file diff --git a/docs/cli-reference/get/references/index.html b/docs/cli-reference/get/references/index.html index c09ed24b..431c3871 100644 --- a/docs/cli-reference/get/references/index.html +++ b/docs/cli-reference/get/references/index.html @@ -1,10 +1,10 @@ references | Open Component Model -
    +
    -
    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
@@ -31,4 +31,4 @@
 it only contains a single component version. Therefore, in this scenario
 this option must always be specified to be able to follow component
 references.
    With the option –output the output mode can be selected.
-The following modes are supported:
    •  (default)
    • JSON
    • json
    • tree
    • wide
    • yaml
    See Also
    • ocm get — Get information about artifacts and components
    Prev
    references
    Next
    resource-configuration
    \ No newline at end of file +The following modes are supported:

    • (default)
    • JSON
    • json
    • tree
    • wide
    • yaml

    See Also

    • ocm get — Get information about artifacts and components
    Prev
    references
    Next
    resource-configuration
    \ No newline at end of file diff --git a/docs/cli-reference/get/resources/index.html b/docs/cli-reference/get/resources/index.html index 30b4c50e..5b56497a 100644 --- a/docs/cli-reference/get/resources/index.html +++ b/docs/cli-reference/get/resources/index.html @@ -1,10 +1,10 @@ resources | Open Component Model -
    +
    -
    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
@@ -31,4 +31,4 @@
 it only contains a single component version. Therefore, in this scenario
 this option must always be specified to be able to follow component
 references.
    With the option –output the output mode can be selected.
-The following modes are supported:
    •  (default)
    • JSON
    • json
    • tree
    • treewide
    • wide
    • yaml
    See Also
    • ocm get — Get information about artifacts and components
    Prev
    resources
    Next
    routingslips
    \ No newline at end of file +The following modes are supported:

    • (default)
    • JSON
    • json
    • tree
    • treewide
    • wide
    • yaml

    See Also

    • ocm get — Get information about artifacts and components
    Prev
    resources
    Next
    routingslips
    \ No newline at end of file diff --git a/docs/cli-reference/get/routingslips/index.html b/docs/cli-reference/get/routingslips/index.html index ed618154..6b0dfe03 100644 --- a/docs/cli-reference/get/routingslips/index.html +++ b/docs/cli-reference/get/routingslips/index.html @@ -1,10 +1,10 @@ routingslips | Open Component Model -
    +
    -
    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
@@ -30,4 +30,4 @@
 it only contains a single component version. Therefore, in this scenario
 this option must always be specified to be able to follow component
 references.
    With the option –output the output mode can be selected.
-The following modes are supported:
    •  (default)
    • JSON
    • json
    • wide
    • yaml
    See Also
    • ocm get — Get information about artifacts and components
    Prev
    routingslips
    Next
    rsakeypair
    \ No newline at end of file +The following modes are supported:

    • (default)
    • JSON
    • json
    • wide
    • yaml

    See Also

    • ocm get — Get information about artifacts and components
    Prev
    routingslips
    Next
    rsakeypair
    \ No newline at end of file diff --git a/docs/cli-reference/get/sitemap.xml b/docs/cli-reference/get/sitemap.xml index c7d6a9e7..37088343 100644 --- a/docs/cli-reference/get/sitemap.xml +++ b/docs/cli-reference/get/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/cli-reference/get/artifacts/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/config/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/credentials/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/plugins/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/pubsub/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/references/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/resources/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/routingslips/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/sources/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/verified/2024-04-17T18:02:57+02:00monthly0.5 \ No newline at end of file +https://ocm.software/docs/cli-reference/get/artifacts/monthly0.5https://ocm.software/docs/cli-reference/get/componentversions/monthly0.5https://ocm.software/docs/cli-reference/get/config/monthly0.5https://ocm.software/docs/cli-reference/get/credentials/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/get/references/monthly0.5https://ocm.software/docs/cli-reference/get/resources/monthly0.5https://ocm.software/docs/cli-reference/get/routingslips/monthly0.5https://ocm.software/docs/cli-reference/get/sources/monthly0.5https://ocm.software/docs/cli-reference/get/verified/monthly0.5 \ No newline at end of file diff --git a/docs/cli-reference/get/sources/index.html b/docs/cli-reference/get/sources/index.html index 84e2704c..89361eda 100644 --- a/docs/cli-reference/get/sources/index.html +++ b/docs/cli-reference/get/sources/index.html @@ -1,10 +1,10 @@ sources | Open Component Model -
    +
    -
    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
@@ -31,4 +31,4 @@
 it only contains a single component version. Therefore, in this scenario
 this option must always be specified to be able to follow component
 references.
    With the option –output the output mode can be selected.
-The following modes are supported:
    •  (default)
    • JSON
    • json
    • tree
    • wide
    • yaml
    See Also
    • ocm get — Get information about artifacts and components
    Prev
    sources
    Next
    tags
    \ No newline at end of file +The following modes are supported:

    • (default)
    • JSON
    • json
    • tree
    • wide
    • yaml

    See Also

    • ocm get — Get information about artifacts and components
    Prev
    sources
    Next
    tags
    \ No newline at end of file diff --git a/docs/cli-reference/get/verified/index.html b/docs/cli-reference/get/verified/index.html index 6b725953..844e1e39 100644 --- a/docs/cli-reference/get/verified/index.html +++ b/docs/cli-reference/get/verified/index.html @@ -1,13 +1,13 @@ verified | Open Component Model -
    +
    -
    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. The following modes are supported:

    • (default)
    • JSON
    • json
    • wide
    • yaml

    Examples

    
 $ ocm get verified
-$ ocm get verified -f verified.yaml acme.org/component -o yaml

    See Also

    • ocm get — Get information about artifacts and components
    Prev
    transportarchive
    Next
    versions
    \ No newline at end of file +$ ocm get verified -f verified.yaml acme.org/component -o yaml

    See Also

    • ocm get — Get information about artifacts and components
    Prev
    transportarchive
    Next
    versions
    \ No newline at end of file diff --git a/docs/cli-reference/help/attributes/index.html b/docs/cli-reference/help/attributes/index.html index e9e73a39..5039cb8e 100644 --- a/docs/cli-reference/help/attributes/index.html +++ b/docs/cli-reference/help/attributes/index.html @@ -1,13 +1,13 @@ attributes | Open Component Model -
    +
    -
    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 +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 OCM library:

    See ocm ocm-downloadhandlers for further details on using download handlers.

    See Also

    Prev
    ocm-accessmethods
    Next
    ocm-labels
    \ No newline at end of file diff --git a/docs/cli-reference/help/ocm-labels/index.html b/docs/cli-reference/help/ocm-labels/index.html index d3ea74da..e82edfe7 100644 --- a/docs/cli-reference/help/ocm-labels/index.html +++ b/docs/cli-reference/help/ocm-labels/index.html @@ -1,12 +1,12 @@ ocm-labels | Open Component Model
    -
    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:

    ExecutorSpecification

    The executor specification describes the available actions and their mapping +a special meaning:

    • configFile: an example template for a parameter file
    • credentialsFile: an example template for a credentials file

    Those templates can be downloaded with ocm bootstrap configuration.

    ExecutorSpecification

    The executor specification describes the available actions and their mapping to executors. It uses the following fields:

    • actions []string

      The 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

    • resourceRef []ResourceReference

      An OCM resource reference describing a component version resource relative to @@ -128,7 +128,7 @@ This is done with the credentials field. It is a map of credentials names and their meaning and/or handling.

      It uses the following fields:

      • description string

        This field should describe the purpose of the credential.

      • properties map[string]string

        This field should describe the used credential fields

      • consumerId map[string]

        This 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.

      Credentials are provided in an ocm config file (see ocm configfile). +type and one additional field must be set.

    Credentials 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.

    Executor Image Contract

    The executor image is called with the action as additional argument. It is diff --git a/docs/cli-reference/index.html b/docs/cli-reference/index.html index 168387e4..e27e77d5 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
@@ -23,7 +23,7 @@
 artifacts, like Component Archives, Common Transport Archive,
 Component Repositories, and Component Versions.
    Additionally it provides some limited support for the docker daemon, OCI artifacts and
 registries.
    It can be used in two ways:
    • verb/operation first: here the sub commands follow the pattern <verb> <object kind> <arguments>
    • area/kind first: here the area and/or object kind is given first followed by the operation according to the pattern
-[<area>] <object kind> <verb/operation> <arguments>
    The command accepts some top level options, they can only be given before the sub commands.
    A configuration according to ocm configfile is read from a .ocmconfig file
+[<area>] <object kind> <verb/operation> <arguments>
    The command accepts some top level options, they can only be given before the sub commands.
    A configuration according to ocm configfile is read from a .ocmconfig file
 located in the HOME directory. With the option –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
@@ -41,7 +41,7 @@
 is started.
    The first credential setting may omit identity attributes. In this case it is used as
 default credential, always used if no dedicated match is found.
    For example:
    --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
    -X <attribute>=<value>
    The –log* options can be used to configure the logging behaviour.
-For details see ocm logging.
    There is a quick config option –logkeys to configure simple
+For details see ocm logging.
    There is a quick config option –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
@@ -49,7 +49,7 @@
 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.
    A 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.
+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.
@@ -57,7 +57,7 @@
 The –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.
    The value can be a simple type or a JSON/YAML string for complex values
-(see ocm attributes). The following attributes are supported:
    • github.com/mandelsoft/logforward [logfwd]: logconfig Logging config structure used for config forwarding
      This attribute is used to specify a logging configuration intended
+(see ocm attributes). The following attributes are supported:
      • github.com/mandelsoft/logforward [logfwd]: logconfig Logging config structure used for config forwarding
        This attribute is used to specify a logging configuration intended
 to be forwarded to other tools.
 (For example: TOI passes this config to the executor)
      • github.com/mandelsoft/oci/cache [cache]: string
        Filesystem folder to use for caching OCI blobs
      • github.com/mandelsoft/ocm/compat [compat]: bool
        Compatibility mode: Avoid generic local access methods and prefer type specific ones.
      • github.com/mandelsoft/ocm/hasher: JSON
        Preferred hash algorithm to calculate resource digests. The following
 digesters are supported:
        • NO-DIGEST
        • SHA-256 (default)
        • SHA-512
      • github.com/mandelsoft/ocm/keeplocalblob [keeplocalblob]: bool
        Keep local blobs when importing OCI artifacts to OCI registries from localBlob
@@ -162,4 +162,4 @@
 derived from the signature name. If it is not a formal distinguished name,
 it is assumed to be a plain common name.
        With –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.
        See Also
        Sub Commands
        • ocm add — Add elements to a component repository or component version
        • ocm check — check components in OCM repository
        • ocm clean — Cleanup/re-organize elements
        • ocm create — Create transport or component archive
        • ocm describe — Describe various elements by using appropriate sub commands.
        • ocm download — Download oci artifacts, resources or complete components
        • ocm get — Get information about artifacts and components
        • ocm list — List information about components
        • ocm set — Set information about OCM repositories
        • ocm show — Show tags or versions
        • ocm sign — Sign components or hashes
        • ocm transfer — Transfer artifacts or components
        • ocm verify — Verify component version signatures
        Additional Help Topics
    \ No newline at end of file +by a certificate delivered with the signature.

    See Also

    Sub Commands
    • ocm add — Add elements to a component repository or component version
    • ocm check — check components in OCM repository
    • ocm clean — Cleanup/re-organize elements
    • ocm create — Create transport or component archive
    • ocm describe — Describe various elements by using appropriate sub commands.
    • ocm download — Download oci artifacts, resources or complete components
    • ocm get — Get information about artifacts and components
    • ocm list — List information about components
    • ocm set — Set information about OCM repositories
    • ocm show — Show tags or versions
    • ocm sign — Sign components or hashes
    • ocm transfer — Transfer artifacts or components
    • ocm verify — Verify component version signatures
    Additional Help Topics
    \ No newline at end of file diff --git a/docs/cli-reference/index.xml b/docs/cli-reference/index.xml index 6fdcdfcf..db9b8f8b 100644 --- a/docs/cli-reference/index.xml +++ b/docs/cli-reference/index.xml @@ -1 +1 @@ -cli-reference on Open Component Modelhttps://ocm.software/docs/cli-reference/Recent content in cli-reference on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model Contributors \ No newline at end of file +cli-reference on Open Component Modelhttps://ocm.software/docs/cli-reference/Recent content in cli-reference on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model Contributors \ No newline at end of file diff --git a/docs/cli-reference/list/componentversions/index.html b/docs/cli-reference/list/componentversions/index.html index 35c607d7..4910a48a 100644 --- a/docs/cli-reference/list/componentversions/index.html +++ b/docs/cli-reference/list/componentversions/index.html @@ -1,10 +1,10 @@ componentversions | Open Component Model -
    +
    -
    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
@@ -36,4 +36,4 @@
 The following schema versions are supported for explicit conversions:
    • ocm.software/v3alpha1
    • v2
    With the option –output the output mode can be selected.
 The following modes are supported:
    •  (default)
    • JSON
    • json
    • yaml
    Examples
    
 $ ocm list componentversion ghcr.io/mandelsoft/kubelink
-$ ocm list componentversion --repo OCIRegistry::ghcr.io mandelsoft/kubelink
    See Also
    • ocm list — List information about components
    Prev
    componentversions
    Next
    componentversions
    \ No newline at end of file +$ ocm list componentversion --repo OCIRegistry::ghcr.io mandelsoft/kubelink

    See Also

    • ocm list — List information about components
    Prev
    componentversions
    Next
    componentversions
    \ No newline at end of file diff --git a/docs/cli-reference/list/index.html b/docs/cli-reference/list/index.html index 8a4c37ef..d43d5502 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/list/index.xml b/docs/cli-reference/list/index.xml index 069c3637..23e8a055 100644 --- a/docs/cli-reference/list/index.xml +++ b/docs/cli-reference/list/index.xml @@ -1 +1 @@ -list on Open Component Modelhttps://ocm.software/docs/cli-reference/list/Recent content in list on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsWed, 17 Apr 2024 18:02:57 +0200componentversionshttps://ocm.software/docs/cli-reference/list/componentversions/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/list/componentversions/Usage ocm list componentversions [&lt;options&gt;] {&lt;component-reference&gt;} 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 -o, --output string output mode (JSON, json, yaml) --repo string repository name or spec -S, --scheme string schema version -s, --sort stringArray sort fields Description 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. \ No newline at end of file +list on Open Component Modelhttps://ocm.software/docs/cli-reference/list/Recent content in list on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model Contributorscomponentversionshttps://ocm.software/docs/cli-reference/list/componentversions/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/list/componentversions/Usage ocm list componentversions [&lt;options&gt;] {&lt;component-reference&gt;} 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 -o, --output string output mode (JSON, json, yaml) --repo string repository name or spec -S, --scheme string schema version -s, --sort stringArray sort fields Description 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. \ No newline at end of file diff --git a/docs/cli-reference/list/sitemap.xml b/docs/cli-reference/list/sitemap.xml index ea4d7dad..9cca0132 100644 --- a/docs/cli-reference/list/sitemap.xml +++ b/docs/cli-reference/list/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/cli-reference/list/componentversions/2024-04-17T18:02:57+02:00monthly0.5 \ No newline at end of file +https://ocm.software/docs/cli-reference/list/componentversions/monthly0.5 \ No newline at end of file diff --git a/docs/cli-reference/set/index.html b/docs/cli-reference/set/index.html index 2831cd20..215c3c3d 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/index.xml b/docs/cli-reference/set/index.xml index 5a08e8f6..e47bca85 100644 --- a/docs/cli-reference/set/index.xml +++ b/docs/cli-reference/set/index.xml @@ -1 +1 @@ -set on Open Component Modelhttps://ocm.software/docs/cli-reference/set/Recent content in set on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsWed, 17 Apr 2024 18:02:57 +0200pubsubhttps://ocm.software/docs/cli-reference/set/pubsub/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/set/pubsub/Usage ocm set pubsub {&lt;ocm repository&gt;} [&lt;pub/sub specification&gt;] 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. \ No newline at end of file +set on Open Component Modelhttps://ocm.software/docs/cli-reference/set/Recent content in set on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model Contributorspubsubhttps://ocm.software/docs/cli-reference/set/pubsub/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/set/pubsub/Usage ocm set pubsub {&lt;ocm repository&gt;} [&lt;pub/sub specification&gt;] 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. \ 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 7a41a86b..61bf858f 100644 --- a/docs/cli-reference/set/pubsub/index.html +++ b/docs/cli-reference/set/pubsub/index.html @@ -1,10 +1,10 @@ pubsub | Open Component Model -
    +
    -
    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 @@ -12,6 +12,6 @@ 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. +can be queried with the ocm get pubsub. Types and specification formats are shown for the topic -ocm ocm-pubsub.

    See Also

    • ocm set — Set information about OCM repositories
    Prev
    pubsub
    Next
    references
    \ No newline at end of file +ocm ocm-pubsub.

    See Also

    • ocm set — Set information about OCM repositories
    Prev
    pubsub
    Next
    references
    \ No newline at end of file diff --git a/docs/cli-reference/set/sitemap.xml b/docs/cli-reference/set/sitemap.xml index d16e59e3..5b4d6233 100644 --- a/docs/cli-reference/set/sitemap.xml +++ b/docs/cli-reference/set/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/cli-reference/set/pubsub/2024-04-17T18:02:57+02:00monthly0.5 \ No newline at end of file +https://ocm.software/docs/cli-reference/set/pubsub/monthly0.5 \ No newline at end of file diff --git a/docs/cli-reference/show/index.html b/docs/cli-reference/show/index.html index 9c08138e..6ac9b26e 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/index.xml b/docs/cli-reference/show/index.xml index e1eed44e..941d0823 100644 --- a/docs/cli-reference/show/index.xml +++ b/docs/cli-reference/show/index.xml @@ -1 +1 @@ -show on Open Component Modelhttps://ocm.software/docs/cli-reference/show/Recent content in show on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsWed, 17 Apr 2024 18:02:57 +0200tagshttps://ocm.software/docs/cli-reference/show/tags/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/show/tags/Usage ocm show tags [&lt;options&gt;] &lt;component&gt; {&lt;version pattern&gt;} Options -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 Description Match tags of an artifact against some patterns.versionshttps://ocm.software/docs/cli-reference/show/versions/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/show/versions/Usage ocm show versions [&lt;options&gt;] &lt;component&gt; {&lt;version pattern&gt;} 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. \ No newline at end of file +show on Open Component Modelhttps://ocm.software/docs/cli-reference/show/Recent content in show on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model Contributorstagshttps://ocm.software/docs/cli-reference/show/tags/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/show/tags/Usage ocm show tags [&lt;options&gt;] &lt;component&gt; {&lt;version pattern&gt;} Options -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 Description Match tags of an artifact against some patterns.versionshttps://ocm.software/docs/cli-reference/show/versions/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/show/versions/Usage ocm show versions [&lt;options&gt;] &lt;component&gt; {&lt;version pattern&gt;} 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. \ No newline at end of file diff --git a/docs/cli-reference/show/sitemap.xml b/docs/cli-reference/show/sitemap.xml index c2a04022..7d17f806 100644 --- a/docs/cli-reference/show/sitemap.xml +++ b/docs/cli-reference/show/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/cli-reference/show/tags/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/show/versions/2024-04-17T18:02:57+02:00monthly0.5 \ No newline at end of file +https://ocm.software/docs/cli-reference/show/tags/monthly0.5https://ocm.software/docs/cli-reference/show/versions/monthly0.5 \ 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 cd7af2c1..fafe28de 100644 --- a/docs/cli-reference/show/tags/index.html +++ b/docs/cli-reference/show/tags/index.html @@ -1,10 +1,10 @@ tags | Open Component Model -
    +
    -
    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
@@ -13,4 +13,4 @@
 as extended OCI artifact references.
    [<repo type>::]<host>[:<port>]/<OCI repository name>[:<tag>][@<digest>]
    The –repo option takes a repository/OCI registry specification:
    [<repo type>::]<configured name>|<file path>|<spec json>
    For the Common Transport Format the types directory,
 tar or tgz are possible.
    Using the JSON variant any repository types supported by the
 linked library can be used:
    • ArtifactSet: v1
    • CommonTransportFormat: v1
    • DockerDaemon: v1
    • Empty: v1
    • OCIRegistry: v1
    • oci: v1
    • ociRegistry
    Examples
    
-$ oci show tags ghcr.io/mandelsoft/kubelink
    See Also
    Prev
    sources
    Next
    toi-bootstrapping
    \ No newline at end of file +$ oci show tags ghcr.io/mandelsoft/kubelink

    See Also

    Prev
    sources
    Next
    toi-bootstrapping
    \ No newline at end of file diff --git a/docs/cli-reference/show/versions/index.html b/docs/cli-reference/show/versions/index.html index 14a8af7a..436fbeec 100644 --- a/docs/cli-reference/show/versions/index.html +++ b/docs/cli-reference/show/versions/index.html @@ -1,10 +1,10 @@ versions | Open Component Model -
    +
    -
    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 @@ -13,4 +13,4 @@ and general repository specifications

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

    The –repo option takes an OCM repository specification:

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

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

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

    Dedicated OCM repository types:

    • ComponentArchive: v1

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

    • CommonTransportFormat: v1
    • OCIRegistry: v1
    • oci: v1
    • ociRegistry

    Examples

    
-$ ocm show versions ghcr.io/mandelsoft/cnudie//github.com/mandelsoft/playground

    See Also

    Prev
    verified
    Next
    \ No newline at end of file +$ ocm show versions ghcr.io/mandelsoft/cnudie//github.com/mandelsoft/playground

    See Also

    Prev
    verified
    \ No newline at end of file diff --git a/docs/cli-reference/sign/componentversions/index.html b/docs/cli-reference/sign/componentversions/index.html index c1162112..1ac7d43c 100644 --- a/docs/cli-reference/sign/componentversions/index.html +++ b/docs/cli-reference/sign/componentversions/index.html @@ -1,10 +1,10 @@ componentversions | Open Component Model -
    +
    -
    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
@@ -51,4 +51,4 @@
 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.
    Examples
    $ ocm sign componentversion --signature mandelsoft --private-key=mandelsoft.key ghcr.io/mandelsoft/kubelink
    See Also
    Prev
    componentversions
    Next
    componentversions
    \ No newline at end of file +references.

    Examples

    $ ocm sign componentversion --signature mandelsoft --private-key=mandelsoft.key ghcr.io/mandelsoft/kubelink

    See Also

    Prev
    componentversions
    Next
    componentversions
    \ No newline at end of file diff --git a/docs/cli-reference/sign/hash/index.html b/docs/cli-reference/sign/hash/index.html index a3a589b2..f6d296e3 100644 --- a/docs/cli-reference/sign/hash/index.html +++ b/docs/cli-reference/sign/hash/index.html @@ -1,12 +1,12 @@ hash | Open Component Model -
    +
    -
    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
       --rootCerts string      root certificates file (deprecated)

    Description

    Print the signature for a dedicated digest value.

    Examples

    
-$ ocm sign hash key.priv SHA-256:810ff2fb242a5dee4220f2cb0e6a519891fb67f2f828a6cab4ef8894633b1f50

    See Also

    Prev
    credentials
    Next
    logging
    \ No newline at end of file +$ ocm sign hash key.priv SHA-256:810ff2fb242a5dee4220f2cb0e6a519891fb67f2f828a6cab4ef8894633b1f50

    See Also

    Prev
    credentials
    Next
    logging
    \ No newline at end of file diff --git a/docs/cli-reference/sign/index.html b/docs/cli-reference/sign/index.html index fc968b3e..e2789c4c 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/sign/index.xml b/docs/cli-reference/sign/index.xml index a56433ba..2a18ceec 100644 --- a/docs/cli-reference/sign/index.xml +++ b/docs/cli-reference/sign/index.xml @@ -1 +1 @@ -sign on Open Component Modelhttps://ocm.software/docs/cli-reference/sign/Recent content in sign on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsWed, 17 Apr 2024 18:02:57 +0200componentversionshttps://ocm.software/docs/cli-reference/sign/componentversions/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/sign/componentversions/Usage ocm sign componentversions [&lt;options&gt;] {&lt;component-reference&gt;} Options -- enable verification store -S, --algorithm string signature handler (default &#34;RSASSA-PKCS1-V1_5&#34;) --ca-cert stringArray additional root certificate authorities (for signing certificates) -c, --constraints constraints version constraint -H, --hash string hash algorithm (default &#34;SHA-256&#34;) -h, --help help for componentversions -I, --issuer stringArray issuer name or distinguished name (DN) (optionally for dedicated signature) ([&lt;name&gt;:=]&lt;dn&gt;) --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 &#34;jsonNormalisation/v1&#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.hashhttps://ocm.software/docs/cli-reference/sign/hash/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/sign/hash/Usage ocm sign hash &lt;private key file&gt; &lt;hash&gt; [&lt;issuer&gt;] Options -S, --algorithm string signature algorithm (default &#34;RSASSA-PKCS1-V1_5&#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) Description Print the signature for a dedicated digest value. \ No newline at end of file +sign on Open Component Modelhttps://ocm.software/docs/cli-reference/sign/Recent content in sign on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model Contributorscomponentversionshttps://ocm.software/docs/cli-reference/sign/componentversions/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/sign/componentversions/Usage ocm sign componentversions [&lt;options&gt;] {&lt;component-reference&gt;} Options -- enable verification store -S, --algorithm string signature handler (default &#34;RSASSA-PKCS1-V1_5&#34;) --ca-cert stringArray additional root certificate authorities (for signing certificates) -c, --constraints constraints version constraint -H, --hash string hash algorithm (default &#34;SHA-256&#34;) -h, --help help for componentversions -I, --issuer stringArray issuer name or distinguished name (DN) (optionally for dedicated signature) ([&lt;name&gt;:=]&lt;dn&gt;) --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 &#34;jsonNormalisation/v1&#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.hashhttps://ocm.software/docs/cli-reference/sign/hash/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/sign/hash/Usage ocm sign hash &lt;private key file&gt; &lt;hash&gt; [&lt;issuer&gt;] Options -S, --algorithm string signature algorithm (default &#34;RSASSA-PKCS1-V1_5&#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) Description Print the signature for a dedicated digest value. \ No newline at end of file diff --git a/docs/cli-reference/sign/sitemap.xml b/docs/cli-reference/sign/sitemap.xml index e2fc7242..a02c956f 100644 --- a/docs/cli-reference/sign/sitemap.xml +++ b/docs/cli-reference/sign/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/cli-reference/sign/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/sign/hash/2024-04-17T18:02:57+02:00monthly0.5 \ No newline at end of file +https://ocm.software/docs/cli-reference/sign/componentversions/monthly0.5https://ocm.software/docs/cli-reference/sign/hash/monthly0.5 \ No newline at end of file diff --git a/docs/cli-reference/sitemap.xml b/docs/cli-reference/sitemap.xml index a6cb54a8..312dce4d 100644 --- a/docs/cli-reference/sitemap.xml +++ b/docs/cli-reference/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/cli-reference/add/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/check/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/clean/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/create/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/describe/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/download/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/list/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/set/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/show/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/sign/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/transfer/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/verify/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/references/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/resource-configuration/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/resources/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/routingslips/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/source-configuration/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/sources/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/check/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/clean/cache/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/create/componentarchive/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/create/rsakeypair/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/create/transportarchive/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/describe/artifacts/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/describe/cache/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/describe/package/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/describe/plugins/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/download/artifacts/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/download/cli/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/download/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/download/resources/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/artifacts/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/config/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/credentials/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/plugins/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/pubsub/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/references/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/resources/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/routingslips/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/sources/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/verified/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/attributes/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/configfile/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/credential-handling/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/logging/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/oci-references/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/ocm-accessmethods/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/ocm-downloadhandlers/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/ocm-labels/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/ocm-pubsub/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/ocm-references/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/ocm-uploadhandlers/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/toi-bootstrapping/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/list/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/set/pubsub/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/show/tags/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/show/versions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/sign/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/sign/hash/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/transfer/artifacts/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/transfer/commontransportarchive/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/transfer/componentarchive/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/transfer/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/verify/componentversions/2024-04-17T18:02:57+02:00monthly0.5 \ No newline at end of file +https://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.5https://ocm.software/docs/cli-reference/add/componentversions/monthly0.5https://ocm.software/docs/cli-reference/add/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/add/routingslips/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/check/componentversions/monthly0.5https://ocm.software/docs/cli-reference/clean/cache/monthly0.5https://ocm.software/docs/cli-reference/create/componentarchive/monthly0.5https://ocm.software/docs/cli-reference/create/rsakeypair/monthly0.5https://ocm.software/docs/cli-reference/create/transportarchive/monthly0.5https://ocm.software/docs/cli-reference/describe/artifacts/monthly0.5https://ocm.software/docs/cli-reference/describe/cache/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/download/artifacts/monthly0.5https://ocm.software/docs/cli-reference/download/cli/monthly0.5https://ocm.software/docs/cli-reference/download/componentversions/monthly0.5https://ocm.software/docs/cli-reference/download/resources/monthly0.5https://ocm.software/docs/cli-reference/get/artifacts/monthly0.5https://ocm.software/docs/cli-reference/get/componentversions/monthly0.5https://ocm.software/docs/cli-reference/get/config/monthly0.5https://ocm.software/docs/cli-reference/get/credentials/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/get/references/monthly0.5https://ocm.software/docs/cli-reference/get/resources/monthly0.5https://ocm.software/docs/cli-reference/get/routingslips/monthly0.5https://ocm.software/docs/cli-reference/get/sources/monthly0.5https://ocm.software/docs/cli-reference/get/verified/monthly0.5https://ocm.software/docs/cli-reference/help/attributes/monthly0.5https://ocm.software/docs/cli-reference/help/configfile/monthly0.5https://ocm.software/docs/cli-reference/help/credential-handling/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/help/toi-bootstrapping/monthly0.5https://ocm.software/docs/cli-reference/list/componentversions/monthly0.5https://ocm.software/docs/cli-reference/set/pubsub/monthly0.5https://ocm.software/docs/cli-reference/show/tags/monthly0.5https://ocm.software/docs/cli-reference/show/versions/monthly0.5https://ocm.software/docs/cli-reference/sign/componentversions/monthly0.5https://ocm.software/docs/cli-reference/sign/hash/monthly0.5https://ocm.software/docs/cli-reference/transfer/artifacts/monthly0.5https://ocm.software/docs/cli-reference/transfer/commontransportarchive/monthly0.5https://ocm.software/docs/cli-reference/transfer/componentarchive/monthly0.5https://ocm.software/docs/cli-reference/transfer/componentversions/monthly0.5https://ocm.software/docs/cli-reference/verify/componentversions/monthly0.5 \ 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 78188370..6478c136 100644 --- a/docs/cli-reference/transfer/artifacts/index.html +++ b/docs/cli-reference/transfer/artifacts/index.html @@ -1,10 +1,10 @@ artifacts | Open Component Model -
    +
    -
    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. @@ -19,4 +19,4 @@ $ ocm oci artifact transfer ghcr.io/mandelsoft/kubelink:v1.0.0 gcr.io $ ocm oci artifact transfer ghcr.io/mandelsoft/kubelink gcr.io $ ocm oci artifact transfer ghcr.io/mandelsoft/kubelink gcr.io/my-project -$ ocm oci artifact transfer /tmp/ctf gcr.io/my-project

    See Also

    Prev
    artifacts
    Next
    attributes
    \ No newline at end of file +$ ocm oci artifact transfer /tmp/ctf gcr.io/my-project

    See Also

    Prev
    artifacts
    Next
    attributes
    \ No newline at end of file diff --git a/docs/cli-reference/transfer/commontransportarchive/index.html b/docs/cli-reference/transfer/commontransportarchive/index.html index 37097b3d..403f08f8 100644 --- a/docs/cli-reference/transfer/commontransportarchive/index.html +++ b/docs/cli-reference/transfer/commontransportarchive/index.html @@ -1,10 +1,10 @@ commontransportarchive | Open Component Model -
    +
    -
    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
@@ -60,7 +60,7 @@
 ‘url’: the URL of the maven repository.
  • plugin: [downloaders provided by plugins]
    sub namespace of the form <plugin name>/<handler>
  • ocm/ociArtifacts: downloading OCI artifacts
    The ociArtifacts downloader is able to download OCI artifacts
 as artifact archive according to the OCI distribution spec.
 The following artifact media types are supported:
    • application/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.
    It accepts a config with the following fields:
    • namespacePrefix: 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.
    • See ocm ocm-uploadhandlers for further details on using
+reference.
    See ocm ocm-uploadhandlers for further details on using
 upload handlers.
    It is possible to use a dedicated transfer script based on spiff.
 The option –scriptFile can be used to specify this script
 by a file name. With –script it can be taken from the
@@ -73,4 +73,4 @@
       <scriptdata>

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

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

    Examples

    
-$ ocm transfer ctf ctf.tgz ghcr.io/mandelsoft/components

    See Also

    Prev
    cli
    Next
    componentarchive
    \ No newline at end of file +$ ocm transfer ctf ctf.tgz ghcr.io/mandelsoft/components

    See Also

    Prev
    cli
    Next
    componentarchive
    \ No newline at end of file diff --git a/docs/cli-reference/transfer/componentarchive/index.html b/docs/cli-reference/transfer/componentarchive/index.html index 7fd3e7cd..966f5c39 100644 --- a/docs/cli-reference/transfer/componentarchive/index.html +++ b/docs/cli-reference/transfer/componentarchive/index.html @@ -1,10 +1,10 @@ componentarchive | Open Component Model -
    +
    -
    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
@@ -44,4 +44,4 @@
 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.
    See Also
    Prev
    componentarchive
    Next
    componentversions
    \ No newline at end of file +with the script option family.

    See Also

    Prev
    componentarchive
    Next
    componentversions
    \ No newline at end of file diff --git a/docs/cli-reference/transfer/componentversions/index.html b/docs/cli-reference/transfer/componentversions/index.html index 4c0f838f..7702a22e 100644 --- a/docs/cli-reference/transfer/componentversions/index.html +++ b/docs/cli-reference/transfer/componentversions/index.html @@ -1,10 +1,10 @@ componentversions | Open Component Model -
    +
    -
    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
@@ -76,7 +76,7 @@
 ‘url’: the URL of the maven repository.
  • plugin: [downloaders provided by plugins]
    sub namespace of the form <plugin name>/<handler>
  • ocm/ociArtifacts: downloading OCI artifacts
    The ociArtifacts downloader is able to download OCI artifacts
 as artifact archive according to the OCI distribution spec.
 The following artifact media types are supported:
    • application/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.
    It accepts a config with the following fields:
    • namespacePrefix: 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.
    • See ocm ocm-uploadhandlers for further details on using
+reference.
    See ocm ocm-uploadhandlers for further details on using
 upload handlers.
    It is possible to use a dedicated transfer script based on spiff.
 The option –scriptFile can be used to specify this script
 by a file name. With –script it can be taken from the
@@ -90,4 +90,4 @@

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

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

    Examples

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

    See Also

    Prev
    componentversions
    Next
    componentversions
    \ No newline at end of file +$ ocm transfer components -t tgz --repo OCIRegistry::ghcr.io mandelsoft/kubelink ctf.tgz

    See Also

    Prev
    componentversions
    Next
    componentversions
    \ No newline at end of file diff --git a/docs/cli-reference/transfer/index.html b/docs/cli-reference/transfer/index.html index fd511a34..007dd968 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/transfer/index.xml b/docs/cli-reference/transfer/index.xml index df2a7475..c3d1c845 100644 --- a/docs/cli-reference/transfer/index.xml +++ b/docs/cli-reference/transfer/index.xml @@ -1 +1 @@ -transfer on Open Component Modelhttps://ocm.software/docs/cli-reference/transfer/Recent content in transfer on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsWed, 17 Apr 2024 18:02:57 +0200artifactshttps://ocm.software/docs/cli-reference/transfer/artifacts/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/transfer/artifacts/Usage ocm transfer artifacts [&lt;options&gt;] {&lt;artifact-reference&gt;} &lt;target&gt; 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.commontransportarchivehttps://ocm.software/docs/cli-reference/transfer/commontransportarchive/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/transfer/commontransportarchive/Usage ocm transfer commontransportarchive [&lt;options&gt;] &lt;ctf&gt; &lt;target&gt; 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 -h, --help help for commontransportarchive --lookup stringArray repository name or spec for closure lookup fallback --no-update don&#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 &#34;directory&#34;) --uploader &lt;name&gt;=&lt;value&gt; repository uploader (&lt;name&gt;[:&lt;artifact type&gt;[:&lt;media type&gt;]]=&lt;JSON target config) (default []) Description Transfer content of a Common Transport Archive to the given target repository.componentarchivehttps://ocm.software/docs/cli-reference/transfer/componentarchive/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/transfer/componentarchive/Usage ocm transfer componentarchive [&lt;options&gt;] &lt;source&gt; &lt;target&gt; 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 -h, --help help for componentarchive --lookup stringArray repository name or spec for closure lookup fallback --no-update don&#39;t touch existing versions in target -f, --overwrite overwrite existing component versions -t, --type string archive format (directory, tar, tgz) (default &#34;directory&#34;) Description Transfer a component archive to some component repository.componentversionshttps://ocm.software/docs/cli-reference/transfer/componentversions/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/transfer/componentversions/Usage ocm transfer componentversions [&lt;options&gt;] {&lt;component-reference&gt;} &lt;target&gt; 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 --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&#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 &#34;directory&#34;) --uploader &lt;name&gt;=&lt;value&gt; repository uploader (&lt;name&gt;[:&lt;artifact type&gt;[:&lt;media type&gt;]]=&lt;JSON target config) (default []) Description Transfer all component versions specified to the given target repository. \ No newline at end of file +transfer on Open Component Modelhttps://ocm.software/docs/cli-reference/transfer/Recent content in transfer on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model Contributorsartifactshttps://ocm.software/docs/cli-reference/transfer/artifacts/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/transfer/artifacts/Usage ocm transfer artifacts [&lt;options&gt;] {&lt;artifact-reference&gt;} &lt;target&gt; 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.commontransportarchivehttps://ocm.software/docs/cli-reference/transfer/commontransportarchive/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/transfer/commontransportarchive/Usage ocm transfer commontransportarchive [&lt;options&gt;] &lt;ctf&gt; &lt;target&gt; 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 -h, --help help for commontransportarchive --lookup stringArray repository name or spec for closure lookup fallback --no-update don&#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 &#34;directory&#34;) --uploader &lt;name&gt;=&lt;value&gt; repository uploader (&lt;name&gt;[:&lt;artifact type&gt;[:&lt;media type&gt;]]=&lt;JSON target config) (default []) Description Transfer content of a Common Transport Archive to the given target repository.componentarchivehttps://ocm.software/docs/cli-reference/transfer/componentarchive/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/transfer/componentarchive/Usage ocm transfer componentarchive [&lt;options&gt;] &lt;source&gt; &lt;target&gt; 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 -h, --help help for componentarchive --lookup stringArray repository name or spec for closure lookup fallback --no-update don&#39;t touch existing versions in target -f, --overwrite overwrite existing component versions -t, --type string archive format (directory, tar, tgz) (default &#34;directory&#34;) Description Transfer a component archive to some component repository.componentversionshttps://ocm.software/docs/cli-reference/transfer/componentversions/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/transfer/componentversions/Usage ocm transfer componentversions [&lt;options&gt;] {&lt;component-reference&gt;} &lt;target&gt; 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 --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&#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 &#34;directory&#34;) --uploader &lt;name&gt;=&lt;value&gt; repository uploader (&lt;name&gt;[:&lt;artifact type&gt;[:&lt;media type&gt;]]=&lt;JSON target config) (default []) Description Transfer all component versions specified to the given target repository. \ No newline at end of file diff --git a/docs/cli-reference/transfer/sitemap.xml b/docs/cli-reference/transfer/sitemap.xml index b0d6076a..2d7eb70a 100644 --- a/docs/cli-reference/transfer/sitemap.xml +++ b/docs/cli-reference/transfer/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/cli-reference/transfer/artifacts/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/transfer/commontransportarchive/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/transfer/componentarchive/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/transfer/componentversions/2024-04-17T18:02:57+02:00monthly0.5 \ No newline at end of file +https://ocm.software/docs/cli-reference/transfer/artifacts/monthly0.5https://ocm.software/docs/cli-reference/transfer/commontransportarchive/monthly0.5https://ocm.software/docs/cli-reference/transfer/componentarchive/monthly0.5https://ocm.software/docs/cli-reference/transfer/componentversions/monthly0.5 \ 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 1568759e..fb9891a5 100644 --- a/docs/cli-reference/verify/componentversions/index.html +++ b/docs/cli-reference/verify/componentversions/index.html @@ -1,10 +1,10 @@ componentversions | Open Component Model -
    +
    -
    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
@@ -45,4 +45,4 @@
 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.
    Examples
    $ ocm verify componentversion --signature mandelsoft --public-key=mandelsoft.key ghcr.io/mandelsoft/kubelink
    See Also
    • ocm verify — Verify component version signatures
    Prev
    componentversions
    Next
    config
    \ No newline at end of file +references.

    Examples

    $ ocm verify componentversion --signature mandelsoft --public-key=mandelsoft.key ghcr.io/mandelsoft/kubelink

    See Also

    • ocm verify — Verify component version signatures
    Prev
    componentversions
    Next
    config
    \ No newline at end of file diff --git a/docs/cli-reference/verify/index.html b/docs/cli-reference/verify/index.html index 71375251..c221b56f 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/cli-reference/verify/index.xml b/docs/cli-reference/verify/index.xml index c9163fb7..49850a0a 100644 --- a/docs/cli-reference/verify/index.xml +++ b/docs/cli-reference/verify/index.xml @@ -1 +1 @@ -verify on Open Component Modelhttps://ocm.software/docs/cli-reference/verify/Recent content in verify on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsWed, 17 Apr 2024 18:02:57 +0200componentversionshttps://ocm.software/docs/cli-reference/verify/componentversions/Wed, 17 Apr 2024 18:02:57 +0200https://ocm.software/docs/cli-reference/verify/componentversions/Usage ocm verify componentversions [&lt;options&gt;] {&lt;component-reference&gt;} Options -- 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) ([&lt;name&gt;:=]&lt;dn&gt;) --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 &#34;~/. \ No newline at end of file +verify on Open Component Modelhttps://ocm.software/docs/cli-reference/verify/Recent content in verify on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model Contributorscomponentversionshttps://ocm.software/docs/cli-reference/verify/componentversions/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/cli-reference/verify/componentversions/Usage ocm verify componentversions [&lt;options&gt;] {&lt;component-reference&gt;} Options -- 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) ([&lt;name&gt;:=]&lt;dn&gt;) --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 &#34;~/. \ No newline at end of file diff --git a/docs/cli-reference/verify/sitemap.xml b/docs/cli-reference/verify/sitemap.xml index c5cdf0a4..4598bce1 100644 --- a/docs/cli-reference/verify/sitemap.xml +++ b/docs/cli-reference/verify/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/cli-reference/verify/componentversions/2024-04-17T18:02:57+02:00monthly0.5 \ No newline at end of file +https://ocm.software/docs/cli-reference/verify/componentversions/monthly0.5 \ No newline at end of file diff --git a/docs/component-descriptors/index.html b/docs/component-descriptors/index.html index 66e51d53..306a60cb 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/version-2/index.html b/docs/component-descriptors/version-2/index.html index fdfa648f..39e9a534 100644 --- a/docs/component-descriptors/version-2/index.html +++ b/docs/component-descriptors/version-2/index.html @@ -3,8 +3,8 @@ -
    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:
+
    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
 component:
   name: github.com/weaveworks/weave-gitops # name of the component
diff --git a/docs/component-descriptors/version-3/index.html b/docs/component-descriptors/version-3/index.html
index fc677d2c..8cd719a9 100644
--- a/docs/component-descriptors/version-3/index.html
+++ b/docs/component-descriptors/version-3/index.html
@@ -3,8 +3,8 @@
 
-
    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
+
    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
diff --git a/docs/contribution/contributing-guideline/index.html b/docs/contribution/contributing-guideline/index.html
index b5dbd25d..73792aaa 100644
--- a/docs/contribution/contributing-guideline/index.html
+++ b/docs/contribution/contributing-guideline/index.html
@@ -1,10 +1,10 @@
 Contributing Guideline | Open Component Model
-
    
+
    
 
-
    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 maintaine 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 789ba951..fd534c1a 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/index.xml b/docs/contribution/index.xml
index 3f68a8b6..25f221b4 100644
--- a/docs/contribution/index.xml
+++ b/docs/contribution/index.xml
@@ -1,4 +1,4 @@
-Contribute on Open Component Modelhttps://ocm.software/docs/contribution/Recent content in Contribute on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsFri, 12 Aug 2022 10:38:22 +0100Contributing Guidelinehttps://ocm.software/docs/contribution/contributing-guideline/Fri, 12 Aug 2022 10:38:22 +0100https://ocm.software/docs/contribution/contributing-guideline/Welcome to the OCM community!
+Contribute on Open Component Modelhttps://ocm.software/docs/contribution/Recent content in Contribute on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsFri, 12 Aug 2022 10:38:22 +0100Contributing Guidelinehttps://ocm.software/docs/contribution/contributing-guideline/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/contribution/contributing-guideline/Welcome to the OCM community!
 Thank you for taking the time to contribute to OCM.
 DCO 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).Security Guidelinehttps://ocm.software/docs/contribution/security-guideline/Fri, 12 Aug 2022 10:38:22 +0100https://ocm.software/docs/contribution/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.
\ No newline at end of file
diff --git a/docs/contribution/security-guideline/index.html b/docs/contribution/security-guideline/index.html
index fd6f9c73..2008d06d 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
    artifacts
    
\ 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
    artifacts
    \ No newline at end of file diff --git a/docs/contribution/sitemap.xml b/docs/contribution/sitemap.xml index 6d7aa60d..7c72b02b 100644 --- a/docs/contribution/sitemap.xml +++ b/docs/contribution/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/contribution/contributing-guideline/2022-08-12T10:38:22+01:00monthly0.5https://ocm.software/docs/contribution/security-guideline/2022-08-12T10:38:22+01:00monthly0.5 \ No newline at end of file +https://ocm.software/docs/contribution/contributing-guideline/monthly0.5https://ocm.software/docs/contribution/security-guideline/2022-08-12T10:38:22+01:00monthly0.5 \ No newline at end of file diff --git a/docs/controller/architecture/index.html b/docs/controller/architecture/index.html index 485c4ed0..b2b793c3 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 6716a3e5..a62e5ac5 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 327a083d..d0b97dcd 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 bd6f3801..63ddffa9 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 ee8e20fe..b30fc98b 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 49ab5d62..ceaa5875 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 8d6b0a21..3c5ca831 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 205bd5dc..b4ea0575 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 9e818572..ff19e529 100644
--- a/docs/controller/controller-reference/replication-controller/index.html
+++ b/docs/controller/controller-reference/replication-controller/index.html
@@ -3,8 +3,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 a7c6ea00..e531d52d 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 2be6a30f..067ebf48 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/index.html b/docs/examples/index.html
index a5da6dc9..38870565 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-open-component-model/index.html b/docs/examples/secure-software-delivery-with-flux-and-open-component-model/index.html index d71d0ecd..5b8feaa2 100644 --- a/docs/examples/secure-software-delivery-with-flux-and-open-component-model/index.html +++ b/docs/examples/secure-software-delivery-with-flux-and-open-component-model/index.html @@ -5,8 +5,8 @@ -
                Docs

                Secure software delivery with Flux and Open Component Model

                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 Open Component Model

                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.

                Overview

                workflow

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

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

                Two Gitea organizations are created:

                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 component and pushes it to the software provider’s OCI registry.

                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 upstream source.

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

                Once this pull request is merged the Flux machinery will deploy the dependency weave-gitops and subsequently the podinfo component. The weave-gitops dashboard 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 Weave GitOps dashboard, accessing the deployed application, applying configuration changes, monitoring the application update, and cutting a new release with updated features.

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

                0. Checkout the source repository

                git clone https://github.com/open-component-model/demo-secure-delivery && \
 cd demo-secure-delivery

                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

                release

                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”.

                3. Verify the release

                ci

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

                4. Install the Component

                install

                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.

                5. View the Weave GitOps Dashboard

                weave-gitops

                With a minute or so Flux will reconcile the Weave GitOps component and the dashboard will be accessible at https://weave-gitops.ocm.dev. You can login with username: admin and password password.

                5. View the application

                podinfo

                We can view the podinfo Helm release that’s been deployed in the default namespace: https://weave-gitops.ocm.dev/helm_release/graph?clusterName=Default&name=podinfo&namespace=default

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

                6. Apply configuration

                configure

                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 @@ -17,5 +17,5 @@ serviceAccountName: ocm-ops weave-gitops: serviceAccountName: ocm-ops

                7. View the configured application

                update

                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.

                8. Cut a new release

                Let’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.

                9. 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.

                10. Monitor the application update

                update-wego

                Jump back to https://weave-gitops.ocm.dev to view the rollout of the new release.

                11. View the updated application

                update-ocm

                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

                Conclusion

                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.

                Users can easily set up the demo environment, cut releases, monitor release automation, view the Weave 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.

                Contributing

                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.

                OCM follows the CNCF Code of Conduct.

                Licensing

                Copyright 2024 SE or an SAP affiliate company and Open Component Model contributors. -Please see our LICENSE for copyright and license information. +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.

                Prev
                Input and Access Types
                Next
                Our Roadmap
                \ No newline at end of file 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 aeaf8025..58cdadbe 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 @@ -5,8 +5,8 @@ -
                Docs

                Create a Component Version

                Setting Up Environment Variables

                For convenience, we will define the following environment variables:

                PROVIDER="acme.org"
+
                Docs

                Create a Component Version

                Setting Up Environment Variables

                For convenience, we will define the following environment variables:

                PROVIDER="acme.org"
 ORG="acme"
 COMPONENT="github.com/${ORG}/helloworld"
 VERSION="1.0.0"
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 f33897db..1c33f828 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,8 +3,8 @@
 
-
                Docs

                Display and Examine Component Versions

                List Component Versions

                To show the component stored in a component archive (without looking at the file system structure), 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
+
                Docs

                Display and Examine Component Versions

                List Component Versions

                To show the component stored in a component archive (without looking at the file system structure), 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
diff --git a/docs/getting-started/getting-started-with-ocm/index.html b/docs/getting-started/getting-started-with-ocm/index.html
index 40cf1ee1..667c64a3 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/prerequisites/index.html b/docs/getting-started/getting-started-with-ocm/prerequisites/index.html index f6943626..737d0f0e 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 7bdc0673..34bce4da 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 c10ec456..73044cb8 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 e8e113d2..5d90760d 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 aa670a77..5465bd53 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 865b0ea3..2646a743 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 f365a93a..4e6e0d70 100644 --- a/docs/overview/about/index.html +++ b/docs/overview/about/index.html @@ -1,7 +1,7 @@ About the OCM Project | Open Component Model -
                +
                -
                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.

                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 3
                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 441fe179..e8dbeec5 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 ba7c7620..da648471 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 362abb39..337f8feb 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/index.xml b/docs/overview/index.xml index ddcb8e4d..1c956b68 100644 --- a/docs/overview/index.xml +++ b/docs/overview/index.xml @@ -1 +1 @@ -Overview on Open Component Modelhttps://ocm.software/docs/overview/Recent content in Overview on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsTue, 06 Oct 2020 08:48:23 +0000About the OCM Projecthttps://ocm.software/docs/overview/about/Tue, 06 Oct 2020 08:48:23 +0000https://ocm.software/docs/overview/about/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.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/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.Important Termshttps://ocm.software/docs/overview/important-terms/Tue, 06 Oct 2020 08:48:23 +0000https://ocm.software/docs/overview/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.Specificationhttps://ocm.software/docs/overview/specification/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/overview/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. \ No newline at end of file +Overview on Open Component Modelhttps://ocm.software/docs/overview/Recent content in Overview on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsTue, 06 Oct 2020 08:48:23 +0000About the OCM Projecthttps://ocm.software/docs/overview/about/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/overview/about/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.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/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.Important Termshttps://ocm.software/docs/overview/important-terms/Tue, 06 Oct 2020 08:48:23 +0000https://ocm.software/docs/overview/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.Specificationhttps://ocm.software/docs/overview/specification/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/overview/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. \ No newline at end of file diff --git a/docs/overview/sitemap.xml b/docs/overview/sitemap.xml index 994aad2b..0334ae3c 100644 --- a/docs/overview/sitemap.xml +++ b/docs/overview/sitemap.xml @@ -1 +1 @@ -https://ocm.software/docs/overview/about/2020-10-06T08:48:23+00:00monthly0.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.5 \ No newline at end of file +https://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.5 \ No newline at end of file diff --git a/docs/overview/specification/index.html b/docs/overview/specification/index.html index 92de5cfc..e79947ad 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 e739968c..79a781e4 100644 --- a/docs/overview/specification/schema-v2.html +++ b/docs/overview/specification/schema-v2.html @@ -1 +1 @@ - Schema Docs
                Type: object

                Open Component Model v2 schema

                root meta
                Type: object

                component descriptor metadata

                root meta schemaVersion
                Type: string

                root component
                Type: object

                a component

                root component 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 component 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 component creationTime
                Type: string or nullFormat: date-time

                root component provider
                Type: string

                root component labels
                Type: array
                No Additional Items

                Each item of this array must be:

                root component labels label
                Type: object

                root component labels labels items name
                Type: string

                root component labels labels items value
                Type: object

                root component labels labels items version
                Type: object
                Must match regular expression: ^v[0-9]+$

                root component labels labels items signing
                Type: boolean

                root component labels labels items merge
                Type: object
                No Additional Properties

                root component labels labels items merge algorithm
                Type: object
                Must match regular expression: ^[a-z][a-z0-9/_-]+$

                root component sources
                Type: array
                No Additional Items

                Each item of this array must be:

                root component sources sourceDefinition
                Type: object

                root component 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 component sources sources items type
                Type: string

                root component sources sources items labels
                Type: array
                No Additional Items

                Each item of this array must be:

                root component sources sources items labels label
                Type: object
                Same definition as component_labels_items

                root component sources sources items access

                root component sources sources items access anyOf access
                Type: object

                base type for accesses (for extensions)

                The following properties are required:

                • type
                root component sources sources items access anyOf githubAccess
                Type: object

                root component sources sources items access anyOf item 1 type
                Type: enum (of string)

                Must be one of:

                • "github"

                root component sources sources items access anyOf httpAccess
                Type: object

                root component sources sources items access anyOf item 2 type
                Type: enum (of string)

                Must be one of:

                • "http"

                root component componentReferences
                Type: array
                No Additional Items

                Each item of this array must be:

                root component componentReferences componentReference
                Type: object

                a reference to a component

                root component componentReferences componentReferences 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 component resources
                Type: array
                No Additional Items

                Each item of this array must be:

                root component resources resources items

                root component resources resources items anyOf resourceType
                Type: object

                base type for resources

                root component 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 component resources resources items anyOf item 0 srcRefs
                Type: array
                No Additional Items

                Each item of this array must be:

                root component resources resources items anyOf item 0 srcRefs srcRef
                Type: object

                a reference to a (component-local) source

                root component resources resources items anyOf item 0 relation
                Type: enum (of string)

                Must be one of:

                • "local"
                • "external"

                root component resources resources items anyOf item 0 labels
                Type: array
                No Additional Items

                Each item of this array must be:

                root component resources resources items anyOf item 0 labels label
                Type: object
                Same definition as component_labels_items

                root component resources resources items anyOf item 0 access

                root component resources resources items anyOf item 0 access anyOf access
                Type: object

                base type for accesses (for extensions)

                Same definition as component_sources_items_access_anyOf_i0
                root component resources resources items anyOf item 0 access anyOf ociBlobAccess
                Type: object

                The following properties are required:

                • layer

                root component resources resources items anyOf item 0 access anyOf item 1 type
                Type: enum (of string)

                Must be one of:

                • "ociBlob"

                root component resources resources items anyOf item 0 access anyOf item 1 ref
                Type: string

                A oci reference to the manifest

                root component resources resources items anyOf item 0 access anyOf item 1 mediaType
                Type: string

                The media type of the object this access refers to

                root component resources resources items anyOf item 0 access anyOf item 1 digest
                Type: string

                The digest of the targeted content

                root component resources resources items anyOf item 0 access anyOf item 1 size
                Type: number

                The size in bytes of the blob
                root component resources resources items anyOf item 0 access anyOf localFilesystemBlobAccess
                Type: object

                root component resources resources items anyOf item 0 access anyOf item 2 type
                Type: enum (of string)

                Must be one of:

                • "localFilesystemBlob"

                root component 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 component resources resources items anyOf item 0 access anyOf localOciBlobAccess
                Type: object

                The following properties are required:

                • filename

                root component resources resources items anyOf item 0 access anyOf item 3 type
                Type: enum (of string)

                Must be one of:

                • "localOciBlob"

                root component resources resources items anyOf item 0 access anyOf item 3 digest
                Type: string

                digest of the layer within the current component descriptor
                root component resources resources items anyOf ociImageResource
                Type: object

                root component 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 component resources resources items anyOf item 1 type
                Type: enum (of string)

                Must be one of:

                • "ociImage"

                root component resources resources items anyOf item 1 labels
                Type: array
                No Additional Items

                Each item of this array must be:

                root component resources resources items anyOf item 1 labels label
                Type: object
                Same definition as component_labels_items

                root component resources resources items anyOf item 1 access
                Type: object

                root component resources resources items anyOf item 1 access type
                Type: enum (of string)

                Must be one of:

                • "ociRegistry"

                root component resources resources items anyOf genericResource
                Type: object

                root component 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 component resources resources items anyOf item 2 type
                Type: enum (of string)

                Must be one of:

                • "generic"

                root component resources resources items anyOf item 2 labels
                Type: array
                No Additional Items

                Each item of this array must be:

                root component resources resources items anyOf item 2 labels label
                Type: object
                Same definition as component_labels_items

                root component resources resources items anyOf item 2 access
                Type: object

                root component resources resources items anyOf item 2 access type
                Type: enum (of string)

                Must be one of:

                • "generic"

                root signatures
                Type: array
                No Additional Items

                Each item of this array must be:

                root signatures signature
                Type: object

                root signatures signatures items name
                Type: string

                root signatures signatures items signature
                Type: object

                root signatures signatures items signature mediaType
                Type: string

                The media type of the signature value
                \ No newline at end of file + Schema Docs
                Type: object

                Open Component Model v2 schema

                root meta
                Type: object

                component descriptor metadata

                root meta schemaVersion
                Type: string

                root component
                Type: object

                a component

                root component 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 component 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 component creationTime
                Type: string or nullFormat: date-time

                root component provider
                Type: string

                root component labels
                Type: array
                No Additional Items

                Each item of this array must be:

                root component labels label
                Type: object

                root component labels labels items name
                Type: string

                root component labels labels items value
                Type: object

                root component labels labels items version
                Type: object
                Must match regular expression: ^v[0-9]+$

                root component labels labels items signing
                Type: boolean

                root component labels labels items merge
                Type: object
                No Additional Properties

                root component labels labels items merge algorithm
                Type: object
                Must match regular expression: ^[a-z][a-z0-9/_-]+$

                root component sources
                Type: array
                No Additional Items

                Each item of this array must be:

                root component sources sourceDefinition
                Type: object

                root component 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 component sources sources items type
                Type: string

                root component sources sources items labels
                Type: array
                No Additional Items

                Each item of this array must be:

                root component sources sources items labels label
                Type: object
                Same definition as component_labels_items

                root component sources sources items access

                root component sources sources items access anyOf access
                Type: object

                base type for accesses (for extensions)

                The following properties are required:

                • type
                root component sources sources items access anyOf githubAccess
                Type: object

                root component sources sources items access anyOf item 1 type
                Type: enum (of string)

                Must be one of:

                • "github"

                root component sources sources items access anyOf httpAccess
                Type: object

                root component sources sources items access anyOf item 2 type
                Type: enum (of string)

                Must be one of:

                • "http"

                root component componentReferences
                Type: array
                No Additional Items

                Each item of this array must be:

                root component componentReferences componentReference
                Type: object

                a reference to a component

                root component componentReferences componentReferences 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 component resources
                Type: array
                No Additional Items

                Each item of this array must be:

                root component resources resources items

                root component resources resources items anyOf resourceType
                Type: object

                base type for resources

                root component 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 component resources resources items anyOf item 0 srcRefs
                Type: array
                No Additional Items

                Each item of this array must be:

                root component resources resources items anyOf item 0 srcRefs srcRef
                Type: object

                a reference to a (component-local) source

                root component resources resources items anyOf item 0 relation
                Type: enum (of string)

                Must be one of:

                • "local"
                • "external"

                root component resources resources items anyOf item 0 labels
                Type: array
                No Additional Items

                Each item of this array must be:

                root component resources resources items anyOf item 0 labels label
                Type: object
                Same definition as component_labels_items

                root component resources resources items anyOf item 0 access

                root component resources resources items anyOf item 0 access anyOf access
                Type: object

                base type for accesses (for extensions)

                Same definition as component_sources_items_access_anyOf_i0
                root component resources resources items anyOf item 0 access anyOf ociBlobAccess
                Type: object

                The following properties are required:

                • layer

                root component resources resources items anyOf item 0 access anyOf item 1 type
                Type: enum (of string)

                Must be one of:

                • "ociBlob"

                root component resources resources items anyOf item 0 access anyOf item 1 ref
                Type: string

                A oci reference to the manifest

                root component resources resources items anyOf item 0 access anyOf item 1 mediaType
                Type: string

                The media type of the object this access refers to

                root component resources resources items anyOf item 0 access anyOf item 1 digest
                Type: string

                The digest of the targeted content

                root component resources resources items anyOf item 0 access anyOf item 1 size
                Type: number

                The size in bytes of the blob
                root component resources resources items anyOf item 0 access anyOf localFilesystemBlobAccess
                Type: object

                root component resources resources items anyOf item 0 access anyOf item 2 type
                Type: enum (of string)

                Must be one of:

                • "localFilesystemBlob"

                root component 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 component resources resources items anyOf item 0 access anyOf localOciBlobAccess
                Type: object

                The following properties are required:

                • filename

                root component resources resources items anyOf item 0 access anyOf item 3 type
                Type: enum (of string)

                Must be one of:

                • "localOciBlob"

                root component resources resources items anyOf item 0 access anyOf item 3 digest
                Type: string

                digest of the layer within the current component descriptor
                root component resources resources items anyOf ociImageResource
                Type: object

                root component 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 component resources resources items anyOf item 1 type
                Type: enum (of string)

                Must be one of:

                • "ociImage"

                root component resources resources items anyOf item 1 labels
                Type: array
                No Additional Items

                Each item of this array must be:

                root component resources resources items anyOf item 1 labels label
                Type: object
                Same definition as component_labels_items

                root component resources resources items anyOf item 1 access
                Type: object

                root component resources resources items anyOf item 1 access type
                Type: enum (of string)

                Must be one of:

                • "ociRegistry"

                root component resources resources items anyOf genericResource
                Type: object

                root component 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 component resources resources items anyOf item 2 type
                Type: enum (of string)

                Must be one of:

                • "generic"

                root component resources resources items anyOf item 2 labels
                Type: array
                No Additional Items

                Each item of this array must be:

                root component resources resources items anyOf item 2 labels label
                Type: object
                Same definition as component_labels_items

                root component resources resources items anyOf item 2 access
                Type: object

                root component resources resources items anyOf item 2 access type
                Type: enum (of string)

                Must be one of:

                • "generic"

                root signatures
                Type: array
                No Additional Items

                Each item of this array must be:

                root signatures signature
                Type: object

                root signatures signatures items name
                Type: string

                root signatures signatures items signature
                Type: object

                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/overview/specification/schema-v3alpha1.html b/docs/overview/specification/schema-v3alpha1.html index 4180ea4b..b6c1750d 100644 --- a/docs/overview/specification/schema-v3alpha1.html +++ b/docs/overview/specification/schema-v3alpha1.html @@ -1 +1 @@ - 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 provider
                Type: object
                No Additional Properties

                root metadata provider name
                Type: string

                root repositoryContexts
                Type: array
                No Additional Items

                Each item of this array must be:

                root repositoryContexts repositoryContexts items

                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 type
                Type: string

                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 httpAccess
                Type: object

                root spec sources sources items access anyOf item 2 type
                Type: enum (of string)

                Must be one of:

                • "http"

                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 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 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 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 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 relation
                Type: enum (of string)

                Must be one of:

                • "local"
                • "external"

                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 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 type
                Type: enum (of string)

                Must be one of:

                • "ociImage"

                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 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 type
                Type: enum (of string)

                Must be one of:

                • "generic"

                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 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 mediaType
                Type: string

                The media type of the signature value
                \ No newline at end of file + 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 provider
                Type: object
                No Additional Properties

                root metadata provider name
                Type: string

                root repositoryContexts
                Type: array
                No Additional Items

                Each item of this array must be:

                root repositoryContexts repositoryContexts items

                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 type
                Type: string

                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 httpAccess
                Type: object

                root spec sources sources items access anyOf item 2 type
                Type: enum (of string)

                Must be one of:

                • "http"

                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 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 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 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 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 relation
                Type: enum (of string)

                Must be one of:

                • "local"
                • "external"

                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 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 type
                Type: enum (of string)

                Must be one of:

                • "ociImage"

                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 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 type
                Type: enum (of string)

                Must be one of:

                • "generic"

                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 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 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 89f5c4b4..d9cc8fe4 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 3840b079..336e47ff 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 Open Component Model
                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 Open Component Model
                Next
                How to get Support
                \ No newline at end of file diff --git a/docs/sitemap.xml b/docs/sitemap.xml index 2a621cfe..3ae8e108 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/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/overview/about/2020-10-06T08:48:23+00:00monthly0.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/2022-08-12T10:37:58+01:00monthly0.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/2023-06-20T10:00:00+00:00monthly0.5https://ocm.software/docs/tutorials/input-and-access-types/2023-04-05T08:24:35+02:00monthly0.5https://ocm.software/docs/tutorials/monthly0.5https://ocm.software/docs/examples/secure-software-delivery-with-flux-and-open-component-model/2023-11-07T11:45:27+00: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/2022-08-12T10:38:22+01:00monthly0.5https://ocm.software/docs/contribution/security-guideline/2022-08-12T10:38:22+01:00monthly0.5https://ocm.software/docs/cli-reference/add/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/check/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/clean/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/create/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/describe/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/download/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/list/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/set/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/show/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/sign/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/transfer/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/verify/2024-04-17T18:02:57+02:00monthly0.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/2022-08-12T10:37:58+01:00monthly0.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/2023-06-20T10:00:00+00:00monthly0.5https://ocm.software/docs/tutorials/input-and-access-types/2023-04-05T08:24:35+02:00monthly0.5https://ocm.software/docs/examples/secure-software-delivery-with-flux-and-open-component-model/2023-11-07T11:45:27+00: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 624ba651..51b6ef03 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 1e8ee4a6..964df0ce 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 4b0da358..b7251740 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 280a0202..a7793c6a 100644 --- a/docs/tutorials/best-practices/index.html +++ b/docs/tutorials/best-practices/index.html @@ -3,10 +3,10 @@ -
                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: +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. b) Publish: Use a separate, secured process to distribute build results.

                OCM 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.

                Separation 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 @@ -23,12 +23,12 @@ 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.

                The composition of such archives is described in the Getting Started section.

                To secure further processes, a certified build-system could even sign the content with +by others.

                The composition of such archives is described in the Getting Started section.

                To 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.

                Building 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

                At 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 blogpost)

                The OCM CLI has some built-in support for dealing with multi-arch images during the +support multi-arch images (for additional information, see the Multi-arch build and images, the simple way blog post)

                The 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 @@ -156,11 +156,11 @@ => importing to docker

                Check that the images were created correctly:

                $ 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

                In the next step we create a component archive and a transport archive

                $ PROVIDER=acme
-$ COMPONENT=github.com/$(PROVIDER)/simpleserver
-$ VERSION=0.1.0
-$ mkdir gen
-$ ocm create ca ${COMPONENT} ${VERSION} --provider ${PROVIDER} --file gen/ca

                Create the file resources.yaml. Note the variants in the image input and the type dockermulti:

                ---
+eu.gcr.io/acme/simpleserver   0.1.0-linux-amd64   08641d64f612   About a minute ago   25.7MB

                In the next step we create a component archive and a transport archive

                PROVIDER=acme
+COMPONENT=github.com/$(PROVIDER)/simpleserver
+VERSION=0.1.0
+mkdir gen
+ocm create ca ${COMPONENT} ${VERSION} --provider ${PROVIDER} --file gen/ca

                Create the file resources.yaml. Note the variants in the image input and the type dockermulti:

                ---
 name: chart
 type: helmChart
 input:
@@ -415,7 +415,7 @@
 clean:
 	rm -rf $(GEN)

                The Makefile supports the following targets:

                • build (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.

                Example:

                $ PROVIDER=foo make ca

                Templating the Resources

                The Makefile uses a dynamic list of generated platforms for the images. You can just set the PLATFORMS variable:

                MULTI     ?= true
+declared in the Makefile. Use either an environment variable or an argument when calling make.
                Example:
                PROVIDER=foo make ca
                Templating the Resources
                The Makefile uses a dynamic list of generated platforms for the images. You can just set the PLATFORMS variable:
                MULTI     ?= 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
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 ff506f7a..e5603796 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,9 +3,9 @@
 
-
                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. +

                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>
 helm pull --destination <target-dir> <repo-name/chart-name>

                For the podinfo example:

                helm repo add podinfo https://stefanprodan.github.io/podinfo
@@ -28,7 +28,7 @@
     access:
       type: ociArtifact
       imageReference: ghcr.io/stefanprodan/charts/podinfo:${PODINFO_VERSION}
-  # Helm Chart in Helm repository  
+  # Helm Chart in Helm repository
   - name: helm-chart-external-helm-repo
     type: helmChart
     version: ${PODINFO_VERSION}
@@ -58,7 +58,7 @@
       repository: ocm/ocm.software/podinfo/image
       imageReference: ghcr.io/stefanprodan/podinfo:${PODINFO_VERSION}

                Some 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 +here. For this example we use the default template engine type subst.

                Note the differences between the various components:

                Building 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. @@ -80,7 +80,7 @@ adding resource ociImage: "name"="image","version"="6.7.0"...

                You can view all component versions in a transport archive using the command:

                ocm get componentversion -o yaml <ctf-target-dir>
                ocm get componentversion ./ocm-hello-world
 COMPONENT            VERSION PROVIDER
 ocm.software/podinfo 6.7.0   stb1337

                You can store the transport archive in an OCI registry (this step needs a proper -configuration of credentials for the OCM CLI):

                ocm transfer ctf -f <ctf-target-dir> <oci-repo-url>

                Using the --copy-resources flag the OCM CLI will copy also copy all referenced resourcres to the OCI registry, making the resources part of the OCM component version, creating a self-contained component version.

                ocm transfer ctf --copy-resources --enforce --overwrite ./ocm-hello-world OCIRegistry::ghcr.io/stb1337/ocm-hello-world-v1
+configuration of credentials for the OCM CLI):
                ocm transfer ctf -f <ctf-target-dir> <oci-repo-url>
                Using 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.
                ocm transfer ctf --copy-resources --enforce --overwrite ./ocm-hello-world OCIRegistry::ghcr.io/stb1337/ocm-hello-world-v1
 transferring component "ocm.software/podinfo"...
   transferring version "ocm.software/podinfo:6.7.0"...
   ...resource 0 helm-chart-external-oci[helmChart](stefanprodan/charts/podinfo:6.7.0)...
diff --git a/docs/tutorials/index.html b/docs/tutorials/index.html
index 4c614698..4936cf46 100644
--- a/docs/tutorials/index.html
+++ b/docs/tutorials/index.html
@@ -1,7 +1,7 @@
-| Open Component Model
-
                
+Tutorials | Open Component Model
+
                
 
-
                Docs
                helloworld
                Prev
                versions
                
\ No newline at end of file
+
                Docs
                Tutorials
                
\ No newline at end of file
diff --git a/docs/tutorials/index.xml b/docs/tutorials/index.xml
index 57e7e317..f6b6e71e 100644
--- a/docs/tutorials/index.xml
+++ b/docs/tutorials/index.xml
@@ -1 +1 @@
-Tutorials on Open Component Modelhttps://ocm.software/docs/tutorials/Recent content in Tutorials on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsTue, 19 Mar 2024 10:36:48 +0100Best Practiceshttps://ocm.software/docs/tutorials/best-practices/Mon, 13 Mar 2023 12:00:26 +0100https://ocm.software/docs/tutorials/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.Build & Deploy Infrastructure via Helm Charts with OCMhttps://ocm.software/docs/tutorials/build-deploy-infrastructure-via-helm-charts-with-ocm/Tue, 19 Mar 2024 10:36:48 +0100https://ocm.software/docs/tutorials/build-deploy-infrastructure-via-helm-charts-with-ocm/Introduction Let&rsquo;s illustrate a very simple &ldquo;Hello World&rdquo; 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.Structuring and Deploying Software Products with OCMhttps://ocm.software/docs/tutorials/structuring-and-deploying-software-products-with-ocm/Tue, 20 Jun 2023 10:00:00 +0000https://ocm.software/docs/tutorials/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.Input and Access Typeshttps://ocm.software/docs/tutorials/input-and-access-types/Wed, 05 Apr 2023 08:24:35 +0200https://ocm.software/docs/tutorials/input-and-access-types/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.<link>https://ocm.software/docs/tutorials/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://ocm.software/docs/tutorials/</guid><description></description></item></channel></rss>
\ No newline at end of file
+<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Tutorials on Open Component Modelhttps://ocm.software/docs/tutorials/Recent content in Tutorials on Open Component ModelHugo -- gohugo.ioen© Copyright 2024, SAP SE and Open Component Model ContributorsTue, 19 Mar 2024 10:36:48 +0100Best Practiceshttps://ocm.software/docs/tutorials/best-practices/Mon, 13 Mar 2023 12:00:26 +0100https://ocm.software/docs/tutorials/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.Build & Deploy Infrastructure via Helm Charts with OCMhttps://ocm.software/docs/tutorials/build-deploy-infrastructure-via-helm-charts-with-ocm/Tue, 19 Mar 2024 10:36:48 +0100https://ocm.software/docs/tutorials/build-deploy-infrastructure-via-helm-charts-with-ocm/Introduction Let&rsquo;s illustrate a very simple &ldquo;Hello World&rdquo; 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.Structuring and Deploying Software Products with OCMhttps://ocm.software/docs/tutorials/structuring-and-deploying-software-products-with-ocm/Tue, 20 Jun 2023 10:00:00 +0000https://ocm.software/docs/tutorials/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.Input and Access Typeshttps://ocm.software/docs/tutorials/input-and-access-types/Wed, 05 Apr 2023 08:24:35 +0200https://ocm.software/docs/tutorials/input-and-access-types/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.
\ 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 522a0646..fd0cccec 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 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 as 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
                The following list of access types is supported:
                • gitHub
                • localBlob
                • ociArtifact
                • ociBlob
                • s3
                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 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 as 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
                The following list of access types is supported:
                • gitHub
                • localBlob
                • ociArtifact
                • ociBlob
                • s3
                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 69f8dfa4..893b0dcb 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
@@ -33,7 +33,7 @@
 phoban.io/podinfo 6.3.5   phoban.io
                Let’s examine the image resource on the component in our private registry:
                ocm 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 {"imageReference":"ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5"}
                We can see that the image reference now points to an image stored in our air-gapped registry.
                GitOps & Localization
                Now that our component has been successfully transferred, let’s deploy it using GitOps.
                We assume you have completed the Deploy Applications with OCM & GitOps guide and will use that repository as the starting point for our air-gapped deployment.
                Because our air-gapped OCM repository is private, we need to provide credentials. This will enable the ocm-controller to retrieve components from the repository.
                We can do this using a ServiceAccount. First, create an Kubernetes Secret to hold the credentials:
                kubectl create secret docker-registry -n ocm-system ghcr-cred \
+image 6.3.5            ociImage external ociArtifact {"imageReference":"ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5"}
                We can see that the image reference now points to an image stored in our air-gapped registry.
                GitOps & Localization
                Now that our component has been successfully transferred, let’s deploy it using GitOps.
                We assume you have completed the Deploy Applications with OCM & GitOps guide and will use that repository as the starting point for our air-gapped deployment.
                Because our air-gapped OCM repository is private, we need to provide credentials. This will enable the ocm-controller to retrieve components from the repository.
                We can do this using a ServiceAccount. First, create an Kubernetes Secret to hold the credentials:
                kubectl create secret docker-registry -n ocm-system ghcr-cred \
   --docker-server=ghcr.io \
   --docker-username=$GITHUB_USER \
   --docker-password=$GITHUB_TOKEN
                Then, create the ServiceAccount:
                cat > ./components/service_account.yaml <<EOF
@@ -104,4 +104,4 @@
 6m6s        Warning   Failed      pod/podinfo-7b7d874bf8-xv75x   Failed to pull image "ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5": rpc error: code = Unknown desc = failed to pull and unpack image "ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5": failed to resolve reference "ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5": 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 "ghcr.io/phoban01/air-gapped/stefanprodan/podinfo:6.3.5"
-5m44s       Warning   Failed      pod/podinfo-7b7d874bf8-xv75x   Error: ImagePullBackOff
                Check 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!
                Conclusion
                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.
                We 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.
                Prev
                Component Subscription
                Next
                Best Practices
                
\ No newline at end of file
+5m44s       Warning   Failed      pod/podinfo-7b7d874bf8-xv75x   Error: ImagePullBackOff

                Check 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!

                Conclusion

                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.

                We 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.

                Prev
                Component Subscription
                Next
                Best Practices
                \ No newline at end of file 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 880d42a7..12eee215 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 \
@@ -84,4 +84,4 @@
 
 NAME                       READY   STATUS    RESTARTS   AGE
 podinfo-84cb98c9b6-75rx5   1/1     Running   0          1m
-podinfo-84cb98c9b6-k4lk8   1/1     Running   0          1m

                Wrapping Up

                That’s it! That’s how easy it is to get started using the Open Component Model and Flux.

                If you want to know more about working with OCM and GitOps, check out these guides:

                Prev
                Structuring and Deploying Software Products with OCM
                Next
                GitOps Driven Configuration of OCM Applications
                \ No newline at end of file +podinfo-84cb98c9b6-k4lk8 1/1 Running 0 1m

                Wrapping Up

                That’s it! That’s how easy it is to get started using the Open Component Model and Flux.

                If you want to know more about working with OCM and GitOps, check out these guides:

                Prev
                Structuring and Deploying Software Products with OCM
                Next
                GitOps Driven Configuration of OCM Applications
                \ No newline at end of file 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 7e69252f..70796745 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 ec84bfcc..f9af3fb2 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/sitemap.xml b/docs/tutorials/sitemap.xml index 348bb4e4..7eaf22f8 100644 --- a/docs/tutorials/sitemap.xml +++ b/docs/tutorials/sitemap.xml @@ -1 +1 @@ -https://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/2023-06-20T10:00:00+00:00monthly0.5https://ocm.software/docs/tutorials/input-and-access-types/2023-04-05T08:24:35+02:00monthly0.5https://ocm.software/docs/tutorials/monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/air-gapped-gitops-with-ocm-flux/2022-11-23T10:00:00+00:00monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/deploying-applications-with-ocm-gitops/2022-11-23T10:00:00+00:00monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/gitops-driven-configuration-of-ocm-applications/2022-11-23T10:00:00+00:00monthly0.5 \ No newline at end of file +https://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/2023-06-20T10:00:00+00:00monthly0.5https://ocm.software/docs/tutorials/input-and-access-types/2023-04-05T08:24:35+02:00monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/air-gapped-gitops-with-ocm-flux/2022-11-23T10:00:00+00:00monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/deploying-applications-with-ocm-gitops/2022-11-23T10:00:00+00:00monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/gitops-driven-configuration-of-ocm-applications/2022-11-23T10:00:00+00:00monthly0.5 \ 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 16b60d49..7347eeda 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. @@ -23,7 +23,7 @@ hierarchies or you could just maintain a list of component version combinations which build a valid product release.

                In 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.

                Prerequisites

                We assume that you have already read the guides in the Getting Started section, as this guide discusses a more +references, you could collect all artifacts belonging to this product version.

                Prerequisites

                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.

                Constructing the Component

                We are going to use podinfo in microservices mode. This enables us to deploy several components and configure them individually.

                podinfo has three services which we are going to model using individual component descriptors:

                • backend
                • frontend
                • cache (redis)

                We will use the following example application to demonstrate a multi-component structure using podinfo: Podinfo Component.

                This repository contains the following items:

                Component 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.

                # 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:
@@ -215,7 +215,7 @@
     ├── sha256.ee79c92bbcce9e7a98f07c6577fd56dd45cf6f7c2d3115216ee249f42119030e
     └── sha256.f6a82a23220752c232e5f66ce46f0be28b27a5af19474072c77dac6d1feb0c16
 
-2 directories, 19 files

                These blobs contain the resources we described when modelling our podinfo application. If we cat a random blob we get +2 directories, 19 files

                These blobs contain the resources we described when modelling our podinfo application. If we cat a random blob we get something like this:

                cat sha256.3c9c902ce013ca070a29634e4603c90063c96df632ef2c8e6b4447aaeb70b67e
 {"componentDescriptorLayer":{"mediaType":"application/vnd.ocm.software.component-descriptor.v2+yaml+tar","digest":"sha256:699ea8628e39256048cd1687c496fe64999a41f16f200ef5ce938ee9f19c37f0","size":2560}}%

                Next, we transfer this component to a location of your choice. Here <your-location> for me was ghcr.io/skarlso/demo-component.

                ocm transfer component ./component-archive <your-location>
 transferring version "ocm.software/podinfo:1.0.2"...
diff --git a/index.xml b/index.xml
index 2fa1e75a..75750d85 100644
--- a/index.xml
+++ b/index.xml
@@ -1,2 +1,2 @@
-Open Component Modelhttps://ocm.software/Recent content on Open Component ModelHugo -- gohugo.ioen© 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/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).Version 3https://ocm.software/docs/component-descriptors/version-3/Tue, 17 Jan 2023 10:22:23 +0000https://ocm.software/docs/component-descriptors/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.About the OCM Projecthttps://ocm.software/docs/overview/about/Tue, 06 Oct 2020 08:48:23 +0000https://ocm.software/docs/overview/about/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.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/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.Important Termshttps://ocm.software/docs/overview/important-terms/Tue, 06 Oct 2020 08:48:23 +0000https://ocm.software/docs/overview/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.Specificationhttps://ocm.software/docs/overview/specification/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/overview/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.Installing the OCM CLIhttps://ocm.software/docs/getting-started/installing-the-ocm-cli/Fri, 12 Aug 2022 10:37:58 +0100https://ocm.software/docs/getting-started/installing-the-ocm-cli/Overview You can install the latest release of the OCM CLI from any of the following sources (more details below):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/This and the following chapters walk you through some basic steps to get started with OCM concepts and the OCM CLI.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/Setting Up Environment Variables For convenience, we will define the following environment variables:
+Open Component Modelhttps://ocm.software/Recent content on Open Component ModelHugo -- gohugo.ioen© 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/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).Version 3https://ocm.software/docs/component-descriptors/version-3/Tue, 17 Jan 2023 10:22:23 +0000https://ocm.software/docs/component-descriptors/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.About the OCM Projecthttps://ocm.software/docs/overview/about/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/overview/about/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.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/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.Important Termshttps://ocm.software/docs/overview/important-terms/Tue, 06 Oct 2020 08:48:23 +0000https://ocm.software/docs/overview/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.Specificationhttps://ocm.software/docs/overview/specification/Mon, 01 Jan 0001 00:00:00 +0000https://ocm.software/docs/overview/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.Installing the OCM CLIhttps://ocm.software/docs/getting-started/installing-the-ocm-cli/Fri, 12 Aug 2022 10:37:58 +0100https://ocm.software/docs/getting-started/installing-the-ocm-cli/Overview You can install the latest release of the OCM CLI from any of the following sources (more details below):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/This and the following chapters walk you through some basic steps to get started with OCM concepts and the OCM CLI.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/Setting Up Environment Variables For convenience, we will define the following environment variables:
 PROVIDER=&#34;acme.org&#34; ORG=&#34;acme&#34; COMPONENT=&#34;github.com/${ORG}/helloworld&#34; VERSION=&#34;1.0.0&#34; CA_ARCHIVE=&#34;ca-hello-world&#34; OCM_REPO=&#34;ghcr.io/&lt;github-org&gt;/ocm&#34; CTF_ARCHIVE=ctf-hello-world
If you specify values for your setup, you can directly use the commands shown in the next steps.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/List Component Versions To show the component stored in a component archive (without looking at the file system structure), the ocm get componentversion command can be used:
\ No newline at end of file
diff --git a/mpas/core_concepts/index.html b/mpas/core_concepts/index.html
index 21865508..428d71ae 100644
--- a/mpas/core_concepts/index.html
+++ b/mpas/core_concepts/index.html
@@ -7,7 +7,7 @@

                Loading search index…

                No recent searches

                No results for "Query here"

                • to select
                • to navigate
                • to close

                Search by FlexSearch

                Core Concepts

                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.

                Product

                A Product is a package of software that can be deployed to target environments such as Kubernetes clusters, -virtual machines or bare-metal devices.

                Products are made available to the MPAS system as OCM Components via a Subscription. +virtual machines or bare-metal devices.

                Products 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.

                A 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.

                A ProductDeploymentGenerator is a Kubernetes Custom Resource that represents a ProductDeployment to be deployed to a Kubernetes cluster. The ProductDeploymentGenerator diff --git a/mpas/getting_started/index.html b/mpas/getting_started/index.html index f0bb2cc6..e3beaf78 100644 --- a/mpas/getting_started/index.html +++ b/mpas/getting_started/index.html @@ -1,17 +1,17 @@ Get Started with MPAS | Open Component Model

                Get Started with MPAS

                This tutorial shows you how to bootstrap MPAS to a Kubernetes cluster and deploy +

                Loading search index…

                No recent searches

                No results for "Query here"

                • to select
                • to navigate
                • to close

                Search by FlexSearch

                Get Started with MPAS

                This tutorial shows you how to bootstrap MPAS to a Kubernetes cluster and deploy a simple application.

                Prerequisites

                • 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.

                To install the MPAS CLI using brew:

                brew install open-component-model/tap/mpas

                For other installation methods, see the installation guide.

                Bootstrap MPAS

                Export your GitHub access token

                The MPAS CLI uses your GitHub access token to authenticate with GitHub. To create a +bootstrap MPAS to a Kubernetes cluster.

                To install the MPAS CLI using brew:

                brew install open-component-model/tap/mpas

                For other installation methods, see the installation guide.

                Bootstrap 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.

                export GITHUB_TOKEN=<your-github-access-token>
 export GITHUB_USER=<your-username>
-export MY_EMAIL=<your-email-address>

                Bootstrap MPAS

                To bootstrap MPAS to your Kubernetes cluster, run the following command. If nothing is specified it will use the KUBECONFIG specified in the user’s environment. It is also possible to specify a dedicated config using the –kubeconfig option.

                mpas bootstrap github \
+export MY_EMAIL=<your-email-address>

                Bootstrap

                To bootstrap MPAS to your Kubernetes cluster, run the following command. If nothing is specified it will use the KUBECONFIG specified in the user’s environment. It is also possible to specify a dedicated config using the –kubeconfig option.

                mpas bootstrap github \
   --owner=$GITHUB_USER \
   --repository=mpas-bootstrap \
   --path=./clusters/my-cluster \
@@ -22,13 +22,13 @@
 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:
                Running mpas bootstrap ...
+reconciles the Project resource.
                The output of the bootstrap is similar to the following:
                Running 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
+ ✓   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
@@ -37,95 +37,94 @@
  ✓   Generating replication-controller manifest with version v0.8.0
  ✓   Generate certificate manifests
  ✓   Reconciling infrastructure components
- ✓   Waiting for components to be ready
+ ✓   Waiting for components to be ready
 
 Bootstrap completed successfully!
                After 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.
                Clone the git repository
                Clone the mpas-bootstrap repository to your local machine:
                git clone https://github.com/$GITHUB_USER/mpas-bootstrap
+be configured to watch the target github repository for changes in the path ./clusters/my-cluster.
                Clone the git repository
                Clone the mpas-bootstrap repository to your local machine:
                git clone https://github.com/$GITHUB_USER/mpas-bootstrap
 cd mpas-bootstrap
                Deploy podinfo application
                The podinfo application has been packaged
-as an OCM component and can be retrieved from Github.
                1. Create a secret containing your GitHub credentials that will be used by MPAS to
-create your project repository.
                kubectl create secret generic \
-  github-access \
-  --from-literal=username=$GITHUB_USER \
-  --from-literal=password=$GITHUB_TOKEN \
-  -n mpas-system
                1. Create a project that will contain the podinfo application.
                Let’s create a directory for the project:
                mkdir -p ./clusters/my-cluster/podinfo
                Then, create a project.yaml file in the ./clusters/my-cluster/podinfo directory:
                mpas 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  >> ./clusters/my-cluster/podinfo/project.yaml
                Then, apply the project to the cluster in a GitOps fashion:
                git add --all && git commit -m "Add podinfo project" && git push
                Flux will detect the changes and apply the project to the cluster.
                This 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’s resources.
                1. Add the needed secrets to the namespace
                Flux is used to deploy all workloads in a GitOps way. Flux needs a secret in
+as an OCM component and can be retrieved from Github.
                1. Create a secret containing your GitHub credentials that will be used by MPAS to create your project repository.
                  kubectl create secret generic \
+github-access \
+--from-literal=username=$GITHUB_USER \
+--from-literal=password=$GITHUB_TOKEN \
+-n mpas-system
                2. Create a project that will contain the podinfo application.
                  Let’s create a directory for the project:
                  mkdir -p ./clusters/my-cluster/podinfo
                  Then, create a project.yaml file in the ./clusters/my-cluster/podinfo directory:
                  mpas 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  >> ./clusters/my-cluster/podinfo/project.yaml
                  Then, apply the project to the cluster in a GitOps fashion:
                  git add --all && git commit -m "Add podinfo project" && git push
                  Flux will detect the changes and apply the project to the cluster.
                  This 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’s resources.
                3. Add the needed secrets to the namespace
                  Flux 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:
                  kubectl create secret generic \
-  github-access \
-  --from-literal=username=$GITHUB_USER \
-  --from-literal=password=$GITHUB_TOKEN \
-  -n mpas-podinfo-application
                  Note The credentials should have access to GitHub packages.
                  As part of step 2, a serviceaccount was created for the project. We will use this service account
+github-access \
+--from-literal=username=$GITHUB_USER \
+--from-literal=password=$GITHUB_TOKEN \
+-n mpas-podinfo-application
                Note The credentials should have access to GitHub packages.
                As 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.
                First, create a secret containing the credentials for the service account:
                kubectl 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
                Then, patch the service account to use the secret:
                kubectl patch serviceaccount mpas-podinfo-application -p '{"imagePullSecrets": [{"name": "github-registry-key"}]}' \
-  -n mpas-podinfo-application
                1. Clone the project repository
                git clone https://github.com/$GITHUB_USER/mpas-podinfo-application
-cd mpas-podinfo-application
                1. Add the podinfo ComponentSubscription
                Create a file under ./subscriptions/ that will contain the subscription declaration.
                mpas create cs podinfo-subscription \
-  --component=ocm.software/mpas/podinfo \
-  --semver=">=v1.0.0" \
-  --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 >> ./subscriptions/podinfo.yaml
                Then, apply the ComponentSubscription to the project in a GitOps fashion:
                git add --all && git commit -m "Add podinfo subscription" && git push
                Flux will detect the changes and apply the subscription to the cluster.
                This 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.
                1. Add a Target for the podinfo application
                The target will define where the application will be installed
                cat <<EOF >> ./targets/podinfo.yaml
+--docker-username=$GITHUB_USER --docker-password=$GITHUB_TOKEN \
+--docker-email=$MY_EMAIL -n mpas-podinfo-application
                Then, patch the service account to use the secret:
                kubectl patch serviceaccount mpas-podinfo-application -p '{"imagePullSecrets": [{"name": "github-registry-key"}]}' \
+-n mpas-podinfo-application
              • Clone the project repository
                git clone https://github.com/$GITHUB_USER/mpas-podinfo-application
+cd mpas-podinfo-application
              • Add the podinfo ComponentSubscription
                Create a file under ./subscriptions/ that will contain the subscription declaration.
                mpas create cs podinfo-subscription \
+--component=ocm.software/mpas/podinfo \
+--semver=">=v1.0.0" \
+--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 >> ./subscriptions/podinfo.yaml
                Then, apply the ComponentSubscription to the project in a GitOps fashion:
                git add --all && git commit -m "Add podinfo subscription" && git push
                Flux will detect the changes and apply the subscription to the cluster.
                This 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.
              • Add a Target for the podinfo application
                The target will define where the application will be installed
                cat <<EOF >> ./targets/podinfo.yaml
 apiVersion: mpas.ocm.software/v1alpha1
 kind: Target
 metadata:
-  name: podinfo-kubernetes-target
-  namespace: mpas-podinfo-application
-  labels:
+name: podinfo-kubernetes-target
+namespace: mpas-podinfo-application
+labels:
     target.mpas.ocm.software/ingress-enabled: "true" # This label is defined by the component that will use it to select an appropriate target to deploy to.
 spec:
-  type: kubernetes
-  access:
+type: kubernetes
+access:
     targetNamespace: podinfo
-  serviceAccountName: podinfo-sa
-  selector:
+serviceAccountName: podinfo-sa
+selector:
     matchLabels:
-      mpas.ocm.software/target-selector: podinfo-kubernetes-target
-  interval: 5m0s
+    mpas.ocm.software/target-selector: podinfo-kubernetes-target
+interval: 5m0s
 EOF
                Then, apply the Target to the project in a GitOps fashion:
                git add --all && git commit -m "Add a target for podinfo" && git push
                Flux will detect the changes and apply the target to the cluster.
                In order for the Target to reach a Ready state, the needed secrets should be created in the podinfo namespace.
                First, create a secret containing the credentials for the service account:
                kubectl 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
                Then, add a label to allow the target to select it using the label selector:
                kubectl label secret github-registry-key mpas.ocm.software/target-selector=podinfo-kubernetes-target -n podinfo
                1. Deploy the podinfo application
                In order to deploy the podinfo application, we need to create a ProductDeploymentGenerator resource:
                mpas create pdg podinfo \
-  --service-account=mpas-podinfo-application \
-  --subscription-name=podinfo-subscription \
-  --subscription-namespace=mpas-podinfo-application  \
-  --namespace=mpas-podinfo-application \
-  --export >> ./generators/podinfo.yaml
                Then, apply the ProductDeploymentGenerator to the project in a GitOps fashion:
                git add --all && git commit -m "Add podinfo deployment generator" && git push
                Flux will detect the changes and apply the resource to the cluster.
                This will create a pull request in the project repository with the ProductDeployment resource
+--docker-username=$GITHUB_USER --docker-password=$GITHUB_TOKEN \
+--docker-email=$MY_EMAIL -n podinfo
                • Then, add a label to allow the target to select it using the label selector:
                kubectl label secret github-registry-key mpas.ocm.software/target-selector=podinfo-kubernetes-target -n podinfo
              • Deploy the podinfo application
                In order to deploy the podinfo application, we need to create a ProductDeploymentGenerator resource:
                mpas create pdg podinfo \
+--service-account=mpas-podinfo-application \
+--subscription-name=podinfo-subscription \
+--subscription-namespace=mpas-podinfo-application  \
+--namespace=mpas-podinfo-application \
+--export >> ./generators/podinfo.yaml
                Then, apply the ProductDeploymentGenerator to the project in a GitOps fashion:
                git add --all && git commit -m "Add podinfo deployment generator" && git push
                Flux will detect the changes and apply the resource to the cluster.
                This will create a pull request in the project repository with the ProductDeployment resource
 that will deploy the podinfo application.
                Go 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.
                Once the pull request is merged, Flux will detect the changes and deploy the application to the cluster.
                After a moment the ProductDeployment should be deployed successfully.
-It is possible to verify this with the command:
                k describe productdeployment -n mpas-podinfo-application
                The result should look something like:
                Name:         podinfo
+It is possible to verify this with the command:
                k describe productdeployment -n mpas-podinfo-application
                The result should look something like:
                Name:         podinfo
 Namespace:    mpas-podinfo-application
-Labels:       kustomize.toolkit.fluxcd.io/name=mpas-podinfo-application-products
-              kustomize.toolkit.fluxcd.io/namespace=mpas-system
+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:
+Conditions:
     Last Transition Time:  2023-09-14T10:14:41Z
     Message:               Reconciliation success
-    Observed Generation:   1
+    Observed Generation:   1
     Reason:                Succeeded
     Status:                True
     Type:                  Ready
-  Observed Generation:     1
                The application is deployed in the podinfo namespace.
                Next
                Installation
                • \ No newline at end of file +Observed Generation: 1

                The application is deployed in the podinfo namespace.

                Next
                Installation
                \ No newline at end of file diff --git a/mpas/installation/index.html b/mpas/installation/index.html index e613adf3..835d6b76 100644 --- a/mpas/installation/index.html +++ b/mpas/installation/index.html @@ -4,4 +4,4 @@

                Installation

                Install using Binaries

                To install the MPAS CLI, you can download the binaries for major platforms from the GitHub releases page.

                Homebrew

                You can also install via homebrew for macOS and Linux:

                brew install open-component-model/tap/mpas

                Bash

                To install with bash for macOS or Linux execute the following command:

                curl -sfL https://raw.githubusercontent.com/open-component-model/mpas/main/install.sh | sh -

                Prev
                Get Started with MPAS
                Next
                Core Concepts
                \ No newline at end of file +

                Loading search index…

                No recent searches

                No results for "Query here"

                • to select
                • to navigate
                • to close

                Search by FlexSearch

                Installation

                Install using Binaries

                To install the MPAS CLI, you can download the binaries for major platforms from the GitHub releases page.

                Homebrew

                You can also install via homebrew for macOS and Linux:

                brew install open-component-model/tap/mpas

                Bash

                To install with bash for macOS or Linux execute the following command:

                curl -sfL https://raw.githubusercontent.com/open-component-model/mpas/main/install.sh | sh -
                Prev
                Get Started with MPAS
                Next
                Core Concepts
                \ No newline at end of file diff --git a/mpas/sitemap.xml b/mpas/sitemap.xml index e506e215..6f86fd30 100644 --- a/mpas/sitemap.xml +++ b/mpas/sitemap.xml @@ -1 +1 @@ -https://ocm.software/mpas/getting_started/2023-11-03T10:53:00+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.5 \ No newline at end of file +https://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.5 \ No newline at end of file diff --git a/search-index.json b/search-index.json index 9d774ff7..ffcf70b6 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":"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).","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":"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.","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":"2020-10-06","id":4,"permalink":"/docs/overview/about/","summary":"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.","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":"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.","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":"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.","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":"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.","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\rInstall 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 .\rBuilding 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":"2022-08-12","id":9,"permalink":"/docs/getting-started/installing-the-ocm-cli/","summary":"Overview You can install the latest release of the OCM CLI from any of the following sources (more details below):","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 topic can be seen by running the OCM CLI help topic command ocm credential-handling.\n","date":"2023-03-13","id":11,"permalink":"/docs/getting-started/getting-started-with-ocm/prerequisites/","summary":"This and the following chapters walk you through some basic steps to get started with OCM concepts and the OCM CLI.","tags":[],"title":"Prerequisites"},{"content":"Setting Up Environment Variables For convenience, we will define the following environment variables:\nPROVIDER=\u0026#34;acme.org\u0026#34; ORG=\u0026#34;acme\u0026#34; COMPONENT=\u0026#34;github.com/${ORG}/helloworld\u0026#34; VERSION=\u0026#34;1.0.0\u0026#34; CA_ARCHIVE=\u0026#34;ca-hello-world\u0026#34; OCM_REPO=\u0026#34;ghcr.io/\u0026lt;github-org\u0026gt;/ocm\u0026#34; CTF_ARCHIVE=ctf-hello-world\rIf you specify values for your setup, you can directly use the commands shown in the next steps. The variable OCM_REPO is set to a location of an OCI registry where artifacts and component descriptors are stored (omitting the https:// prefix). For example, GitHub Packages can be used as an OCI registry. Many other options exist.\nLet\u0026rsquo;s assume that we are creating a component based on a GitHub source repository.\nCreate a Component Archive The first step when creating a new component version is to create a component archive. A component archive contains references, resources, and sources. The ocm CLI tool can help with this.\nWe begin by creating an empty component archive using the command ocm create componentarchive:\nocm create componentarchive ${COMPONENT} ${VERSION} --provider ${PROVIDER} --file $CA_ARCHIVE\rWhat happened? This command creates the following file structure:\nca-hello-world ├── blobs └── component-descriptor.yaml\rThe component descriptor is stored as a yaml file named component-descriptor.yaml. It describes the content of a component version.\nIt contains the following configuration:\nmeta: schemaVersion: v2 component: name: github.com/acme/helloworld version: 1.0.0 provider: acme.org resources: [] sources: [] componentReferences: []\rBy default, the command creates a directory structure. The option --type can be used to select other target formats, such as tar or tgz.\nAdd a Local Resource The next step is ocm add resources. In this example, we want to add the Helm Chart podinfo to the component archive. If you do not have a Helm Chart available locally, you can follow these steps:\nhelm repo add podinfo https://stefanprodan.github.io/podinfo helm pull --untar podinfo/podinfo\rocm add resource $CA_ARCHIVE --type helmChart --name mychart --version ${VERSION} --inputType helm --inputPath ./podinfo\rprocessing resource (by options)... processing document 1... processing index 1 found 1 resources adding resource helmChart: \u0026#34;name\u0026#34;=\u0026#34;mychart\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;1.0.0\u0026#34;...\rWhat happened? The generated file structure is:\nca-hello-world ├── blobs │ └── sha256.2545c7686796c0fbe3f30db26585c61ad51c359cd12d432b5751b7d3be80f1a3 └── component-descriptor.yaml\rThe added blob contains the packaged Helm Chart. The blob is referenced in the component descriptor in component.resources.access.localreference:\nmeta: schemaVersion: v2 component: name: github.com/acme/helloworld version: 1.0.0 provider: acme.org componentReferences: [] repositoryContexts: [] resources: - access: localReference: sha256.2545c7686796c0fbe3f30db26585c61ad51c359cd12d432b5751b7d3be80f1a3 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 sources: []\rBecause we use content from the local environment, it is directly packaged into the component archive using the access method of type localBlob.\nAdd an Image Next, we will add an image. This can be done in one of two ways:\nAdd an Image Reference (Option 1) If the image is already stored in an image registry (e.g., by a previous Docker build/push), you can simply add a reference to it.\nocm add resource $CA_ARCHIVE --type ociArtifact --name image --version ${VERSION} --accessType ociArtifact --reference gcr.io/google_containers/echoserver:1.10\rprocessing resource (by options)... processing document 1... processing index 1 found 1 resources 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 component descriptor now has the following content, with an additional access under component.resources, where access is of type external:\nmeta: schemaVersion: v2 component: name: github.com/acme/helloworld version: 1.0.0 provider: acme.org componentReferences: [] repositoryContexts: [] resources: - access: localReference: sha256.2545c7686796c0fbe3f30db26585c61ad51c359cd12d432b5751b7d3be80f1a3 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: []\rAdd an Image Resource (Option 2) Alternatively, you can add an image as a resource built locally using Docker before. It will be picked up from the local Docker file system and added to the component archive.\ndocker pull gcr.io/google_containers/echoserver:1.10 docker image ls\rREPOSITORY TAG IMAGE ID CREATED SIZE gcr.io/google_containers/echoserver 1.10 365ec60129c5 6 years ago 95.4MB\rocm add resource ${CA_ARCHIVE} --name image --version ${VERSION} --type ociArtifact --inputType docker --inputPath=gcr.io/google_containers/echoserver:1.10\rprocessing resource (by options)... processing document 1... processing index 1 found 1 resources 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;... image gcr.io/google_containers/echoserver:1.10\rWhat happened? The Docker image is downloaded from the Docker daemon, converted to an OCI artifact, and added as local artifact to the component version. The component descriptor now has the content:\nmeta: schemaVersion: v2 component: name: github.com/acme/helloworld version: 1.0.0 provider: acme.org componentReferences: [] repositoryContexts: [] resources: - access: localReference: sha256.55d2bcf1cbf0384175deaa33c8cfc5e5a7cbf23315e6d6643ee2e29cf0973b8c 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: localReference: sha256.d3c2d72fd4e9e04c58f4c420e594afbf7c62b541f5d570460a28e4f3473351a0 mediaType: application/vnd.oci.image.manifest.v1+tar+gzip referenceName: github.com/acme/helloworld/gcr.io/google_containers/echoserver:1.10 type: localBlob digest: ... name: image relation: local type: ociArtifact version: 1.0.0 sources: []\rThe generated blob sha256.d3c2d... is an archive describing the image according to the OCI Image Layout Specification.\nUsing a Resources File You could simplify the previous two steps (adding helm chart and image as resources) by using a text file as input. For that, you could create a file resources.yaml, which looks like this:\n--- name: mychart type: helmChart input: type: helm path: ./podinfo --- name: image type: ociArtifact version: \u0026#34;1.0.0\u0026#34; 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. For 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 should be taken from local resources, the field input is used to specify the access to local resources. In this case, the resource content is directly put into the component archive. Similarly to the access attribute, the kind of the input source is described by the field type. The input types are not part of the input specification but are provided locally by the OCM command line client. For available input types, see ocm add resources.\nFor more complex scenarios, the description files might use variable substitution (templating), see Best Practices.\nAdd the resources using the following command:\nocm add resources $CA_ARCHIVE resources.yaml\rprocessing 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;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;...\rFor a local image built with Docker use this file:\n--- name: mychart type: helmChart input: type: helm path: ./podinfo --- name: image type: ociArtifact version: \u0026#34;1.0.0\u0026#34; input: type: docker path: gcr.io/google_containers/echoserver:1.10\r(Note: If this file is used, the output of the following instructions will differ since another local resource was added.)\nUpload the Component Versions To upload the component version to an OCI registry, you can transfer the component archive using the command ocm transfer componentarchive:\nocm transfer componentarchive ./ca-hello-world ${OCM_REPO}\rtransferring version \u0026#34;github.com/acme/helloworld:1.0.0\u0026#34;... ...resource 0 mychart[helmChart](github.com/acme/helloworld/podinfo:6.7.0)... ...adding component version...\rBundle Composed Components If you have created multiple components according to the instructions above, you can bundle them into a single archive entity. This can be done by creating a transport archive using the common transfer format (CTF).\nThe transport archive is the entity that does the transfer between component repositories. It is used to transfer entire deployments between locations.\nA transport archive may contain any number of component versions. It may also be pushed to an OCM repository.\nNote that a transport archive is also an OCM repository, so it can also be used as source or as a target for transport operations.\nocm transfer componentversion ${CA_ARCHIVE} ${CTF_ARCHIVE}\rtransferring version \u0026#34;github.com/acme/helloworld:1.0.0\u0026#34;... ...resource 0 mychart[helmChart](github.com/acme/helloworld/podinfo:6.7.0)... ...adding component version... 1 versions transferred\rWhat happened? The resulting transport archive has the following file structure:\nctf-hello-world/ ├── artifact-index.json └── blobs ├── sha256.0dd94de11c17f995648c8e817971581bce4b016f53d4d2bf2fff9fcda37d7b95 ├── sha256.4ab29c8acb0c8b002a5037e6d9edf2d657222da76fee2a10f38d65ecd981d0c6 ├── sha256.b2dc5088f005d27ea39b427c2e67e91e2b6b80d3e85eca2476a019003c402904 └── sha256.d3cf4858f5387eaea194b7e40b7f6eb23460a658ad4005c5745361978897e043\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.\nAll in One The previous steps can be combined into a single operation working on a single description file that can contain multiple components:\nCreating a Common Transport Archive Adding one or more components With resources, sources, and references The command ocm add componentversions directly creates or extends a common transport archive without the need for creating dedicated component archives.\nCreate a yaml configuration file component-constructor.yaml, which contains information about the components to create and the elements added to those components. 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).\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: \u0026#34;1.0.0\u0026#34; provider: name: acme.org resources: - name: mychart type: helmChart input: type: helm path: ./podinfo - name: image type: ociArtifact version: \u0026#34;1.0.0\u0026#34; access: type: ociArtifact imageReference: gcr.io/google_containers/echoserver:1.10\rocm add componentversions --create --file ${CTF_ARCHIVE} 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 common-transport-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\r","date":"2023-03-13","id":12,"permalink":"/docs/getting-started/getting-started-with-ocm/create-a-component-version/","summary":"Setting Up Environment Variables For convenience, we will define the following environment variables:\nPROVIDER=\u0026#34;acme.org\u0026#34; ORG=\u0026#34;acme\u0026#34; COMPONENT=\u0026#34;github.com/${ORG}/helloworld\u0026#34; VERSION=\u0026#34;1.0.0\u0026#34; CA_ARCHIVE=\u0026#34;ca-hello-world\u0026#34; OCM_REPO=\u0026#34;ghcr.io/\u0026lt;github-org\u0026gt;/ocm\u0026#34; CTF_ARCHIVE=ctf-hello-world\rIf you specify values for your setup, you can directly use the commands shown in the next steps.","tags":[],"title":"Create a Component Version"},{"content":"List Component Versions To show the component stored in a component archive (without looking at the file system structure), 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 //.\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;\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 component 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":"List Component Versions To show the component stored in a component archive (without looking at the file system structure), the ocm get componentversion command can be used:","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":"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.","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":"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.","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":"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.","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":"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.","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":"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.","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":"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","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":"The ComponentVersion API produces component descriptors for a specific component version.\nExample The following is an example of a ComponentVersion:","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":"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","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":"The ComponentSubscription API produces component descriptors for a specific component version.\nExample The following is an example of a ComponentSubscription:","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":"2022-11-23","id":29,"permalink":"/docs/tutorials/ocm-and-gitops/air-gapped-gitops-with-ocm-flux/","summary":"Introduction In this guide, we will show you how the tools provided by OCM make it possible to automate your air-gapped deployments.","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 blogpost)\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\n$ PROVIDER=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:\n$ PROVIDER=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":"This chapter contains guidelines for common scenarios how to work with the Open Component Model, focusing on using CI/CD, build and publishing processes.","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 resourcres 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":"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.","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 contains configuration options such as PODINFO_UI_COLOR deploy.yaml the deployment configuration. Note that this deployment yaml contains an attribute image that will be configured using the config.yaml explained below. spec: containers: - name: backend image: not-an-image\rkustomization.yaml makes sure only the relevant files are applied service.yaml to expose the service endpoint and make discoverable config.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/v1alpha1 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 this 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":"2023-06-20","id":32,"permalink":"/docs/tutorials/structuring-and-deploying-software-products-with-ocm/","summary":"Introduction In this specification software products are comprised of logical units called components. A component version consists of a set of technical artifacts (e.","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":"2022-11-23","id":33,"permalink":"/docs/tutorials/ocm-and-gitops/deploying-applications-with-ocm-gitops/","summary":"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.","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":"2022-11-23","id":34,"permalink":"/docs/tutorials/ocm-and-gitops/gitops-driven-configuration-of-ocm-applications/","summary":"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.","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 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 as 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 The following list of access types is supported:\ngitHub localBlob ociArtifact ociBlob s3 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.\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":"2023-04-05","id":35,"permalink":"/docs/tutorials/input-and-access-types/","summary":"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.","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.\nOverview This walkthrough deploys a full end-to-end pipeline demonstrating how OCM and Flux can be employed to deploy applications in air-gapped environments.\nThe demo environment consists of Gitea, Tekton, Flux and the OCM controller.\nTwo Gitea organizations are created:\nsoftware-provider software-consumer 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 component and pushes it to the software provider\u0026rsquo;s OCI registry.\nConsumer The software consumer organization models an air-gapped scenario where applications are deployed from a secure OCI registry rather than directly from an arbitrary upstream source.\nThe software consumer organization contains a repository named ocm-applications. During the setup of the demo a PR is created which contains the Kubernetes manifests required to deploy the component published by the software provider.\nOnce this pull request is merged the Flux machinery will deploy the dependency weave-gitops and subsequently the podinfo component. The weave-gitops dashboard 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 Weave GitOps dashboard, accessing the deployed application, applying configuration changes, monitoring the application update, and cutting a new release with updated features.\nThe source code for the demo can be found at https://github.com/open-component-model/demo-secure-delivery\n0. Checkout the source repository git clone https://github.com/open-component-model/demo-secure-delivery \u0026amp;\u0026amp; \\ cd demo-secure-delivery\r1. 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 Weave GitOps Dashboard With a minute or so Flux will reconcile the Weave GitOps component and the dashboard will be accessible at https://weave-gitops.ocm.dev. You can login with username: admin and password password.\n5. View the application We can view the podinfo Helm release that\u0026rsquo;s been deployed in the default namespace: https://weave-gitops.ocm.dev/helm_release/graph?clusterName=Default\u0026amp;name=podinfo\u0026amp;namespace=default\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 and add the following:\npodinfo: replicas: 2 message: \u0026#34;Hello Open Component Model!\u0026#34; serviceAccountName: ocm-ops weave-gitops: 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://weave-gitops.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 Weave 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 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-open-component-model/","summary":"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.\nOverview This walkthrough deploys a full end-to-end pipeline demonstrating how OCM and Flux can be employed to deploy applications in air-gapped environments.","tags":[],"title":"Secure software delivery with Flux and Open Component Model"},{"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":"You can checkout the Project Roadmap on GitHub which is based on issues and PRs from the OCM project repository.","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":"We are here to help you with any questions you have about OCM. Here are a few ways to get support:","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":"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.","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 maintaine 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":"2022-08-12","id":44,"permalink":"/docs/contribution/contributing-guideline/","summary":"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).","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":"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.","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 MPAS 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. kubectl 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. Let\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 Flux 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 git clone https://github.com/$GITHUB_USER/mpas-podinfo-application cd mpas-podinfo-application\rAdd the podinfo ComponentSubscription Create 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 The 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 In 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":"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.","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\nBash 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 -\n","date":"2023-09-12","id":47,"permalink":"/mpas/installation/","summary":"Install using Binaries To install the MPAS CLI, you can download the binaries for major platforms from the GitHub releases page.","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":"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.","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":"The mpas bootstrap command deploys the following components to your cluster:\nFlux: A Kubernetes operator that will install and manage the other components.","tags":[],"title":"Bootstrap"},{"content":"Demo of MPAS\n","date":"2024-04-02","id":50,"permalink":"/mpas/demo_of_mpas/","summary":"Demo of MPAS","tags":[],"title":"MPAS Demo Video"},{"content":"","date":"2024-07-10","id":51,"permalink":"/docs/","summary":"","tags":[],"title":"Docs"},{"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":"2024-04-17","id":52,"permalink":"/docs/cli-reference/add/","summary":"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 ","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/mandelsoft/kubelink $ ocm describe artifact --repo OCIRegistry::ghcr.io mandelsoft/kubelink\rSee Also ocm describe\t— Describe various elements by using appropriate sub commands. ","date":"2024-04-17","id":53,"permalink":"/docs/cli-reference/describe/artifacts/","summary":"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.","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":"2024-04-17","id":54,"permalink":"/docs/cli-reference/download/artifacts/","summary":"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.","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/mandelsoft/kubelink $ ocm get artifact --repo OCIRegistry::ghcr.io mandelsoft/kubelink\rSee Also ocm get\t— Get information about artifacts and components ","date":"2024-04-17","id":55,"permalink":"/docs/cli-reference/get/artifacts/","summary":"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.","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. If 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 oci artifact transfer ghcr.io/mandelsoft/kubelink:v1.0.0 gcr.io $ ocm oci artifact transfer ghcr.io/mandelsoft/kubelink gcr.io $ ocm oci artifact transfer ghcr.io/mandelsoft/kubelink gcr.io/my-project $ ocm oci artifact transfer /tmp/ctf gcr.io/my-project\rSee Also ocm transfer\t— Transfer artifacts or components ","date":"2024-04-17","id":56,"permalink":"/docs/cli-reference/transfer/artifacts/","summary":"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.","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 only happens for local resources. When external image references are transferred (with option \u0026ndash;copy-resources) the mapping 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://v1.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":"2024-04-17","id":57,"permalink":"/docs/cli-reference/help/attributes/","summary":"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).","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":"2024-04-17","id":58,"permalink":"/docs/cli-reference/clean/cache/","summary":"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).","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":"2024-04-17","id":59,"permalink":"/docs/cli-reference/describe/cache/","summary":"Usage ocm describe cache [\u0026lt;options\u0026gt;]\rOptions -h, --help help for cache\rDescription Show details about the OCI blob cache (if given).","tags":[],"title":"cache"},{"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":"2024-04-17","id":60,"permalink":"/docs/cli-reference/check/","summary":"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 ","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":"2024-04-17","id":61,"permalink":"/docs/cli-reference/clean/","summary":"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 ","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":"2024-04-17","id":62,"permalink":"/docs/cli-reference/download/cli/","summary":"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;~/.","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 only happens for local resources. When external image references are transferred (with option \u0026ndash;copy-resources) the mapping 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://v1.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":"2024-04-17","id":63,"permalink":"/docs/cli-reference/","summary":"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.","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;JSON target config) (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.\nIt the option \u0026ndash;overwrite is given, component versions in the target repository will be overwritten, if they already exist, but with different digest. It 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.\nIt the option \u0026ndash;copy-resources is given, all referential resources will potentially be localized, mapped to component version local resources in the target repository. It 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.\nIt 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.\nIt the option \u0026ndash;omit-access-types is given, by-value transfer is omitted completely for the given resource types.\nIt 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/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/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.\nplugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\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.\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":"2024-04-17","id":64,"permalink":"/docs/cli-reference/transfer/commontransportarchive/","summary":"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;JSON target config) (default [])\rDescription Transfer content of a Common Transport Archive to the given target repository.","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":"2024-04-17","id":65,"permalink":"/docs/cli-reference/create/componentarchive/","summary":"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.","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.\nIt the option \u0026ndash;overwrite is given, component versions in the target repository will be overwritten, if they already exist, but with different digest. It 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).\nIt the option \u0026ndash;copy-resources is given, all referential resources will potentially be localized, mapped to component version local resources in the target repository. It 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.\nIt 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":"2024-04-17","id":66,"permalink":"/docs/cli-reference/transfer/componentarchive/","summary":"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.","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 -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) --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;JSON target config) (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 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.\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) All 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.\nIt the option \u0026ndash;copy-resources is given, all referential resources will potentially be localized, mapped to component version local resources in the target repository. It 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/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/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.\nplugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\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.\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":"2024-04-17","id":67,"permalink":"/docs/cli-reference/add/componentversions/","summary":"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 -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) --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;JSON target config) (default []) -v, --version string default version for components\rDescription Add component versions specified by a constructor file to a Common Transport Archive.","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/mandelsoft/kubelink $ ocm get componentversion --repo OCIRegistry::ghcr.io mandelsoft/kubelink\rSee Also ocm check\t— check components in OCM repository ","date":"2024-04-17","id":68,"permalink":"/docs/cli-reference/check/componentversions/","summary":"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.","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":"2024-04-17","id":69,"permalink":"/docs/cli-reference/download/componentversions/","summary":"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.","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/mandelsoft/kubelink $ ocm get componentversion --repo OCIRegistry::ghcr.io mandelsoft/kubelink\rSee Also ocm get\t— Get information about artifacts and components ","date":"2024-04-17","id":70,"permalink":"/docs/cli-reference/get/componentversions/","summary":"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.","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/mandelsoft/kubelink $ ocm list componentversion --repo OCIRegistry::ghcr.io mandelsoft/kubelink\rSee Also ocm list\t— List information about components ","date":"2024-04-17","id":71,"permalink":"/docs/cli-reference/list/componentversions/","summary":"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.","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 mandelsoft --private-key=mandelsoft.key ghcr.io/mandelsoft/kubelink\rSee Also ocm sign\t— Sign components or hashes ","date":"2024-04-17","id":72,"permalink":"/docs/cli-reference/sign/componentversions/","summary":"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.","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;JSON target config) (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.\nIt the option \u0026ndash;overwrite is given, component versions in the target repository will be overwritten, if they already exist, but with different digest. It 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.\nIt the option \u0026ndash;copy-resources is given, all referential resources will potentially be localized, mapped to component version local resources in the target repository. It 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.\nIt 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.\nIt the option \u0026ndash;omit-access-types is given, by-value transfer is omitted completely for the given resource types.\nIt 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/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/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.\nplugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\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.\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/mandelsoft/kubelink ctf.tgz $ ocm transfer components -t tgz --repo OCIRegistry::ghcr.io mandelsoft/kubelink ctf.tgz\rSee Also ocm transfer\t— Transfer artifacts or components ","date":"2024-04-17","id":73,"permalink":"/docs/cli-reference/transfer/componentversions/","summary":"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;JSON target config) (default [])\rDescription Transfer all component versions specified to the given target repository.","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 mandelsoft --public-key=mandelsoft.key ghcr.io/mandelsoft/kubelink\rSee Also ocm verify\t— Verify component version signatures ","date":"2024-04-17","id":74,"permalink":"/docs/cli-reference/verify/componentversions/","summary":"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;~/.","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":"2024-04-17","id":75,"permalink":"/docs/cli-reference/get/config/","summary":"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.","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):\ntype: downloader.ocm.config.ocm.software description: \"my standard download handler configuration\" handlers: - name: oci/artifact artifactType: ociImage mimeType: 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 download handler registrations (see ocm ocm-downloadhandlers):\ntype: uploader.ocm.config.ocm.software description: \"my standard download handler configuration\" handlers: - name: oci/artifact artifactType: ociImage mimeType: config: ... ... 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":"2024-04-17","id":76,"permalink":"/docs/cli-reference/help/configfile/","summary":"Description The command line client supports configuring by a given configuration file. If existent, by default, the file $HOME/.ocmconfig will be read.","tags":[],"title":"configfile"},{"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":"2024-04-17","id":77,"permalink":"/docs/cli-reference/create/","summary":"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 ","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":"2024-04-17","id":78,"permalink":"/docs/cli-reference/help/credential-handling/","summary":"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.","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":"2024-04-17","id":79,"permalink":"/docs/cli-reference/get/credentials/","summary":"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.","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":"2024-04-17","id":80,"permalink":"/docs/cli-reference/describe/","summary":"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 ","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":"2024-04-17","id":81,"permalink":"/docs/cli-reference/download/","summary":"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 ","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":"2024-04-17","id":82,"permalink":"/docs/cli-reference/get/","summary":"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 ","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":"2024-04-17","id":83,"permalink":"/docs/cli-reference/sign/hash/","summary":"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.","tags":[],"title":"hash"},{"content":"Additional Topics attributes\t— attributes configfile\t— configfile credential-handling\t— credential-handling logging\t— logging oci-references\t— oci-references ocm-accessmethods\t— ocm-accessmethods ocm-downloadhandlers\t— ocm-downloadhandlers ocm-labels\t— ocm-labels ocm-pubsub\t— ocm-pubsub ocm-references\t— ocm-references ocm-uploadhandlers\t— ocm-uploadhandlers toi-bootstrapping\t— toi-bootstrapping ","date":"2024-04-17","id":84,"permalink":"/docs/cli-reference/help/","summary":"Additional Topics attributes\t— attributes configfile\t— configfile credential-handling\t— credential-handling logging\t— logging oci-references\t— oci-references ocm-accessmethods\t— ocm-accessmethods ocm-downloadhandlers\t— ocm-downloadhandlers ocm-labels\t— ocm-labels ocm-pubsub\t— ocm-pubsub ocm-references\t— ocm-references ocm-uploadhandlers\t— ocm-uploadhandlers toi-bootstrapping\t— toi-bootstrapping ","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":"2024-04-17","id":85,"permalink":"/docs/cli-reference/list/","summary":"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 ","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/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":"2024-04-17","id":86,"permalink":"/docs/cli-reference/help/logging/","summary":"Description Logging can be configured as part of the ocm config file (ocm configfile) or by command line options of the ocm command.","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":"2024-04-17","id":87,"permalink":"/docs/cli-reference/help/oci-references/","summary":"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.","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 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\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":"2024-04-17","id":88,"permalink":"/docs/cli-reference/help/ocm-accessmethods/","summary":"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.","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:\nocm/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. oci/artifact: 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.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 plugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\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\nSee ocm ocm-downloadhandlers for further details on using download handlers.\nSee Also ","date":"2024-04-17","id":89,"permalink":"/docs/cli-reference/help/ocm-downloadhandlers/","summary":"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.","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":"2024-04-17","id":90,"permalink":"/docs/cli-reference/help/ocm-labels/","summary":"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.","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":"2024-04-17","id":91,"permalink":"/docs/cli-reference/help/ocm-pubsub/","summary":"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.","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":"2024-04-17","id":92,"permalink":"/docs/cli-reference/help/ocm-references/","summary":"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:","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/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/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.\nplugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\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.\nSee ocm ocm-uploadhandlers for further details on using upload handlers.\nSee Also ","date":"2024-04-17","id":93,"permalink":"/docs/cli-reference/help/ocm-uploadhandlers/","summary":"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.","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":"2024-04-17","id":94,"permalink":"/docs/cli-reference/describe/package/","summary":"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.","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":"2024-04-17","id":95,"permalink":"/docs/cli-reference/describe/plugins/","summary":"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.","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":"2024-04-17","id":96,"permalink":"/docs/cli-reference/get/plugins/","summary":"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.","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":"2024-04-17","id":97,"permalink":"/docs/cli-reference/get/pubsub/","summary":"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.","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":"2024-04-17","id":98,"permalink":"/docs/cli-reference/set/pubsub/","summary":"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.","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 --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.\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":"2024-04-17","id":99,"permalink":"/docs/cli-reference/add/references/","summary":"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 --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.","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":"2024-04-17","id":100,"permalink":"/docs/cli-reference/get/references/","summary":"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.","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 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\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":"2024-04-17","id":101,"permalink":"/docs/cli-reference/add/resource-configuration/","summary":"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;,.","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 --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 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\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.\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":"2024-04-17","id":102,"permalink":"/docs/cli-reference/add/resources/","summary":"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;,.","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;JSON target config) (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:\nocm/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. oci/artifact: 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.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 plugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\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\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":"2024-04-17","id":103,"permalink":"/docs/cli-reference/download/resources/","summary":"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;JSON target config) (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;~/.","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":"2024-04-17","id":104,"permalink":"/docs/cli-reference/get/resources/","summary":"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.","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":"2024-04-17","id":105,"permalink":"/docs/cli-reference/add/routingslips/","summary":"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.","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":"2024-04-17","id":106,"permalink":"/docs/cli-reference/get/routingslips/","summary":"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.","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":"2024-04-17","id":107,"permalink":"/docs/cli-reference/create/rsakeypair/","summary":"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.","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":"2024-04-17","id":108,"permalink":"/docs/cli-reference/set/","summary":"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 ","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":"2024-04-17","id":109,"permalink":"/docs/cli-reference/show/","summary":"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) ","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":"2024-04-17","id":110,"permalink":"/docs/cli-reference/sign/","summary":"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 ","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 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\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":"2024-04-17","id":111,"permalink":"/docs/cli-reference/add/source-configuration/","summary":"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;,.","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 --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 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\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.\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":"2024-04-17","id":112,"permalink":"/docs/cli-reference/add/sources/","summary":"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;,.","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":"2024-04-17","id":113,"permalink":"/docs/cli-reference/get/sources/","summary":"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.","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 $ oci show tags ghcr.io/mandelsoft/kubelink\rSee Also ocm show\t— Show tags or versions ","date":"2024-04-17","id":114,"permalink":"/docs/cli-reference/show/tags/","summary":"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.","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":"2024-04-17","id":115,"permalink":"/docs/cli-reference/help/toi-bootstrapping/","summary":"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.","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":"2024-04-17","id":116,"permalink":"/docs/cli-reference/transfer/","summary":"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 ","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":"2024-04-17","id":117,"permalink":"/docs/cli-reference/create/transportarchive/","summary":"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.","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":"2024-04-17","id":118,"permalink":"/docs/cli-reference/get/verified/","summary":"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;~/.","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":"2024-04-17","id":119,"permalink":"/docs/cli-reference/verify/","summary":"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 ","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":"2024-04-17","id":120,"permalink":"/docs/cli-reference/show/versions/","summary":"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.","tags":[],"title":"versions"},{"content":"","date":"2024-04-02","id":121,"permalink":"/mpas/","summary":"","tags":[],"title":"Mpas"},{"content":"","date":"2020-10-06","id":122,"permalink":"/","summary":"","tags":[],"title":"Open Component Model"},{"content":"\r","date":"0001-01-01","id":123,"permalink":"/docs/tutorials/","summary":"\r","tags":[],"title":""},{"content":"","date":"0001-01-01","id":124,"permalink":"/categories/","summary":"","tags":[],"title":"Categories"},{"content":"","date":"0001-01-01","id":125,"permalink":"/contributors/","summary":"","tags":[],"title":"Contributors"},{"content":"","date":"0001-01-01","id":126,"permalink":"/tags/","summary":"","tags":[],"title":"Tags"}] \ 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 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":"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).","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":"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.","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":"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.","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":"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.","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":"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.","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":"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.","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\rInstall 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 .\rBuilding 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":"2022-08-12","id":9,"permalink":"/docs/getting-started/installing-the-ocm-cli/","summary":"Overview You can install the latest release of the OCM CLI from any of the following sources (more details below):","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 topic can be seen by running the OCM CLI help topic command ocm credential-handling.\n","date":"2023-03-13","id":11,"permalink":"/docs/getting-started/getting-started-with-ocm/prerequisites/","summary":"This and the following chapters walk you through some basic steps to get started with OCM concepts and the OCM CLI.","tags":[],"title":"Prerequisites"},{"content":"Setting Up Environment Variables For convenience, we will define the following environment variables:\nPROVIDER=\u0026#34;acme.org\u0026#34; ORG=\u0026#34;acme\u0026#34; COMPONENT=\u0026#34;github.com/${ORG}/helloworld\u0026#34; VERSION=\u0026#34;1.0.0\u0026#34; CA_ARCHIVE=\u0026#34;ca-hello-world\u0026#34; OCM_REPO=\u0026#34;ghcr.io/\u0026lt;github-org\u0026gt;/ocm\u0026#34; CTF_ARCHIVE=ctf-hello-world\rIf you specify values for your setup, you can directly use the commands shown in the next steps. The variable OCM_REPO is set to a location of an OCI registry where artifacts and component descriptors are stored (omitting the https:// prefix). For example, GitHub Packages can be used as an OCI registry. Many other options exist.\nLet\u0026rsquo;s assume that we are creating a component based on a GitHub source repository.\nCreate a Component Archive The first step when creating a new component version is to create a component archive. A component archive contains references, resources, and sources. The ocm CLI tool can help with this.\nWe begin by creating an empty component archive using the command ocm create componentarchive:\nocm create componentarchive ${COMPONENT} ${VERSION} --provider ${PROVIDER} --file $CA_ARCHIVE\rWhat happened? This command creates the following file structure:\nca-hello-world ├── blobs └── component-descriptor.yaml\rThe component descriptor is stored as a yaml file named component-descriptor.yaml. It describes the content of a component version.\nIt contains the following configuration:\nmeta: schemaVersion: v2 component: name: github.com/acme/helloworld version: 1.0.0 provider: acme.org resources: [] sources: [] componentReferences: []\rBy default, the command creates a directory structure. The option --type can be used to select other target formats, such as tar or tgz.\nAdd a Local Resource The next step is ocm add resources. In this example, we want to add the Helm Chart podinfo to the component archive. If you do not have a Helm Chart available locally, you can follow these steps:\nhelm repo add podinfo https://stefanprodan.github.io/podinfo helm pull --untar podinfo/podinfo\rocm add resource $CA_ARCHIVE --type helmChart --name mychart --version ${VERSION} --inputType helm --inputPath ./podinfo\rprocessing resource (by options)... processing document 1... processing index 1 found 1 resources adding resource helmChart: \u0026#34;name\u0026#34;=\u0026#34;mychart\u0026#34;,\u0026#34;version\u0026#34;=\u0026#34;1.0.0\u0026#34;...\rWhat happened? The generated file structure is:\nca-hello-world ├── blobs │ └── sha256.2545c7686796c0fbe3f30db26585c61ad51c359cd12d432b5751b7d3be80f1a3 └── component-descriptor.yaml\rThe added blob contains the packaged Helm Chart. The blob is referenced in the component descriptor in component.resources.access.localreference:\nmeta: schemaVersion: v2 component: name: github.com/acme/helloworld version: 1.0.0 provider: acme.org componentReferences: [] repositoryContexts: [] resources: - access: localReference: sha256.2545c7686796c0fbe3f30db26585c61ad51c359cd12d432b5751b7d3be80f1a3 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 sources: []\rBecause we use content from the local environment, it is directly packaged into the component archive using the access method of type localBlob.\nAdd an Image Next, we will add an image. This can be done in one of two ways:\nAdd an Image Reference (Option 1) If the image is already stored in an image registry (e.g., by a previous Docker build/push), you can simply add a reference to it.\nocm add resource $CA_ARCHIVE --type ociArtifact --name image --version ${VERSION} --accessType ociArtifact --reference gcr.io/google_containers/echoserver:1.10\rprocessing resource (by options)... processing document 1... processing index 1 found 1 resources 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 component descriptor now has the following content, with an additional access under component.resources, where access is of type external:\nmeta: schemaVersion: v2 component: name: github.com/acme/helloworld version: 1.0.0 provider: acme.org componentReferences: [] repositoryContexts: [] resources: - access: localReference: sha256.2545c7686796c0fbe3f30db26585c61ad51c359cd12d432b5751b7d3be80f1a3 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: []\rAdd an Image Resource (Option 2) Alternatively, you can add an image as a resource built locally using Docker before. It will be picked up from the local Docker file system and added to the component archive.\ndocker pull gcr.io/google_containers/echoserver:1.10 docker image ls\rREPOSITORY TAG IMAGE ID CREATED SIZE gcr.io/google_containers/echoserver 1.10 365ec60129c5 6 years ago 95.4MB\rocm add resource ${CA_ARCHIVE} --name image --version ${VERSION} --type ociArtifact --inputType docker --inputPath=gcr.io/google_containers/echoserver:1.10\rprocessing resource (by options)... processing document 1... processing index 1 found 1 resources 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;... image gcr.io/google_containers/echoserver:1.10\rWhat happened? The Docker image is downloaded from the Docker daemon, converted to an OCI artifact, and added as local artifact to the component version. The component descriptor now has the content:\nmeta: schemaVersion: v2 component: name: github.com/acme/helloworld version: 1.0.0 provider: acme.org componentReferences: [] repositoryContexts: [] resources: - access: localReference: sha256.55d2bcf1cbf0384175deaa33c8cfc5e5a7cbf23315e6d6643ee2e29cf0973b8c 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: localReference: sha256.d3c2d72fd4e9e04c58f4c420e594afbf7c62b541f5d570460a28e4f3473351a0 mediaType: application/vnd.oci.image.manifest.v1+tar+gzip referenceName: github.com/acme/helloworld/gcr.io/google_containers/echoserver:1.10 type: localBlob digest: ... name: image relation: local type: ociArtifact version: 1.0.0 sources: []\rThe generated blob sha256.d3c2d... is an archive describing the image according to the OCI Image Layout Specification.\nUsing a Resources File You could simplify the previous two steps (adding helm chart and image as resources) by using a text file as input. For that, you could create a file resources.yaml, which looks like this:\n--- name: mychart type: helmChart input: type: helm path: ./podinfo --- name: image type: ociArtifact version: \u0026#34;1.0.0\u0026#34; 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. For 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 should be taken from local resources, the field input is used to specify the access to local resources. In this case, the resource content is directly put into the component archive. Similarly to the access attribute, the kind of the input source is described by the field type. The input types are not part of the input specification but are provided locally by the OCM command line client. For available input types, see ocm add resources.\nFor more complex scenarios, the description files might use variable substitution (templating), see Best Practices.\nAdd the resources using the following command:\nocm add resources $CA_ARCHIVE resources.yaml\rprocessing 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;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;...\rFor a local image built with Docker use this file:\n--- name: mychart type: helmChart input: type: helm path: ./podinfo --- name: image type: ociArtifact version: \u0026#34;1.0.0\u0026#34; input: type: docker path: gcr.io/google_containers/echoserver:1.10\r(Note: If this file is used, the output of the following instructions will differ since another local resource was added.)\nUpload the Component Versions To upload the component version to an OCI registry, you can transfer the component archive using the command ocm transfer componentarchive:\nocm transfer componentarchive ./ca-hello-world ${OCM_REPO}\rtransferring version \u0026#34;github.com/acme/helloworld:1.0.0\u0026#34;... ...resource 0 mychart[helmChart](github.com/acme/helloworld/podinfo:6.7.0)... ...adding component version...\rBundle Composed Components If you have created multiple components according to the instructions above, you can bundle them into a single archive entity. This can be done by creating a transport archive using the common transfer format (CTF).\nThe transport archive is the entity that does the transfer between component repositories. It is used to transfer entire deployments between locations.\nA transport archive may contain any number of component versions. It may also be pushed to an OCM repository.\nNote that a transport archive is also an OCM repository, so it can also be used as source or as a target for transport operations.\nocm transfer componentversion ${CA_ARCHIVE} ${CTF_ARCHIVE}\rtransferring version \u0026#34;github.com/acme/helloworld:1.0.0\u0026#34;... ...resource 0 mychart[helmChart](github.com/acme/helloworld/podinfo:6.7.0)... ...adding component version... 1 versions transferred\rWhat happened? The resulting transport archive has the following file structure:\nctf-hello-world/ ├── artifact-index.json └── blobs ├── sha256.0dd94de11c17f995648c8e817971581bce4b016f53d4d2bf2fff9fcda37d7b95 ├── sha256.4ab29c8acb0c8b002a5037e6d9edf2d657222da76fee2a10f38d65ecd981d0c6 ├── sha256.b2dc5088f005d27ea39b427c2e67e91e2b6b80d3e85eca2476a019003c402904 └── sha256.d3cf4858f5387eaea194b7e40b7f6eb23460a658ad4005c5745361978897e043\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.\nAll in One The previous steps can be combined into a single operation working on a single description file that can contain multiple components:\nCreating a Common Transport Archive Adding one or more components With resources, sources, and references The command ocm add componentversions directly creates or extends a common transport archive without the need for creating dedicated component archives.\nCreate a yaml configuration file component-constructor.yaml, which contains information about the components to create and the elements added to those components. 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).\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: \u0026#34;1.0.0\u0026#34; provider: name: acme.org resources: - name: mychart type: helmChart input: type: helm path: ./podinfo - name: image type: ociArtifact version: \u0026#34;1.0.0\u0026#34; access: type: ociArtifact imageReference: gcr.io/google_containers/echoserver:1.10\rocm add componentversions --create --file ${CTF_ARCHIVE} 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 common-transport-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\r","date":"2023-03-13","id":12,"permalink":"/docs/getting-started/getting-started-with-ocm/create-a-component-version/","summary":"Setting Up Environment Variables For convenience, we will define the following environment variables:\nPROVIDER=\u0026#34;acme.org\u0026#34; ORG=\u0026#34;acme\u0026#34; COMPONENT=\u0026#34;github.com/${ORG}/helloworld\u0026#34; VERSION=\u0026#34;1.0.0\u0026#34; CA_ARCHIVE=\u0026#34;ca-hello-world\u0026#34; OCM_REPO=\u0026#34;ghcr.io/\u0026lt;github-org\u0026gt;/ocm\u0026#34; CTF_ARCHIVE=ctf-hello-world\rIf you specify values for your setup, you can directly use the commands shown in the next steps.","tags":[],"title":"Create a Component Version"},{"content":"List Component Versions To show the component stored in a component archive (without looking at the file system structure), 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 //.\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;\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 component 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":"List Component Versions To show the component stored in a component archive (without looking at the file system structure), the ocm get componentversion command can be used:","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":"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.","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":"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.","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":"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.","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":"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.","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":"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.","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":"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","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":"The ComponentVersion API produces component descriptors for a specific component version.\nExample The following is an example of a ComponentVersion:","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":"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","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":"The ComponentSubscription API produces component descriptors for a specific component version.\nExample The following is an example of a ComponentSubscription:","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":"2022-11-23","id":29,"permalink":"/docs/tutorials/ocm-and-gitops/air-gapped-gitops-with-ocm-flux/","summary":"Introduction In this guide, we will show you how the tools provided by OCM make it possible to automate your air-gapped deployments.","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":"This chapter contains guidelines for common scenarios how to work with the Open Component Model, focusing on using CI/CD, build and publishing processes.","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":"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.","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 contains configuration options such as PODINFO_UI_COLOR deploy.yaml the deployment configuration. Note that this deployment yaml contains an attribute image that will be configured using the config.yaml explained below. spec: containers: - name: backend image: not-an-image\rkustomization.yaml makes sure only the relevant files are applied service.yaml to expose the service endpoint and make discoverable config.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/v1alpha1 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 this 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":"2023-06-20","id":32,"permalink":"/docs/tutorials/structuring-and-deploying-software-products-with-ocm/","summary":"Introduction In this specification software products are comprised of logical units called components. A component version consists of a set of technical artifacts (e.","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":"2022-11-23","id":33,"permalink":"/docs/tutorials/ocm-and-gitops/deploying-applications-with-ocm-gitops/","summary":"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.","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":"2022-11-23","id":34,"permalink":"/docs/tutorials/ocm-and-gitops/gitops-driven-configuration-of-ocm-applications/","summary":"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.","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 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 as 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 The following list of access types is supported:\ngitHub localBlob ociArtifact ociBlob s3 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.\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":"2023-04-05","id":35,"permalink":"/docs/tutorials/input-and-access-types/","summary":"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.","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.\nOverview This walkthrough deploys a full end-to-end pipeline demonstrating how OCM and Flux can be employed to deploy applications in air-gapped environments.\nThe demo environment consists of Gitea, Tekton, Flux and the OCM controller.\nTwo Gitea organizations are created:\nsoftware-provider software-consumer 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 component and pushes it to the software provider\u0026rsquo;s OCI registry.\nConsumer The software consumer organization models an air-gapped scenario where applications are deployed from a secure OCI registry rather than directly from an arbitrary upstream source.\nThe software consumer organization contains a repository named ocm-applications. During the setup of the demo a PR is created which contains the Kubernetes manifests required to deploy the component published by the software provider.\nOnce this pull request is merged the Flux machinery will deploy the dependency weave-gitops and subsequently the podinfo component. The weave-gitops dashboard 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 Weave GitOps dashboard, accessing the deployed application, applying configuration changes, monitoring the application update, and cutting a new release with updated features.\nThe source code for the demo can be found at https://github.com/open-component-model/demo-secure-delivery\n0. Checkout the source repository git clone https://github.com/open-component-model/demo-secure-delivery \u0026amp;\u0026amp; \\ cd demo-secure-delivery\r1. 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 Weave GitOps Dashboard With a minute or so Flux will reconcile the Weave GitOps component and the dashboard will be accessible at https://weave-gitops.ocm.dev. You can login with username: admin and password password.\n5. View the application We can view the podinfo Helm release that\u0026rsquo;s been deployed in the default namespace: https://weave-gitops.ocm.dev/helm_release/graph?clusterName=Default\u0026amp;name=podinfo\u0026amp;namespace=default\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 and add the following:\npodinfo: replicas: 2 message: \u0026#34;Hello Open Component Model!\u0026#34; serviceAccountName: ocm-ops weave-gitops: 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://weave-gitops.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 Weave 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 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-open-component-model/","summary":"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.\nOverview This walkthrough deploys a full end-to-end pipeline demonstrating how OCM and Flux can be employed to deploy applications in air-gapped environments.","tags":[],"title":"Secure software delivery with Flux and Open Component Model"},{"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":"You can checkout the Project Roadmap on GitHub which is based on issues and PRs from the OCM project repository.","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":"We are here to help you with any questions you have about OCM. Here are a few ways to get support:","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":"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.","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":"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).","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":"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.","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":"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.","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":"Install using Binaries To install the MPAS CLI, you can download the binaries for major platforms from the GitHub releases page.","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":"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.","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":"The mpas bootstrap command deploys the following components to your cluster:\nFlux: A Kubernetes operator that will install and manage the other components.","tags":[],"title":"Bootstrap"},{"content":"Demo of MPAS\n","date":"2024-04-02","id":50,"permalink":"/mpas/demo_of_mpas/","summary":"Demo of MPAS","tags":[],"title":"MPAS Demo Video"},{"content":"","date":"2024-07-10","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":"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 ","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/mandelsoft/kubelink $ ocm describe artifact --repo OCIRegistry::ghcr.io mandelsoft/kubelink\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":"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.","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":"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.","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/mandelsoft/kubelink $ ocm get artifact --repo OCIRegistry::ghcr.io mandelsoft/kubelink\rSee Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":57,"permalink":"/docs/cli-reference/get/artifacts/","summary":"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.","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. If 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 oci artifact transfer ghcr.io/mandelsoft/kubelink:v1.0.0 gcr.io $ ocm oci artifact transfer ghcr.io/mandelsoft/kubelink gcr.io $ ocm oci artifact transfer ghcr.io/mandelsoft/kubelink gcr.io/my-project $ ocm oci artifact transfer /tmp/ctf gcr.io/my-project\rSee Also ocm transfer\t— Transfer artifacts or components ","date":"0001-01-01","id":58,"permalink":"/docs/cli-reference/transfer/artifacts/","summary":"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.","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 only happens for local resources. When external image references are transferred (with option \u0026ndash;copy-resources) the mapping 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://v1.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":"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).","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":"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).","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":"Usage ocm describe cache [\u0026lt;options\u0026gt;]\rOptions -h, --help help for cache\rDescription Show details about the OCI blob cache (if given).","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":"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 ","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":"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 ","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":"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;~/.","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 only happens for local resources. When external image references are transferred (with option \u0026ndash;copy-resources) the mapping 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://v1.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":"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.","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;JSON target config) (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.\nIt the option \u0026ndash;overwrite is given, component versions in the target repository will be overwritten, if they already exist, but with different digest. It 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.\nIt the option \u0026ndash;copy-resources is given, all referential resources will potentially be localized, mapped to component version local resources in the target repository. It 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.\nIt 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.\nIt the option \u0026ndash;omit-access-types is given, by-value transfer is omitted completely for the given resource types.\nIt 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/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/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.\nplugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\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.\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":"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;JSON target config) (default [])\rDescription Transfer content of a Common Transport Archive to the given target repository.","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":"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.","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.\nIt the option \u0026ndash;overwrite is given, component versions in the target repository will be overwritten, if they already exist, but with different digest. It 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).\nIt the option \u0026ndash;copy-resources is given, all referential resources will potentially be localized, mapped to component version local resources in the target repository. It 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.\nIt 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":"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.","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 -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) --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;JSON target config) (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 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.\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) All 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.\nIt the option \u0026ndash;copy-resources is given, all referential resources will potentially be localized, mapped to component version local resources in the target repository. It 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/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/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.\nplugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\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.\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":"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 -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) --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;JSON target config) (default []) -v, --version string default version for components\rDescription Add component versions specified by a constructor file to a Common Transport Archive.","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/mandelsoft/kubelink $ ocm get componentversion --repo OCIRegistry::ghcr.io mandelsoft/kubelink\rSee Also ocm check\t— check components in OCM repository ","date":"0001-01-01","id":71,"permalink":"/docs/cli-reference/check/componentversions/","summary":"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.","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":"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.","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/mandelsoft/kubelink $ ocm get componentversion --repo OCIRegistry::ghcr.io mandelsoft/kubelink\rSee Also ocm get\t— Get information about artifacts and components ","date":"0001-01-01","id":73,"permalink":"/docs/cli-reference/get/componentversions/","summary":"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.","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/mandelsoft/kubelink $ ocm list componentversion --repo OCIRegistry::ghcr.io mandelsoft/kubelink\rSee Also ocm list\t— List information about components ","date":"0001-01-01","id":74,"permalink":"/docs/cli-reference/list/componentversions/","summary":"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.","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 mandelsoft --private-key=mandelsoft.key ghcr.io/mandelsoft/kubelink\rSee Also ocm sign\t— Sign components or hashes ","date":"0001-01-01","id":75,"permalink":"/docs/cli-reference/sign/componentversions/","summary":"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.","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;JSON target config) (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.\nIt the option \u0026ndash;overwrite is given, component versions in the target repository will be overwritten, if they already exist, but with different digest. It 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.\nIt the option \u0026ndash;copy-resources is given, all referential resources will potentially be localized, mapped to component version local resources in the target repository. It 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.\nIt 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.\nIt the option \u0026ndash;omit-access-types is given, by-value transfer is omitted completely for the given resource types.\nIt 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/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/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.\nplugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\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.\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/mandelsoft/kubelink ctf.tgz $ ocm transfer components -t tgz --repo OCIRegistry::ghcr.io mandelsoft/kubelink ctf.tgz\rSee Also ocm transfer\t— Transfer artifacts or components ","date":"0001-01-01","id":76,"permalink":"/docs/cli-reference/transfer/componentversions/","summary":"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;JSON target config) (default [])\rDescription Transfer all component versions specified to the given target repository.","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 mandelsoft --public-key=mandelsoft.key ghcr.io/mandelsoft/kubelink\rSee Also ocm verify\t— Verify component version signatures ","date":"0001-01-01","id":77,"permalink":"/docs/cli-reference/verify/componentversions/","summary":"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;~/.","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":"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.","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):\ntype: downloader.ocm.config.ocm.software description: \"my standard download handler configuration\" handlers: - name: oci/artifact artifactType: ociImage mimeType: 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 download handler registrations (see ocm ocm-downloadhandlers):\ntype: uploader.ocm.config.ocm.software description: \"my standard download handler configuration\" handlers: - name: oci/artifact artifactType: ociImage mimeType: config: ... ... 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":"Description The command line client supports configuring by a given configuration file. If existent, by default, the file $HOME/.ocmconfig will be read.","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":"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 ","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":"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.","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":"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.","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":"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 ","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":"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 ","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":"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 ","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":"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.","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":"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 ","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":"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 ","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/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":"Description Logging can be configured as part of the ocm config file (ocm configfile) or by command line options of the ocm command.","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":"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.","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 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\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":"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.","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:\nocm/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. oci/artifact: 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.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 plugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\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\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":"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.","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":"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.","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":"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.","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":"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:","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/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/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.\nplugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\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.\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":"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.","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":"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.","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":"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.","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":"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.","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":"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.","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":"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.","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 --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.\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":"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 --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.","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":"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.","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 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\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":"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;,.","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 --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 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\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.\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":"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;,.","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;JSON target config) (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:\nocm/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. oci/artifact: 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.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 plugin: [downloaders provided by plugins]\nsub namespace of the form \u0026lt;plugin name\u0026gt;/\u0026lt;handler\u0026gt;\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\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":"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;JSON target config) (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;~/.","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":"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.","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":"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.","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":"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.","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":"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.","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":"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 ","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":"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) ","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":"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 ","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 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\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":"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;,.","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 --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 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\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.\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":"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;,.","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":"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.","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 $ oci show tags ghcr.io/mandelsoft/kubelink\rSee Also ocm show\t— Show tags or versions ","date":"0001-01-01","id":118,"permalink":"/docs/cli-reference/show/tags/","summary":"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.","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":"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.","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":"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 ","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":"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.","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":"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;~/.","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":"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 ","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":"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.","tags":[],"title":"versions"}] \ No newline at end of file diff --git a/sitemap.xml b/sitemap.xml index 8e8e3c65..a2b69e94 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/2020-10-06T08:48:23+00:00monthly0.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/2022-08-12T10:37:58+01:00monthly0.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/2022-11-23T10:00:00+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/2023-06-20T10:00:00+00:00monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/deploying-applications-with-ocm-gitops/2022-11-23T10:00:00+00:00monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/gitops-driven-configuration-of-ocm-applications/2022-11-23T10:00:00+00:00monthly0.5https://ocm.software/docs/tutorials/input-and-access-types/2023-04-05T08:24:35+02:00monthly0.5https://ocm.software/docs/examples/2023-11-07T11:45:27+00:00monthly0.5https://ocm.software/docs/examples/secure-software-delivery-with-flux-and-open-component-model/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/2022-08-12T10:38:22+01:00monthly0.5https://ocm.software/docs/contribution/security-guideline/2022-08-12T10:38:22+01:00monthly0.5https://ocm.software/mpas/getting_started/2023-11-03T10:53:00+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/2024-07-10T08:48:23+00:00monthly0.5https://ocm.software/docs/cli-reference/add/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/describe/artifacts/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/download/artifacts/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/artifacts/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/transfer/artifacts/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/attributes/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/clean/cache/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/describe/cache/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/check/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/clean/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/download/cli/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/transfer/commontransportarchive/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/create/componentarchive/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/transfer/componentarchive/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/check/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/download/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/list/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/sign/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/transfer/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/verify/componentversions/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/config/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/configfile/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/create/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/credential-handling/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/credentials/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/describe/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/download/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/sign/hash/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/list/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/logging/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/oci-references/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/ocm-accessmethods/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/ocm-downloadhandlers/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/ocm-labels/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/ocm-pubsub/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/ocm-references/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/ocm-uploadhandlers/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/describe/package/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/describe/plugins/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/plugins/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/pubsub/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/set/pubsub/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/references/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/references/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/resource-configuration/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/resources/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/download/resources/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/resources/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/routingslips/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/routingslips/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/create/rsakeypair/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/set/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/show/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/sign/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/source-configuration/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/add/sources/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/sources/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/show/tags/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/help/toi-bootstrapping/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/transfer/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/create/transportarchive/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/get/verified/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/verify/2024-04-17T18:02:57+02:00monthly0.5https://ocm.software/docs/cli-reference/show/versions/2024-04-17T18:02:57+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/tutorials/monthly0.5https://ocm.software/categories/monthly0.5https://ocm.software/contributors/monthly0.5https://ocm.software/tags/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/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/2022-08-12T10:37:58+01:00monthly0.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/2022-11-23T10:00:00+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/2023-06-20T10:00:00+00:00monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/deploying-applications-with-ocm-gitops/2022-11-23T10:00:00+00:00monthly0.5https://ocm.software/docs/tutorials/ocm-and-gitops/gitops-driven-configuration-of-ocm-applications/2022-11-23T10:00:00+00:00monthly0.5https://ocm.software/docs/tutorials/input-and-access-types/2023-04-05T08:24:35+02:00monthly0.5https://ocm.software/docs/examples/2023-11-07T11:45:27+00:00monthly0.5https://ocm.software/docs/examples/secure-software-delivery-with-flux-and-open-component-model/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/2024-07-10T08:48:23+00: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