Story

• As a user, I wish to see the Janus IDP related themes within the Backstage Showcase app.

Description

• Backstage allows for the default themes to be overridden allowing users to customize the look and feel of their app. We can leverage this to create themes focused around our brand.

AC

• Implement the agreed upon themes that were decided by the Janus IDP team.

Additional Notes

• We will need to have some conversations around how we want the Backstage Showcase app to look and feel.

Story

• As a user, I wish to be able to view the issues that are currently present in my GitHub repositories.

Description

• The GitHub plugin allows users to view any issues that have been created within their GitHub repositories. This allows them to quickly identify any problem from within the Backstage app.

AC

• Add the GitHub Issues plugin to the Backstage Showcase app
• Able to visualize the issues within the catalog page
• Update the catalog-info.yaml file to allow for GitHub issues to be surfaced within the Backstage Showcase app
• Document the GitHub specific process for deployment

Additional Notes

• Will require the GitHub Authentication Provider to be implemented within the Backstage Showcase app.

From version: 1.0.2
To version: 1.0.3

Story

• As a user, I wish to be able to use Keycloak Authentication and the Keycloak Plugin within the Backstage Showcase app.

Description

• Keycloak is an identity and access management tool. The purpose of this story is to add the Keycloak plugin to the Backstage Showcase app. In addition to adding the Keycloak plugin, we will begin the implementation of authentication starting with a login page.

ACs

• Add the Keycloak plugin to the Backstage Showcase app
• Able to sign into Backstage Showcase app using an account created within Keycloak
• Visualize the users and groups that were created within Keycloak in the Backstage Showcase Catalog
• Document the Keycloak specific process for deployment

Additional Notes

• None

What do you want to improve?

Optimize Dockerfile to run faster. We have many contributions and it takes a long time to get feedback, merge and deploy.

What is the current behavior?

The build time was already too long and doubled in the last week.

What is the new behavior?

Build faster. Much faster

⚠️ Is this a breaking change?

Put an x in the boxes that apply

• Yes
• No
• Don't know

What do you want to improve?

We should build Showcase only when the code is updated. Not the Techdocs documentation.

What is the current behavior?

We are building Showcase everytime there is a code change.

What is the new behavior?

Don't trigger a build if the change is in the docs folder. The docs will be generate with another GitHub Action

⚠️ Is this a breaking change?

Put an x in the boxes that apply

• Yes
• No
• Don't know

And add a new tab to the Entity page

Once the build is done, ArgoCD does not trigger a deployment of the latest image.

Story

• As a user, I wish to see an example of the Backstage Showcase app running within OperateFirst.

Description

• To better showcase the app, we should have an instance of it running within OperateFirst. This can help to better show the value that Backstage and our Janus IDP plugins have to offer.

AC

• An instance of the Backstage Showcase app running on OperateFirst
• Documentation on how to deploy to OperateFirst for future reference

Additional Notes

• None so far

Story

• As a developer, I would like to better understand the purpose of the Backstage Showcase app.

Description

• We should expanded up our documentation to allow members of the community to better understand the Backstage Showcase app. This should include information on contributing to the project (creating issues, pull requests), an updated README (outlining the purpose of the app and links to additional documentation), how to get started with the app, and more.

AC

• Updated README to explain the purpose of the app
• Contribution documentation

Additional Notes

• This will need more refinement to better capture what all we will be looking for.

Story

• As a user, I wish to be able to view information about the clusters that I have available to me using the Open Cluster Management plugin within Backstage

Description

• The Open Cluster Management plugin allows users the ability to see information about their available clusters. Using OCM, we can view information about clusters as well as access them straight from the Backstage app.

AC

• OCM plugin added to the Backstage Showcase app
• View cluster related information within the Backstage Showcase app
• Document the OCM specific process for deployment

Additional Notes

• Will require the Kubernetes plugin to be implemented within the Backstage Showcase app

Originally, we updated the Dockerfile to find a way to decrease the length of time that it takes to build an image. In some instances it would take up to an hour for the build to complete. This was causing issues whenever we are trying to continually iterate changes within the project. However, due our removal of fix-permissions within the Dockerfile, we are now getting an error whenever we attempt to deploy to an OpenShift cluster.

There are currently some conversations being had about how best to update the Dockerfile from redhat-backstage-build. Once those conversations have been concluded we should update the Docker file in backstage-showcase to mirror the Dockerfile from redhat-backstage-build.

Add to a new 'Topology' tab in the entity page

Once the permission to Quay is resolved, we need to do the following tasks:

• Update the GitHub Action to push the image to quay.io instead of GitHub registry.
• Use the image from Quay to deploy the showcase app in the ArgoCD manifest.
• Update the annotation in the catalog-info.yaml file.

