backstage-cr_skill

This skill helps you create and modify Backstage CRs for the rhdh-operator, guiding you through version selection and resource validation.

Shell

0

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill kadel/claude-plugins --skill backstage-cr

SKILL.md3.0 KB

Overview

This skill generates and modifies Backstage Custom Resources (CR) for the rhdh-operator to deploy and manage Red Hat Developer Hub (RHDH) on Kubernetes/OpenShift. It guides choosing API versions, configuring application settings, database options, routing, monitoring, and dynamic plugins. Use it to produce validated YAML CRs that match the requested rhdh.redhat.com API version and operator expectations.

How this skill works

The skill asks or defaults to an API version (v1alpha5 by default), collects requirements (database, route, plugins, monitoring, deployment kind), and consults the corresponding reference spec. It generates a minimal or full Backstage CR YAML, including appConfig, database configuration, route settings, monitoring, and deployment fields, and checks for referenced ConfigMaps/Secrets. It also supports strategic workload patches and dynamic plugin ConfigMap references.

When to use it

When you need a new Backstage CR for rhdh-operator (create Backstage CR).
When configuring RHDH operator deployment options (deployment.kind, replicas, workload patch).
When switching between local operator-managed DB and external DB secrets.
When enabling Routes, TLS, or OpenShift-specific networking.
When adding or updating dynamic plugins, app-config ConfigMaps, or extra files/envs.

Best practices

Confirm desired API version up front; default is rhdh.redhat.com/v1alpha5.
Prefer enableLocalDb:false with authSecretName for production external DBs; use local DB only for dev.
Keep dynamic plugins in a dedicated ConfigMap and reference it via dynamicPluginsConfigMapName.
Validate that all referenced ConfigMaps and Secrets exist in the target namespace before applying.
Use deployment.patch for minimal changes to underlying workload and deployment.kind to choose Deployment or StatefulSet (v1alpha5).

Example use cases

Generate minimal Backstage CR YAML with local PostgreSQL and Route enabled.
Create CR for production with enableLocalDb:false and external DB auth secret.
Add dynamic plugins by creating a plugins ConfigMap and updating dynamicPluginsConfigMapName in the CR.
Enable monitoring by setting monitoring.enabled:true for v1alpha4 or later.
Patch workload using deployment.patch to inject additional env or volumes without replacing operator-managed settings.

FAQ

Ask which features you need; default is v1alpha5. Use v1alpha4 if you need monitoring added, or v1alpha3 only for legacy compatibility.

How do I use an external database?

Set spec.application.database.enableLocalDb:false and provide spec.application.database.authSecretName referencing a Secret with connection credentials.

How can I add dynamic plugins?

Create a ConfigMap with plugin definitions, set spec.application.dynamicPluginsConfigMapName to that ConfigMap, and ensure the operator can read it.