Procedure

1. Create a dedicated directory for your flavor, following a standardized structure. This structure helps the operator identify and process all the components of your flavor:

   flavors/
   └── my-custom-flavor/
       ├── kustomize.yaml
       ├── config/
       │   ├── app-config.yaml
       │   └── plugins/
       │       └── my-plugin.yaml
       ├── resources/
       │   ├── dependencies.yaml
       │   └── catalog/
       │       └── entities.yaml
       └── hooks/
           ├── pre-install/
           │   └── job.yaml
           └── post-install/
               └── job.yaml

   where

   kustomize.yaml

   This is your flavor’s manifest file that acts as the central definition, orchestrating the application of all other files in the directory.

   config/

   Contains the core app-config.yaml for Red Hat Developer Hub, along with any plugin-specific configuration files.

   resources/

   Holds additional Kubernetes resources your flavor needs. This can include CRDs for dependencies or initial catalog entities to populate RHDH.

   hooks/

   Contains manifests for Kubernetes jobs that run before (pre-install) or after (post-install) the RHDH instance is deployed.

2. (Optional) If your flavor uses dynamic plugins that require specific Kubernetes resources, define these resources as YAML manifests in your config/profile/{PROFILE}/plugin-deps directory.
3. (Optional) For dependencies that require operators or other infrastructure, specify them in the plugin-infra directory.
4. (Optional) Write Kubernetes job manifests for any pre-installation or post-installation tasks. The Operator will execute these jobs and monitor their status.

Procedure

1. Create a container image that contains your flavor’s directory structure at a specific location, typically /flavor/. The image should be lightweight and contain only the necessary manifests and files.

   /flavor/
   ├── flavor.yaml             # Flavor manifest
   ├── config/
   ├── resources/
   └── hooks/

2. When the image is built, push it to a container registry which makes the flavor accessible to others, for example:

   podman push quay.io/myorg/my-custom-flavor:1.0.0

3. Users can deploy your custom flavor by referencing the container image directly in their Backstage custom resource. The operator pulls the image, extracts the contents, and applies the configuration automatically. For example:

   apiVersion: backstage.redhat.com/v1alpha1
   kind: Backstage
   metadata:
     name: custom-hub
   spec:
     flavor:
       name: my-custom-flavor
       image: quay.io/myorg/my-custom-flavor:1.0.0