Feature Overview (aka. Goal Summary)

• extend Backstage CR with dynamic plugins configuration (spec.application.dynamicPlugins struct)
• deprecate using spec.application.dynamicPluginsConfigMapName

Goals (aka. expected user outcomes)

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

Requirements (aka. Acceptance Criteria):

• Implement addition to the Backstage CR spec:
  The spec.application.dynamicPlugins must contain:
  a `plugins` list of objects with the following properties:
  `package` the NPM 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)
  `pluginConfig` an optional plugin-specific configuration fragment
  `disabled` an optional boolean to disable the plugin (`false` by default)
  an optional `includes` list of yaml files to include, each file containing a list of plugins.

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

Out of Scope (Optional)

• modifying existed dynamic-plugins format
• changing install plugin script

Customer Considerations (Optional)

Make clear spec.application.dynamicPluginsConfigMapName deprecation process

Documentation Considerations

Make sure needed modifications provided in:

• Upstream doc: https://github.com/redhat-developer/rhdh-operator/blob/main/docs/configuration.md
• Downstream doc: https://docs.redhat.com/en/documentation/red_hat_developer_hub/1.4/html/configuring/provisioning-and-using-your-custom-configuration#provisioning-and-using-your-custom-configuration