backstage/charts

Backstage Helm Charts

Backstage

English | 한국어 | 中文版

What is Backstage?

Backstage is an open source framework for building developer portals. Powered by a centralized software catalog, Backstage restores order to your microservices and infrastructure and enables your product teams to ship high-quality code quickly without compromising autonomy.

Backstage unifies all your infrastructure tooling, services, and documentation to create a streamlined development environment from end to end.

Out of the box, Backstage includes:

• Backstage Software Catalog for managing all your software such as microservices, libraries, data pipelines, websites, and ML models
• Backstage Software Templates for quickly spinning up new projects and standardizing your tooling with your organization’s best practices
• Backstage TechDocs for making it easy to create, maintain, find, and use technical documentation, using a "docs like code" approach
• Plus, a growing ecosystem of open source plugins that further expand Backstage’s customizability and functionality

Backstage was created by Spotify but is now hosted by the Cloud Native Computing Foundation (CNCF) as an Incubation level project. For more information, see the announcement.

Project roadmap

For information about the detailed project roadmap including delivered milestones, see the Roadmap.

Getting Started

To start using Backstage, see the Getting Started documentation.

Documentation

The documentation of Backstage includes:

• Main documentation
• Software Catalog
• Architecture (Decisions)
• Designing for Backstage
• Storybook - UI components

Community

To engage with our community, you can use the following resources:

• Discord chatroom - Get support or discuss the project
• Contributing to Backstage - Start here if you want to contribute
• RFCs - Help shape the technical direction
• FAQ - Frequently Asked Questions
• Code of Conduct - This is how we roll
• Adopters - Companies already using Backstage
• Blog - Announcements and updates
• Newsletter - Subscribe to our email newsletter
• Backstage Community Sessions - Join monthly meetups and explore Backstage community
• Give us a star ⭐️ - If you are using Backstage or think it is an interesting project, we would love a star ❤️

License

Copyright 2020-2024 © The Backstage Authors. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page: https://www.linuxfoundation.org/trademark-usage

Licensed under the Apache License, Version 2.0: http://www.apache.org/licenses/LICENSE-2.0

Security

Please report sensitive security issues using Spotify's bug-bounty program rather than GitHub.

For further details, see our complete security release process.

charts's Issues

feat: provide integration with external secrets operator to prevent credentials being committed to config files

commonLabels does not add the labels to pods

I want to see the status of Backstage Kubernetes resources inside Backstage, so I added the label backstage.io/kubernetes-id: backstage to commonLabels value. After deploying, the label was added to the Deployment, Ingress and Service object, but it was not present in the Pod object created by the Deployment. Thus, the pod information itself is not present in Backstage.

🚀 Feature: Add resource limit support

As a standard best practice we should enable folks to limit the amount of resources that can be consumed by the pods that are being loaded/run.

Inconvenient plugin installation process in the helm chart

Hello!
Problem:
At this moment all plugins install to dir in ephemeral storage /app/packages of the backstage container, in this case data will be lost after restart. I can't persist this directory also via k8s pvc, backstage files will be overriten.
In addition after installing the plugin through yarn, you also need to add some typescript files, which is also not very convenient.
Question:
Is there any normal way to install backstage plugins in helm version?

Chore: Set up proper CI/CD and test workflows

Convert CI/CD we have in https://github.com/janus-idp/helm-backstage and setup a chart testing pipeline.

NetworkPolicy values do nothing

Hey team,

we have following values available in the chart:

charts/charts/backstage/values.yaml

Lines 254 to 272 in 5ea59d3

	networkPolicy:
	# -- networkPolicy.enabled Specifies whether a NetworkPolicy should be created
	enabled: false
	externalAccess:
	from: []
	# -- Custom network policy rule
	egressRules:
	# -- Additional custom egress rules
	# e.g:
	# customRules:
	# - to:
	# - namespaceSelector:
	# matchLabels:
	# label: example
	customRules: []

However, they do nothing when enabled. We don't have a template for them either. Is this something we've missed during the initial chart forming/transfer? Do we need those values?

We can either remove those values so we don't confuse users or add the missing template.

cc @vinzscam since you know the most about the chart and its history before it was donated to backstage org.

Changelog

Awesome work and great to see all the improvements to the repo!

I would love to see formatted changelogs for releases, like a list of merged PRs, to quickly spot any potential breaking changes. Especially since they can happen pretty frequent in the 0.x.x time of development

Add Helm Charts to ArtifactHub

Artifact Hub is a web-based application that enables finding, installing, and publishing packages and configurations for CNCF projects.

Add the Helm chart and other Backstage related efforts to ArtifactHub

• Determine individual who should drive effort
• Determine artifacts that should be added
  • Repository based helm chart
  • OCI based artifact
• Implement necessary configurations to enable Artifact Hub integrations
  • Helm Charts
  • Container Images

bug: extraDeploy is defined as a value under values.yaml but there is no implementation

Hello,

extraDeploy is defined under values.yaml but there is no implementation around it: https://github.com/backstage/charts/blob/main/charts/backstage/values.yaml#L38-L39