What do you want to improve?

We should be able to customize the ArgoCD url in the app-config.yaml config file.

What is the current behavior?

Currently the url is hardcoded in the app-config.yaml:
target: https://argocd.operate-first.cloud/api/v1/

What is the new behavior?

The app-config should have something like:
target: ${ARGOCD_URL}

⚠️ Is this a breaking change?

Put an x in the boxes that apply

• Yes
• No
• Don't know

Still in alpha but we should check what's new
https://backstage.io/docs/features/software-templates/testing-scaffolder-alpha/

Do we have to update/migrate the existing templates?

What happened?

There is an issue where we are unable to log in via GitHub within the showcase app. This is leading to most of the GitHub plugins being unavailable.

What are the steps to reproduce this issue?

1. Navigate to the showcase app
2. Go to the catalog
3. Select backstage-showcase
4. Attempt to log in
5. See “User not found”

Browser affected

Put an x in the boxes that apply

• All
• Chrome
• Safari
• Edge
• Firefox

We only support the last 2 major versions.

Devices affected

Put an x in the boxes that apply

• All
• Desktop
• Tablet
• Phone

Attach any related screenshots, if any.

What do you want to improve?

We would like to deploy the showcase app using different configurations for different environments.

What is the current behavior?

Currently, the showcase app is being deployed on Operate First using the base configuration in the manifests directory. This leads to problems when deploying because we are unable to ensure that the showcase app will work whenever new changes are introduced.

What is the new behavior?

We update the manifests to include new environments for deployment. This will also allow us to go in and clean up some of our manifests as they are currently pieced together to get the showcase app up and running.

Some initial ideas for the configurations include:

• Prod
• QA - where we can run tests on the recent changes
• Dev - where we can potentially test PRs manually

⚠️ Is this a breaking change?

Put an x in the boxes that apply

• Yes
• No
• Don't know

Special Notes

Need to reach out to members of Operate First to ensure we are able to have multiple namespaces
We would need to figure out how we wish to promote from one environment to another

Story

• As a user, I wish to be able to visualize Kubernetes resources within the Backstage Showcase app using the Kubernetes plugin.

Description

• The Kubernetes plugin allows us to view Kubernetes resources that are running within a cluster. Using the plugin in conjuction with the annotation/label "backstage.io/kubernetes-id", one can visualize that resource within the catalog.

AC

• Add the Kubernetes plugin to the Backstage Showcase app
• Able to visualize Kubernetes resources running within a cluster in the Backstage Showcase app
• Update the catalog-info.yaml file to be able to surface the Backstage Showcase app running within a cluster.
• Document the Kubernetes specific process for deployment

Additional Notes

• This is needed before we introduce the OCM plugin

What do you want to improve?

Reduce the GitHub action execution time

What is the current behavior?

We are not using caching

What is the new behavior?

Use caching to improve execution time on most of the steps in the different GitHub Actions with actions/cache save and restore

⚠️ Is this a breaking change?

Put an x in the boxes that apply

• Yes
• No
• Don't know

The current deployment will make the showcase app unavailable for a few minutes. The environment should always be available for customers, demo, etc

Add the homepage plugin to the showcase app

Customize the homepage to display the Janus links

Externalize the data in a json file to be able to update it later on without having to redeploy

Use the GitHub issue template to create a skeleton when a user is creating a new issue for bug, feature request or enhance an existing feature. The issue input will be consistent and contains the required information.

What do you want to improve?

What is the current behavior?

What is the new behavior?

⚠️ Is this a breaking change?

Put an x in the boxes that apply

• Yes
• No
• Don't know

Goal

The build used to take around 10 minutes which is a long time. It now takes at least 20 minutes. The goal is to optimize the build and reduce it to only 2-3 minutes.

Acceptance criteria

• Showcase built should take only 2-3 minutes.

Issues in Epic

• #131
• #132
• #55
• #133
• #139

High level tasks:

