EPIC Goal

• extend Backstage CR with dynamic plugins configuration (spec.application.dynamicPlugins struct) like:

spec:
  application:
    dynamicPlugins:
      plugins:
        - package: <string>
          integrity: <string, optional>
          disabled: <boolean [true]> - do we need it?
          pluginConfig: <yaml>
      includes:  
        

Where:

• • plugins define plugins with:
    • package: uri of the package to install (either a package name or a path to a local package)
    • integrity: a string containing the integrity hash of the package (optional if package is local, as integrity check is not checked for local packages)
    • disabled: an optional boolean to disable the plugin - Do we need it in this context? Does it make sense to define disabled plugin?
    •  pluginConfig: an optional plugin-specific configuration fragment of app-config
  • includes makes it possible to include some plugin configuration defined externally (such as local file resided in the dynamic plugins init container)

• if spec.application.dynamicPlugins defined - convert it to ConfigMap, mount and use it instead of:
  • (if) defined in default-config/dynamic-plugins.yaml
  • (if) defined in spec.application.dynamicPluginsConfigMapName

• add the same test suite as for spec.application.dynamicPluginsConfigMapName
• deprecate spec.application.dynamicPluginsConfigMapName
• update upstream documentation
• update downstream documentation

Why is this important?

Making dynamic plugins configuration in CR instead of reference to unstructured configMap makes plugins configuration more visible and modification experience more clear and adds *some possibility to validate and fail faster.

Note: validation of pluginConfig and includes is out of scope.

Dependencies (internal and external)

n/a

Acceptance Criteria

Release Enablement/Demo - Provide necessary release enablement details
and documents

DEV - Upstream code and tests merged: <link to meaningful PR or GitHub
Issue>

DEV - Upstream documentation merged: <link to meaningful PR or GitHub
Issue>

DOC - Downstream documentation merged: <link to meaningful PR>