Seems like this helm chart is following Bitnami's chart structure (together with Bitnami's common), so it would be a matter of creating a new template file as such: https://github.com/bitnami/charts/blob/main/bitnami/argo-cd/templates/extra-list.yaml.

Add tests for postgres scenarios where external secret is involude

I get scared when I see postgres auth secret values getting changed 😆, mainly because of past stress of trying to satisfy all of the scenarios that tend to cause regression to other values if not done right. Do we have good tests to ensure that when certain values are set, the correct Deployment yaml is generated? As theres a few conditional branches in that backstage.postgresql.databaseSecretKey function. If not, would be good to get these in another time if possible. Will allow us to change any code in this area with increased confidence in future.

I will add though, changes lgtm 👍

Originally posted by @ChrisJBurns in #154 (comment)

CORS errors when using ingress - Failed to load entity kinds

Trying Helm charts with ingress and postgresql.enabled: true!

Getting "Failed to load entity kinds".

Access to fetch at 'http://localhost:7007/api/catalog/entity-facets?facet=kind' from origin 'https://backstage.mydomain.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

It's working of I do port forwarding directly to K8S SVC. (http://localhost:7007/)

Tried adding CORS config in value file-> appConfig, but then POD is not starting.. error: Backend failed to start up Error: Missing required config value at 'backend.database'

POD log:
Loaded config from app-config-from-configmap.yaml, env
{"level":"info","message":"Found 1 new secrets in config that will be redacted","service":"backstage"}
{"level":"info","message":"Created UrlReader predicateMux{readers=azure{host=dev.azure.com,authed=false},bitbucketCloud{host=bitbucket.org,authed=false},github{host=github.com,authed=false},gitlab{host=gitlab.com,authed=false},awsS3{host=amazonaws.com,authed=false},fetch{}","service":"backstage"}
Backend failed to start up Error: Missing required config value at 'backend.database'
at ConfigReader.getConfig (/app/node_modules/@backstage/config/dist/index.cjs.js:130:13)
at ObservableConfigProxy.select (/app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:105:41)
at ObservableConfigProxy.getString (/app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:158:17)
at DatabaseManager.getClientType (/app/node_modules/@backstage/backend-common/dist/index.cjs.js:971:36)
at DatabaseManager.getConfigForPlugin (/app/node_modules/@backstage/backend-common/dist/index.cjs.js:1043:29)
at /app/node_modules/@backstage/backend-common/dist/index.cjs.js:1083:14

backstage.image.tag doesn't work

I'm using the below values. It seems to be attempting to retrieve image with the tag 'latest', as seen in the warning message below. However, there is no image with the 'latest' tag, and it is not successfully pulling the correct image with tag 'x.x.x'.

backstage:
  image:
    registry: private.repo
    repository: backstage/backstage
    tag: x.x.x

  Warning  Failed          12s (x2 over 31s)  kubelet            Failed to pull image "private.repo/backstage/backstage:latest": rpc error: code = Unknown desc = Error response from daemon: manifest for private.repo/backstage/backstage:latest not found: manifest unknown: Requested image not found

After having a look at https://github.com/backstage/charts/blob/main/charts/backstage/templates/backstage-deployment.yaml#L63 it looks like backstage.image.tag isn't in use here.

Add option to add RBAC Role and bindings required for kubernetes plugin

Hi!

I think the chart should optionally include the ClusterRole from the documentation : https://backstage.io/docs/features/kubernetes/configuration#role-based-access-control
And create associated ClusterRoleBinding

Gitlab Auth: Authentication failed, Failed to obtain access token

I am running into the following error when attempting to authenticate to backstage using the Gitlab Auth Provider

This is my app-config:

  image:
    debug: true
    tag: 1.14.0
  appConfig:
    app:
      title: BDSF
      baseUrl: https://backstage.bigbang.dev
    organization:
      name: BDSF
    backend:
      auth:
        keys:
          - secret: ${X}
      baseUrl: https://backstage.bigbang.dev
      listen:
        port: 7007
      csp:
        connect-src: ["'self'", 'http:', 'https:']
      cors:
        origin: https://backstage.bigbang.dev
        methods: [GET, HEAD, PATCH, POST, PUT, DELETE]
        credentials: true
      database:
        client: better-sqlite3
        connection: ':memory:'
      cache:
        store: memory
    integrations:
      gitlab:
        - host: gitlab.bigbang.dev
          token: ${X}
          apiBaseUrl: https://gitlab.bigbang.dev/api/v4
          baseUrl: https://gitlab.bigbang.dev
    gitlab:
      defaultCodeOwnersPath: CODEOWNERS
      allowedKinds: ['Component', 'Resource']
    sonarqube:
      baseUrl: https://sonarqube.bigbang.dev
      apiKey: ${X}
    techdocs:
      builder: 'local' # Alternatives - 'external'
      generator:
        runIn: 'local' # Alternatives - 'local'
      publisher:
        type: 'local' # Alternatives - 'googleGcs' or 'awsS3'. Read documentation for using alternatives.
    auth:
      environment: development
      providers:
        gitlab:
          development:
            clientId: ${X}
            clientSecret: ${X}
            audience: https://gitlab.bigbang.dev
    scaffolder:
    catalog:
      providers:
        gitlab:
          yourProviderId:
            host: gitlab.bigbang.dev
            schedule:
              frequency: { minutes: 5 }
              timeout: { minutes: 3 }
      import:
        entityFilename: catalog-info.yaml
        pullRequestBranchName: backstage-integration
      rules:
        - allow: [Component, System, API, Resource, Location]
      locations:
        - type: file
          target: ../../examples/entities.yaml
        - type: file
          target: ../../examples/template/template.yaml
          rules:
            - allow: [Template]
        - type: file
          target: ../../examples/org.yaml
          rules:
            - allow: [User, Group]

