Skip to content

EPIC: Argument Interpreter for generated OCM Typed Specifications #544

@jakobmoellerdev

Description

@jakobmoellerdev

Description
What is the goal of this epic?

The goal of this epic is to provide a new, more flexible answer to the problem of mapping arbitrary configuration flags and arguments from the OCM CLI into specifications that work with the OCM binding library.

An example would be the Signature Handler

ocm sign componentversion --signature mysignature --private-key=my.key ghcr.io/open-component-model/ocm//ocm.software/ocmcli:0.17.0 --algorithm sigstore

In this case we want to dynamically register a parser for the sigstore algorithm that can interpret method-specific flags such as a fulcio URL or anything implementation specific. Then we can use that to generate a specification, which we can then use for our binding libraries.

User Story

As an OCM User, I want simple and easy to use flag shortcuts for the most common workflows within the CLI. As such I don't want to have to specify a specification manually but get generated specifications on demand based on input flags.

Scope

Any command wishing to register dynamic flags can do so with a new generic flag called kind. This flag can be used to steer out a plugin interface that offers a translation of any set of arguments given as a plain string into a specification:

Image

By default any command that needs this should by default be implemented by being given a specification.

The commands should then be interpreted with one of 2 versions:

  1. By passing the specification directly with --spec
  2. By using arbitrary arguments after --kind interpreterKind/v1, and be validated / translated by the plugin registered with interpreterKind/v1. Any plugin can choose to implement an interpreter if desired.

Out of Scope

We will (for now) not transition all commands into the new argument interpreter. Instead the EPIC should include one implementation showcasing how we can integrate the handling into an existing command that works with specifications. After this the EPIC needs to include follow up tasks for all outstanding transitions.

This EPIC is supposed to be an infrastructure implementation that we can reuse whenever we dynamically need to register flags.

Possible Usages:

  • Download Blob Filesystem Interpreters in ocm download resource
  • Signing / Verification Handler Flags
  • Any company/organization-specific semantic repository extensions not defined anywhere in OCM.

Metadata

Metadata

Assignees

Labels

area/ipceiImportant Project of Common European Interestkind/epicLarge multi-story topic

Type

No fields configured for Epic.

Projects

Status
🆕 ToDo

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions