Description

Our custom resources repository, component, resource, and deployer can specify an OCMConfig that refers to a Secret, ConfigMap, or one of our afore-mentioned custom resources. This information is propagated by default. However, a user needs to specify a propagated OCMConfig by specifying the custom resource.

For example:

# Custom resource specifying an OCM configuration through a Secret (propagated by default)
apiVersion: delivery.ocm.software/v1alpha1
kind: Repository
metadata:
  name: basic-auth-repository
spec:
  ...
  ocmConfig:
    - kind: Secret
      name: basic-auth

# Custom resource specifying an OCM configuration through the custom resource repository
apiVersion: delivery.ocm.software/v1alpha1
kind: Component
metadata:
  name: basic-auth-component
spec:
  RepositoryRef: basic-auth-repository
  ...
  ocmConfig:
    - kind: Repository
      apiVersion: delivery.ocm.software/v1alpha1
      name: basic-auth

We want to increase the UX by removing the explicit reference to the propagated OCMConfig as the reference is already set through the RepositoryRef. Hence, users can expect that a custom resource referencing another custom resource will automatically check for OCMConfigs (in their Status field EffectiveOCMConfig) as long as the custom resource does not specify any additional OCMConfig.

This would do the same as the above example:

# Custom resource specifying an OCM configuration through a Secret (propagated by default)
apiVersion: delivery.ocm.software/v1alpha1
kind: Repository
metadata:
  name: basic-auth-repository
spec:
  ...
  ocmConfig:
    - kind: Secret
      name: basic-auth

# Custom resource specifying an OCM configuration through the custom resource repository
apiVersion: delivery.ocm.software/v1alpha1
kind: Component
metadata:
  name: basic-auth-component
spec:
  RepositoryRef: basic-auth-repository
  ...

As this changes the default behaviour of our custom resources, the change is considered a breaking API change.

Done Criteria

• Adjust the function GetEffectiveConfig() with the above-mentioned functionality
  • When no OCMConfig is specified in a Component, Resource, or Deployer, it should check for OCMConfigs in the referenced resource and use that
  • This needs to work for Component, Resource, and Deployer
• Code has been reviewed by other team members
• Analysis of existing tests (Unit and Integration)
• Unit Tests created for new code or existing Unit Tests updated
• Integration Test Suite updated (includes deletion of existing unnecessary Integration Test and/or creation of new ones if required)
• Enduser Documentation updated (if applicable)
• Internal technical Documentation created/updated (if applicable)
• Successful demonstration in Review