Assume ${X} is replaced with the correct key for each field. I can't seem to make heads or tails if it's coming from the gitlab side of things, or if it's coming from the gitlab backend integration.

Would really appreciate any pointers or suggestions to tackle this.

Attached are some relevant screenshots

Publish the chart to ArtifactHub

With #92 I've laid a foundation for publishing this chart through mainstream channels. I would like this chart to be available and indexed by the most common search engine for helm charts out there - Artifact Hub.

On ArtifactHub I was able to find numerous other Backstage helm charts including ours. Our chart is published there by an unrelated party.

https://artifacthub.io/packages/helm/backstage/backstage

We can claim this chart through the official Ownership claim process. Before we do that, I'd like to see if we can get @christianknell to transfer the chart to us on his own initiative. 🙂

feat: add auth provider config to Helm chart

Hi there,

I'd like to request the option to configure auth providers like Keycloak in the Helm chart

Cheers

🚀 Feature: Make it possible to set securityContext

🔖 Feature description
The current chart doesn't have any securityConext settings on the deployment. It would be great to have the ability to set securityContext.

🎤 Context
I have the need that pods/containers need to run as non-root and have read only root file system.

✌️ Possible Implementation
on backstage-deployment.yaml template file.

spec:
  template:
    spec:
       containers:
          ......
{{- if .Values.backstage.securityContext }}
          securityContext:
            {{- toYaml .Values.backstage.securityContext | nindent 12 }}
{{- end }}
         ......

Add external database setup to helm chart

Right now you can setup pgsql setting only if {{- if .Values.postgresql.enabled }} which means deployment of bitnami pg chart.
It would be great to have an extra option like "use external postgres" which would allow you to put pg settings there.

Cors errors using port-forward on the service

Hi,
i try to install Backstage using this values file:

---

  backstage:
    replicas: 1
    image:
      registry: ghcr.io
      repository: backstage/backstage
      tag: 1.14.2

    resources:
      limits:
        memory: 1Gi
      requests:
        memory: 250Mi
        cpu: 100m

    # TODO: https://github.com/backstage/charts/pull/84
    # affinity:
    #   nodeAffinity:
    #     requiredDuringSchedulingIgnoredDuringExecution:
    #       nodeSelectorTerms:
    #         - matchExpressions:
    #             - key: monitoring
    #               operator: In
    #               values:
    #                 - 'true'
    #             - key: topology.kubernetes.io/zone
    #               operator: In
    #               values:
    #                 - eu-west-1a

    extraEnvVars:
    - name: GITLAB_TOKEN
      valueFrom:
        secretKeyRef:
          name: backstage
          key: gitlab-token

    appConfig:
      app:
        title: Backstage POC
        baseUrl: http://localhost:3000
      
      organization:
        name: POC

      backend:
        baseUrl: http://localhost:7007
        listen:
          port: 7007
          # host: 0.0.0.0
        
        csp:
          connect-src: ["'self'", 'http:', 'https:']
        cors:
          origin: http://localhost:3000
          methods: [GET, POST, PUT, DELETE]
          credentials: true
        database:
          client: pg
          connection:
            host: ${POSTGRES_HOST}
            port: ${POSTGRES_PORT}
            user: ${POSTGRES_USER}
            password: ${POSTGRES_PASSWORD}
      
      integrations:
        gitlab:
          - host: gitlab.com
            token: ${GITLAB_TOKEN}

      # auth:
      #   environment: development
      #   providers:
      #     okta:
      #       development:
      #         clientId: ${AUTH_OKTA_CLIENT_ID}
      #         clientSecret: ${AUTH_OKTA_CLIENT_SECRET}
      #         audience: ${AUTH_OKTA_DOMAIN}
      #         authServerId: ${AUTH_OKTA_AUTH_SERVER_ID} # Optional
      #         idp: ${AUTH_OKTA_IDP} # Optional

      techdocs:
        requestUrl: http://0.0.0.0:7000/api/techdocs
        storageUrl: http://0.0.0.0:7000/api/techdocs/static/docs
        builder: 'local'
        generators:
          techdocs: 'docker'
        publisher:
          type: 'local'

      catalog:
        readonly: true
        rules:
          - allow: [Component, API, System, Domain, Resource, Location, User, Group]
        locations:
          - type: url
            target: https://gitlab.com/xxxxxx/-/blob/feat/backstage-app/backstage/backstage/dev/org.yaml
          - type: url
            target: https://gitlab.com/xxxxxx/-/blob/feat/backstage-app/backstage/backstage/dev/domains.yaml
          - type: url
            target: https://gitlab.com/xxxxxx/-/blob/feat/backstage-app/backstage/backstage/dev/systems.yaml
          - type: url
            target: https://gitlab.com/xxxxxx/-/blob/feat/backstage-app/backstage/backstage/dev/components.yaml
        # providers:
        #   gitlab:
        #     GitLab:
        #       host: gitlab.com
        #       schedule:
        #         frequency:
        #           minutes: 60
        #         timeout:
        #           minutes: 10

  metrics:
    serviceMonitor:
      enabled: true

  postgresql:
    enabled: true
    global:
      storageClass: gp2-resize
    auth:
      username: backstage
      database: backstage
      existingSecret: backstage
      secretKeys:
        adminPasswordKey: admin-password
        userPasswordKey: user-password
        replicationPasswordKey: replication-password
    architecture: standalone
    metrics:
      enabled: true
      resources:
        limits:
          memory: 300Mi
        requests:
          memory: 50Mi
          cpu: 100m
      serviceMonitor:
        enabled: true
      prometheusRule:
        enabled: true
        rules: []

Application seems running,

Loaded config from app-config-from-configmap.yaml, env
17
{"level":"info","message":"Found 2 new secrets in config that will be redacted","service":"backstage"}
16
{"level":"info","message":"Created UrlReader predicateMux{readers=azure{host=dev.azure.com,authed=false},bitbucketCloud{host=bitbucket.org,authed=false},github{host=github.com,authed=false},gitlab{host=gitlab.com,authed=true},awsS3{host=amazonaws.com,authed=false},fetch{}","service":"backstage"}
15
{"level":"info","message":"Performing database migration","plugin":"catalog","service":"backstage","type":"plugin"}
14
{"level":"info","message":"Catalog is running in readonly mode","plugin":"catalog","service":"backstage","type":"plugin"}
13
{"level":"info","message":"Configuring \"database\" as KeyStore provider","plugin":"auth","service":"backstage","type":"plugin"}
12
{"level":"warn","message":"The 'techdocs.generators.techdocs' configuration key is deprecated and will be removed in the future. Please use 'techdocs.generator' instead. See here https://backstage.io/docs/features/techdocs/configuration","plugin":"techdocs","service":"backstage","type":"plugin"}
11
{"level":"info","message":"Creating Local publisher for TechDocs","plugin":"techdocs","service":"backstage","type":"plugin"}
10
{"level":"info","message":"Added DefaultCatalogCollatorFactory collator factory for type software-catalog","plugin":"search","service":"backstage","type":"plugin"}
9
{"level":"info","message":"Added DefaultTechDocsCollatorFactory collator factory for type techdocs","plugin":"search","service":"backstage","type":"plugin"}
8
{"level":"info","message":"Starting all scheduled search tasks.","plugin":"search","service":"backstage","type":"plugin"}
7
{"level":"info","message":"Serving static app content from /app/packages/app/dist","plugin":"app","service":"backstage","type":"plugin"}
6
{"level":"info","message":"Injecting env config into module-backstage.dd2063e0.js","plugin":"app","service":"backstage","type":"plugin"}
5
{"level":"info","message":"Task worker starting: search_index_software_catalog, {\"version\":2,\"cadence\":\"PT10M\",\"initialDelayDuration\":\"PT3S\",\"timeoutAfterDuration\":\"PT15M\"}","service":"backstage","task":"search_index_software_catalog","type":"taskManager"}
4
{"level":"info","message":"Task worker starting: search_index_techdocs, {\"version\":2,\"cadence\":\"PT10M\",\"initialDelayDuration\":\"PT3S\",\"timeoutAfterDuration\":\"PT15M\"}","service":"backstage","task":"search_index_techdocs","type":"taskManager"}
3
{"level":"info","message":"Storing 283 updated assets and 0 new assets","plugin":"app","service":"backstage","type":"plugin"}
2
{"level":"info","message":"Listening on :7007","service":"backstage"}
1
{"level":"info","message":"::ffff:10.222.7.156 - - [12/Jun/2023:07:31:59 +0000] \"GET /metrics HTTP/1.1\" 200 - \"-\" \"Prometheus/2.37.0\"","service":"backstage","type":"incomingRequest"}

but when i open the main view, i've got these errors on the javascript console :

Access to fetch at 'http://localhost:7007/api/catalog/entities/by-refs' from origin 'http://127.0.0.1:7007' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
index.esm.js:1687     POST http://localhost:7007/api/catalog/entities/by-refs net::ERR_FAILED
(anonymous) @ index.esm.js:1687
await in (anonymous) (async)
(anonymous) @ index.esm.js:1726
getEntitiesByRefs @ index.esm.js:112
await in getEntitiesByRefs (async)
(anonymous) @ index.esm.js:893
(anonymous) @ useAsyncFn.js:21
(anonymous) @ useAsync.js:12
nf @ react-dom.production.min.js:262
T.unstable_runWithPriority @ scheduler.production.min.js:18
Ze @ react-dom.production.min.js:122
je @ react-dom.production.min.js:261
Si @ react-dom.production.min.js:243
(anonymous) @ react-dom.production.min.js:123
T.unstable_runWithPriority @ scheduler.production.min.js:18
Ze @ react-dom.production.min.js:122
ao @ react-dom.production.min.js:123
R @ scheduler.production.min.js:16
O.port1.onmessage @ scheduler.production.min.js:12
api-docs:1 Access to fetch at 'http://localhost:7007/api/catalog/entity-facets?facet=kind' from origin 'http://127.0.0.1:7007' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
index.esm.js:1687     GET http://localhost:7007/api/catalog/entity-facets?facet=kind net::ERR_FAILED 200 (OK)
(anonymous) @ index.esm.js:1687
await in (anonymous) (async)
(anonymous) @ index.esm.js:1726
requestOptional @ index.esm.js:349
await in requestOptional (async)
getEntityFacets @ index.esm.js:235
(anonymous) @ index.esm.js:626
(anonymous) @ useAsyncFn.js:21
(anonymous) @ useAsync.js:12
nf @ react-dom.production.min.js:262
T.unstable_runWithPriority @ scheduler.production.min.js:18
Ze @ react-dom.production.min.js:122
je @ react-dom.production.min.js:261
Si @ react-dom.production.min.js:243
(anonymous) @ react-dom.production.min.js:123
T.unstable_runWithPriority @ scheduler.production.min.js:18
Ze @ react-dom.production.min.js:122
ao @ react-dom.production.min.js:123
R @ scheduler.production.min.js:16
O.port1.onmessage @ scheduler.production.min.js:12
api-docs:1 Access to fetch at 'http://localhost:7007/api/catalog/entity-facets?facet=metadata.tags' from origin 'http://127.0.0.1:7007' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
index.esm.js:1687     GET http://localhost:7007/api/catalog/entity-facets?facet=metadata.tags net::ERR_FAILED 200 (OK)
(anonymous) @ index.esm.js:1687
await in (anonymous) (async)
(anonymous) @ index.esm.js:1726
requestOptional @ index.esm.js:349
await in requestOptional (async)
getEntityFacets @ index.esm.js:235
(anonymous) @ index.esm.js:1515
(anonymous) @ useAsyncFn.js:21
(anonymous) @ useAsync.js:12
nf @ react-dom.production.min.js:262
T.unstable_runWithPriority @ scheduler.production.min.js:18
Ze @ react-dom.production.min.js:122
je @ react-dom.production.min.js:261
Si @ react-dom.production.min.js:243
(anonymous) @ react-dom.production.min.js:123
T.unstable_runWithPriority @ scheduler.production.min.js:18
Ze @ react-dom.production.min.js:122
ao @ react-dom.production.min.js:123
R @ scheduler.production.min.js:16
O.port1.onmessage @ scheduler.production.min.js:12
api-docs:1 Access to fetch at 'http://localhost:7007/api/catalog/entities?filter=kind=api' from origin 'http://127.0.0.1:7007' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
index.esm.js:1687     GET http://localhost:7007/api/catalog/entities?filter=kind=api net::ERR_FAILED 200 (OK)
(anonymous) @ index.esm.js:1687
await in (anonymous) (async)
(anonymous) @ index.esm.js:1726
requestRequired @ index.esm.js:340
await in requestRequired (async)
getEntities @ index.esm.js:79
loading @ index.esm.js:356
(anonymous) @ useAsyncFn.js:21
(anonymous) @ useTimeoutFn.js:15
setTimeout (async)
(anonymous) @ useTimeoutFn.js:13
nf @ react-dom.production.min.js:262
T.unstable_runWithPriority @ scheduler.production.min.js:18
Ze @ react-dom.production.min.js:122
je @ react-dom.production.min.js:261
(anonymous) @ react-dom.production.min.js:261
R @ scheduler.production.min.js:16
O.port1.onmessage @ scheduler.production.min.js:12

Use upstream Backstage image in CI

Replace:

charts/charts/backstage/ci/ci-values.yaml

Lines 2 to 5 in 55e12fd

	image:
	registry: ghcr.io
	repository: janus-idp/redhat-backstage-build
	tag: latest

With pointer to upstream up-to-date image.

See also: #8 (comment)

Generate/create a proper json schema

Proper chart should have a JSON schema, we should define one for this chart.

https://helm.sh/docs/topics/charts/#schema-files

Contribution Docs

Is probably a good idea that we add some contribution docs that folks can follow. We add some checkboxes on the PR workflow, but wondering if we need to be a bit more explicit so by the time PR's are raised, the necessary things have been done.

