Add deployment annotation for Backstage ingestion#43
Conversation
Signed-off-by: Antonia Gaete <agaete@linuxfoundation.org>
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
Disabled knowledge base sources:
WalkthroughThe Deployment template for lfx-v2-query-service was updated to add the Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Pull request overview
Adds metadata intended to enable Spotify Backstage Kubernetes ingestion/discovery for lfx-v2-query-service.
Changes:
- Adds
metadata.labels.app.kubernetes.io/nameto theDeploymentresource in the Helm chart.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| metadata: | ||
| name: lfx-v2-query-service | ||
| namespace: {{ .Release.Namespace }} | ||
| labels: | ||
| app.kubernetes.io/name: {{ .Chart.Name }} |
There was a problem hiding this comment.
PR title/description say Backstage requires a deployment annotation for discovery, but this change adds a standard app.kubernetes.io/name label on the Deployment metadata. If Backstage ingestion is expecting an annotation (or a specific Backstage key like backstage.io/...), this won’t satisfy the stated requirement—please add the correct annotation/key at metadata.annotations (and, if discovery uses labels/selectors, ensure it’s applied to the resources Backstage queries, e.g., Deployment/Service and/or pod template labels as appropriate).
Signed-off-by: Antonia Gaete <agaete@linuxfoundation.org>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@charts/lfx-v2-query-service/templates/deployment.yaml`:
- Around line 9-10: Add the missing Backstage discovery label by updating the
Deployment metadata labels to include the key backstage.io/kubernetes-id; set
its value to a stable unique identifier for the release (for example derived
from the Helm chart/name or the chart helper used elsewhere such as the fullname
helper), alongside the existing app.kubernetes.io/name (refer to the labels
block and Chart.Name in the deployment template) so Backstage can ingest the
workload.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: ac2b22d6-df6e-4142-be17-6d5bacb9f076
📒 Files selected for processing (1)
charts/lfx-v2-query-service/templates/deployment.yaml
| labels: | ||
| app.kubernetes.io/name: {{ .Chart.Name }} |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
For Backstage Kubernetes ingestion, which exact Kubernetes metadata key is required for workload discovery in this case, and must it be an annotation or a label on Deployment metadata?
💡 Result:
The exact Kubernetes metadata key required for workload discovery in Backstage Kubernetes ingestion is backstage.io/kubernetes-id. It must be a label on the Deployment metadata.
Citations:
- 1: https://backstage.io/docs/features/kubernetes/configuration/
- 2: https://www.plural.sh/blog/backstage-kubernetes-plugin-guide/
- 3: https://backstage.io/docs/features/kubernetes/troubleshooting
- 4: https://github.com/backstage/backstage/blob/aeaed8adb31c22e0204b2ac720174f9b4fa15841/plugins/kubernetes-common/src/catalog-entity-constants.ts
- 5: https://backstage.io/api/next/variables/_backstage_plugin-kubernetes-common.KUBERNETES_ANNOTATION.html
- 6: https://backstage.io/docs/next/features/kubernetes/configuration
Backstage requirement unmet: missing the backstage.io/kubernetes-id label.
The PR adds app.kubernetes.io/name for standard Kubernetes labeling, but Backstage Kubernetes ingestion requires a backstage.io/kubernetes-id label on Deployment metadata to discover workloads. Without this label, Backstage ingestion will fail.
Suggested adjustment
metadata:
name: lfx-v2-query-service
namespace: {{ .Release.Namespace }}
labels:
app.kubernetes.io/name: {{ .Chart.Name }}
+ backstage.io/kubernetes-id: {{ .Chart.Name }}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| labels: | |
| app.kubernetes.io/name: {{ .Chart.Name }} | |
| labels: | |
| app.kubernetes.io/name: {{ .Chart.Name }} | |
| backstage.io/kubernetes-id: {{ .Chart.Name }} |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@charts/lfx-v2-query-service/templates/deployment.yaml` around lines 9 - 10,
Add the missing Backstage discovery label by updating the Deployment metadata
labels to include the key backstage.io/kubernetes-id; set its value to a stable
unique identifier for the release (for example derived from the Helm chart/name
or the chart helper used elsewhere such as the fullname helper), alongside the
existing app.kubernetes.io/name (refer to the labels block and Chart.Name in the
deployment template) so Backstage can ingest the workload.
There was a problem hiding this comment.
This label is added on the backstage side, not on the deployment.
There was a problem hiding this comment.
@agaetep, thank you for the clarification! You're right. There are two ways to surface Kubernetes components as part of a Backstage entity. The backstage.io/kubernetes-id annotation can be added to the entity's catalog-info.yaml rather than to the Kubernetes Deployment itself — meaning Backstage-side configuration can handle that mapping without modifying the deployment manifest. My earlier suggestion was incorrect for your setup. The app.kubernetes.io/name label this PR adds is the right approach for your architecture.
(´• ω •`) ʕ•ᴥ•ʔ
✏️ Learnings added
Learnt from: agaetep
Repo: linuxfoundation/lfx-v2-query-service PR: 43
File: charts/lfx-v2-query-service/templates/deployment.yaml:9-10
Timestamp: 2026-04-13T18:55:45.267Z
Learning: For the `lfx-v2-query-service` repository, Backstage Kubernetes ingestion is configured on the Backstage catalog entity side (via `backstage.io/kubernetes-id` annotation in `catalog-info.yaml`), not by adding `backstage.io/kubernetes-id` labels to the Kubernetes Deployment manifest. The Deployment only needs the standard `app.kubernetes.io/name` label for Backstage discovery via label selector.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
Signed-off-by: Antonia Gaete <agaete@linuxfoundation.org>
Spotify Backstage can pull kubernetes data from components using deployment annotations. This service is missing the name annotation needed to discover it.