• Configure Techdocs
• Add a onboarding section
• Add a dev section with points 1, 2 and 3 from https://docs.google.com/document/d/17Jt3_G6l5TsbNE6lqB7ldDYlvqzbylGdVIhO0QEB6YI/edit#heading=h.gjdgxs & also https://docs.google.com/document/d/1TZjzw3dVWGA3U57wUzxczrjDV6wVvNe-8rPe5rJSQHM/edit#
• Add a platform engineer section(how to update homepage, software template, techradar

What do you want to improve?

Enable the github org processor, to automatically import developers and groups from github org members and github org teams.
Please refer to this document: https://backstage.io/docs/integrations/github/org

⚠️ Is this a breaking change?

Put an x in the boxes that apply

• Yes
• No
• Don't know

Acceptance criteria

We currently have 3 issue templates for bugs, new features and enhancements.

To be consistent and make sure we have all the required information in the issues, we need similar templates for the kinds:

• security (quick description, CVE link, severity)
• dependency upgrade (library name, from which version to which version)
• chore (what has to be done, which part of the project, related to another tool (GH Actions, etc)
• epic (description, links to all related issues)
• documentation (new section in documentation, updating documentation)

Since moved from the Overview tab, the card is not showing up.

What do you want to improve?

We have some interest coming in from other teams to use the images that we build for the backstage-showcase app. We should come up with a method for improving how we tag our images to ensure that we do not introduce a breaking change / error that could potentially be disruptive to the other teams.

What is the current behavior?

We create two images that are tagged with latest and the git id every time there is a push to main.

What is the new behavior?

A method of ensuring there is an image that we can guarantee will work for the other teams. A couple of ideas that come to mind are included below.

• Start a versioning system where we have major versions that we can guarantee will work and minor versions that could introduce an issue / error and tag accordingly
• Pull and re-tag the previous git id tagged images to something that will be identifiable to the other teams
• Keeping track of previous git id tags that we know work and updating teams when new ones arrive

⚠️ Is this a breaking change?

Put an x in the boxes that apply

• Yes
• No
• Don't know

What do you want to improve?

Add a badge with a link to Quay to anyone can find the latest image.
Like the one in the redhat-backstage-build repo

What is the current behavior?

Currently we don't have a link to Quay. We used to publish to GH Registry so user can find the old image. We should remove the old image and only keep Quay (or publish to both)

What is the new behavior?

Let the user where to find the latest image

And add it to the 'Security' tab in the Entity page.

Add to the 'Overview' tab in the Entity page

What do you want to improve?

adding the ability to discover catalog entry by crawling the repo of an organization

What is the current behavior?

that feature does not exists.
please refer to this link on how to implement it:
https://backstage.io/docs/integrations/github/discovery#github-provider

⚠️ Is this a breaking change?

Put an x in the boxes that apply

• Yes
• No
• Don't know

Acceptance criteria

• Add the ArgoCD action @roadiehq/scaffolder-backend-argocd
• Add the ArgoCD backend plugin @roadiehq/backstage-plugin-argo-cd-backend
• Be able to add more than 1 ArgoCD instance in the proxy section of app-config.yaml

Plugin documentation/information

• https://github.com/RoadieHQ/roadie-backstage-plugins/tree/main/plugins/scaffolder-actions/scaffolder-backend-argocd
• https://roadie.io/backstage/plugins/argo-cd/

Install and configure the Snyk plugin
https://github.com/snyk-tech-services/backstage-plugin-snyk/tree/main

Add to the 'Security Insights' tab in the entity page

What do you want to improve?

Enable github identity resolver, this will allow a user that logs in to be mapped to an identity imported via the github org processor (see #115 ). This is a necessary step to understand the ownership of a user that is logged it. Having an identity resolver is also the base of any serious RBAC implementation.

see here: https://backstage.io/docs/auth/identity-resolver/#built-in-resolvers
also an implementation with the default github idneityt resolver: https://github.com/raf-backstage-demo/backstage-app-demo/blob/main/packages/backend/src/plugins/auth.ts

⚠️ Is this a breaking change?

Put an x in the boxes that apply

• Yes
• No
• Don't know

Fix the following security issue:

https://quay.io/repository/janus-idp/backstage-showcase/manifest/sha256:692660768d9158f4f4a55da7da6aa6ec6eb69906b503a32d580cbcd7230150ff?tab=vulnerabilities&fixable=true

Story

• As a user, I wish to be able to deploy the Backstage Showcase app to a Kubernetes cluster.

Description

• Currently, the Helm Chart that we are utilizing within our repository is the helm-backstage Janus-IDP Helm Chart and is not the correct Helm Chart that we are going to be using to deploy the showcase app with. This can lead to some confusion whenever we start getting more involvement from the community and needs to be address. The correct Helm Chart should instead come from the upstream Backstage repository.

AC

• Upstream Helm Chart added to the repository
• Documentation on how to deploy to a cluster using the Helm Chart.

Additional Notes

• None so far

The ocm page does not look like the other pages in Backstage. It's missing the header section

• Create a folder homepage in the bucket and move the data for the homepage
• Create a folder techradar in the bucket and move the data for the techradar page

We could also create a GPT for this feature. janus-idp/software-templates#88

@sabre1041 can you please add some context here

Update the Tech Radar sample with better data.