Possible something like I've done here: https://github.com/pact-foundation/pact-broker-chart/blob/master/CONTRIBUTING.md

with ingress fails to install chart due to invalid spec

minikube@earth ~> cat values.yml
ingress:
  enabled: true
  host: "test"

minikube@earth ~> helm upgrade -f values.yml my-backstage backstage/backstage
W1209 12:51:58.794453   34716 warnings.go:70] unknown field "spec:rules"
Error: UPGRADE FAILED: failed to create resource: Ingress.extensions "my-backstage" is invalid: spec: Invalid value: []networking.IngressRule(nil): either `defaultBackend` or `rules` must be specified

just trying to test a local deployment and coming across ingress configuration issue. not quite sure how to resolve it. any guidance?

Make clear that people are expected to provide their own backstage image before deploying

A quick search around Discord tells me there's some confusion around how this Helm chart should be used.

People often think this Helm Chart is a drop-in solution to create a developer portal when in fact is expected that people have followed the getting started guide and used npx @backstage/create-app@latest at least once.

Some threads with examples of people using the Helm Chart with the default image:

• (EN) https://discord.com/channels/687207715902193673/995973463208644678/1079458729809944656
• (EN) https://discord.com/channels/687207715902193673/1076510953123893321/1076520344296366100
• (PT-BR) https://discord.com/channels/687207715902193673/1024692900325511198/1065602691696431124

Is there plans to update this chart to deploy front end and back end images separately?

It seems that it's a common standard to break services into separate images but this helm chart is limited by the ability to deploy a single combined image.

Cant force login

Hello, i configured the chart as follow in a testing environment:

backstage:
  appConfig:
    integrations:
      github:
        - host: github.com
          token: supersecretdata

    auth:
      environment: development
      providers:
        github:
          development:
            clientId: supersecretdata
            clientSecret: supersecretdata

and every time i go the url configured, i automatically login as a guest (like everyone else.)
but if i go in settings, auth provider, and i click login on github i can login as a github user (and in the app nothing changes)

What am i doing wrong? how do i enforce the login from github beforehand?
Thanks for your help.

Is this chart still maintaining?

https://artifacthub.io/packages/helm/backstage/backstage

I tring to deploy the backstage on K8S with this official helm chart with kubeapps, but is seems not ok.

Postgresql Connectivity Error : Backend failed to start up Error: Failed to connect to the database.....

Hi, I am facing a problem while connecting the backstage app (deploy with kubernetes) to Azure PostgreSQL.

Below is the error while K8 deployment running...

Backend failed to start up Error: Failed to connect to the database to make sure that 'backstage_plugin_catalog' exists, error: no pg_hba.conf entry for host*******

Already follow this document https://backstage.io/docs/tutorials/configuring-plugin-databases#postgresql
and here is my pg client configuration in app-config.yaml

  database:
    client: pg
    connection:
      host: ${POSTGRES_HOST}
      port: ${POSTGRES_PORT}
      user: ${POSTGRES_USER}
      password: ${POSTGRES_PASSWORD}

Really appreciate any help or suggestions on the correct configuration or documentation when it comes to the Cloud Base PostgreSQL database.

Thanks in advance :)

Backstage helm chart testing on Rosa Openshift cluster

Following steps listed in the documentation to install:

$ helm version
version.BuildInfo{Version:"v3.11.2", GitCommit:"912ebc1cd10d38d340f048efaf0abda047c3468e", GitTreeState:"clean", GoVersion:"go1.18.10"}
$  helm repo add bitnami https://charts.bitnami.com/bitnami
"bitnami" has been added to your repositories
$ helm repo add backstage https://backstage.github.io/charts
"backstage" has been added to your repositories
# Verify that repos are added
$ helm repo list
NAME      URL
sigstore  https://sigstore.github.io/helm-charts
bitnami   https://charts.bitnami.com/bitnami
backstage https://backstage.github.io/charts

Something that was never clear to me installing these charts is finding the release version, no matter what I tried it would not accept it as a value, giving this error: Release "<release_var>" does not exist. Examples of things I tried for <release_var>`:

• backstage-0.20.0
• 0.20.0
• v0.20.0

Each time it would fail the install:

$ helm list --output yaml
- app_version: ""
  chart: backstage-0.20.0
  name: 0.20.0
  namespace: janus-idp
  revision: "1"
  status: failed
  updated: 2023-04-03 08:16:27.99776 -0700 PDT
- app_version: ""
  chart: backstage-0.20.0
  name: backstage-0.20.0
  namespace: janus-idp
  revision: "1"
  status: failed
  updated: 2023-04-03 08:16:41.582456 -0700 PDT

When checking pods on the Rosa cluster in the janus-idp namespace, I saw that every installation attempted to create a singular pod that would suffer from a CrashLoopBackOff. It would pull the latest image (ghcr.io/backstage/backstage:latest), and produce the following error in the pod logs:

node:internal/modules/cjs/loader:1024
throw err;
^
Error: Cannot find module '/app/packages/backend'
at Function.Module._resolveFilename (node:internal/modules/cjs/loader:1021:15)
at Function.Module._load (node:internal/modules/cjs/loader:866:27)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
at node:internal/main/run_main_module:22:47 {
code: 'MODULE_NOT_FOUND',
requireStack: []
}

I then tried to not specify a release name:

helm install backstage/backstage --generate-name
NAME: backstage-1680536283
LAST DEPLOYED: Mon Apr  3 08:38:05 2023
NAMESPACE: janus-idp
STATUS: deployed
REVISION: 1
TEST SUITE: None

However pod suffers from the same MODULE_NOT_FOUND issue as above. I tried deleting the namespace and recreating in case any ReplicaSets, Deploments, or any other manifests were cached. After properly uninstalling the charts and running helm list to verify this:

$ helm install backstage/backstage --generate-name
W0403 08:50:34.646389   25799 warnings.go:70] would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "backstage-backend" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "backstage-backend" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "backstage-backend" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "backstage-backend" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
NAME: backstage-1680537031
LAST DEPLOYED: Mon Apr  3 08:50:33 2023
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

However no pods were created / exist in the cluster. More testing to follow.
/cc @tumido

About setting app-config.yaml

Hi,

I have a question regarding setting app-config.yaml.

So basically, I can set it with 'APP_CONFIG_'in the values.yaml of the Helm chart, but how should I set object-array valuables?

For example,

  gitlab:
    - host: gitlab.com
      token: ${GITLAB_TOKEN}

Thanks in advance!

You must configure atleast one key in backend.auth.keys for production

I just tried to clone the chart repo and deployed this backstage helm chart without making any change and getting this error.
Please could you suggest the following 2 queries

1. How can i configure and run in a development environment instead of production?
2. What configuration is required to resolve this issue?

**_Error Message:

"level":"warn","message":"You should NOT be using the guest provider outside of a development environment.","plugin":"auth","service":"backstage"}
/app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:1486
throw new Error(
^

Error: Failed to instantiate service 'core.tokenManager' for 'search' because the factory function threw an error, Error: Failed to instantiate service 'core.tokenManager' because createRootContext threw an error, Error: You must configure at least one key in backend.auth.keysfor production._**
at /app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:1486:17
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async BackendInitializer.getInitDeps_fn (/app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:1649:20)
at async /app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:1784:32
at async processNode (/app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:1307:22)
at async Promise.all (index 0)
at async processMoreNodes (/app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:1302:7)
at async _DependencyGraph.parallelTopologicalTraversal (/app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:1313:5)
at async /app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:1782:9
at async Promise.all (index 7)
at async BackendInitializer.doStart_fn (/app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:1762:3)
at async BackendInitializer.start (/app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:1616:5)
at async BackstageBackend.start (/app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:1886:5)

Requesting your help in getting this resolved. Looking forward to hear from you

Installing chart fails

Tried to install this chart with the following helmfile.yaml:

helmDefaults:
  wait: true
  waitForJobs: true
  atomic: true
  timeout: 90

repositories:
- name: backstage
  url:  https://backstage.github.io/charts

releases:
- name: backstage
  namespace: backstage
  chart: backstage/backstage

My pod is crashing with the following error message:

Loading config from MergedConfigSource{FileConfigSource{path="/app/app-config.yaml"}, EnvConfigSource{count=1}}
{"level":"info","message":"Found 1 new secrets in config that will be redacted","service":"backstage"}
{"level":"info","message":"Listening on :7007","service":"rootHttpRouter"}
/app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:1496
          throw new Error(
                ^

Error: Failed to instantiate service 'core.httpRouter' for 'app' because the factory function threw an error, Error: Failed to instantiate service 'core.auth' for 'app' because the factory function threw an error, Error: Failed to instantiate service 'core.tokenManager' for 'app' because the factory function threw an error, Error: Failed to instantiate service 'core.tokenManager' because createRootContext threw an error, Error: You must configure at least one key in backend.auth.keys for production.
    at /app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:1496:17
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async _ServiceRegistry.initializeEagerServicesWithScope (/app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:1427:11)
    at async /app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:1768:7
    at async Promise.all (index 0)
    at async BackendInitializer.doStart_fn (/app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:1766:3)
    at async BackendInitializer.start (/app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:1626:5)
    at async BackstageBackend.start (/app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:1894:5)

Node.js v18.20.2

Chart version: 1.9.2

Using ghcr.io/backstage/backstage:1.15.0 image works.

Issue - Offline Helm Chart Setup

Hi Team,

I am trying to install this chart offline without configuring the bitnami repo. Getting error as below

Error: INSTALLATION FAILED: template: backstage/templates/service.yaml:4:11: executing "backstage/templates/service.yaml" at <include "common.names.fullname" .>: error calling include: template: no template "common.names.fullname" associated with template "gotpl

Please can you help with providing some offline version to deploy helm charts and get backstage up and running as well?

Thanks & REgards,
Sri

Insllation error

HI,

I tried to install the chart and use the latest version of it, however I got an error:
Error: INSTALLATION FAILED: execution error at (backstage/templates/backstage-deployment.yaml:1:61): The repository name of the image is required (e.g. my-backstage:tag | docker.io/my-backstage:tag) !
I took the vanilla chart and didnt do any modification yet, any idea why? should I provide my own image, this is a bit strange as most of the K8S charts that I installed didn't require something when you install the default, any idea?

Btw, is there a quick way to overcome this ?

Values Schema cannot be validated in Air-Gapped Environment

I am currently trying to deploy this chart in an air-gapped environment but the values.schema.json contains external internet references as mentioned in #92.

Due to the air-gapped environment I cannot even resolve the hostname:

Error: values don't meet the specifications of the schema(s) in the following chart(s):
backstage:
Get "https://kubernetesjsonschema.dev/master/_definitions.json": dial tcp: lookup kubernetesjsonschema.dev on x.x.x.x:53: no such host

To my knowledge there is currently no way to skip the schema validation. helm/helm#10398

My current workaround is to remove the values.schema.json and repackage the chart in my environment.

I think ideally the Helm chart should be fully self contained.

integration opportunity discussion

Hi Vincenzo Scamporlino,
Referring to you as I see you are the main contributor.
I work at AWS. I would be interested in discussing the status of the chart and the opportunity of integration with some of our open source projects. I reached out directly on Linkedin, please let me know.
Thanks.

include integration config file

is there a way to include GitHub integration config file via secretref?
Description: https://backstage.io/docs/integrations/github/github-apps#including-in-integrations-config

seems include function is only possible with configMap - https://github.com/backstage/charts/tree/main/charts/backstage#pass-extra-configuration-files

thank you!

feat: Add appVersion in helm chart

Allow this helm chart to be a dependency of an other one by specifying appVersion in Chart.yml

🚀 Feature: Make it possible to enabled TLS on ingress

🔖 Feature description
The current chart doesn't have any TLS setting on the ingress. It would be great to have the ability to enable TLS

🎤 Context
I have the need for data that is in transit must be encrypted.

✌️ Possible Implementation
on ingress.yaml template file.

{{- if .Values.ingress.tls.enabled }}
  tls:
    - hosts:
      - {{ .Values.ingress.host }}
      secretName: {{ .Values.ingress.tls.secretName }}
{{- end -}}

Add kubernetes startup probe

It's currently not possible to configure a startup probe in the helm chart for backstage. readiness and liveness were previous add in #101

Allow the ingress host name to be interpreted as a template value

Would it be possible to change the ingress.yaml rules.host and tls.hosts to interpret the value as a template?

For example:

rules:
    - host: {{- include "common.tplvalues.render" ( dict "value" Values.ingress.host "context" $) | nindent 4 }}   

In my values.yaml file, I would like to do the following:

ingress: 
      enabled: true
      host: '{{- print .Release.Name "-" .Release.Namespace -}}.apps.example.com'

I have multiple environments (dev, test, staging) where I would like to use the release name and namespace as part of the host name.

Thank you.

Add kubernetes probes

It is currently not possible to configure a readiness/liveness probe in the helm chart for backstage. I can work on this if we are okay with the addition of readiness/liveness probe configuration

Failed to load entity kinds issue when port-forward backstage service

Hi Team,

I am trying to utilise this helm chart with only setting postgresql.enabled:true in my custom values.yaml. Both postgres and backstage pods are running fine but when I do kubectl port-forward svc/my-backstage :7007 and try to access my backstage front-end, getting below error highlighted in screenshot. Can someone please advise on the same? can't see anything suspicious in logs of backstage pod logs except below 304 status code message.
Message in backstage log:
{"level":"info","message":"::ffff:127.0.0.1 - - [20/Dec/2022:20:14:05 +0000] \"GET /catalog HTTP/1.1\" 200 - \"-\" \"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.99 Safari/537.36\"","service":"backstage","type":"incomingRequest"} {"level":"info","message":"::ffff:127.0.0.1 - - [20/Dec/2022:20:14:05 +0000] \"GET /favicon.ico HTTP/1.1\" 304 - \"-\" \"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.99 Safari/537.36\"","service":"backstage","type":"incomingRequest"}

Request for Documentation Improvement

@sabre1041 motivated to create a separate issue for my comment in #140

Citing:

I would like to add that maybe a common assumptions of Helm charts are, that they mostly work out of the box. The backstage Helm chart however needs a ton of very detailed customisations, which are not well documented.

I am personally missing the following information in the documentation of the Helm chart:

• What do I need to do, to get a basic Backstage up and running?
• Where can I find example Helm chart values, that result in a working deployment?
• How do I implement sourcecode changes of Backstage (as intended by the backstage documentation) in a Helm chart deployment, without having to build a customised container image?
• Is there a reference documentation of all configurable options of the backstage configuration file/environment?

I consider myself an experienced Kubernetes person and I am trying hard to use this Helm chart to «just» get Backstage deployed. Not even talking about it even being configured in a meaningful way.

Following current documentation does not result into a usable Backstage instance.