docs: replace more showcase references with RHDH (redhat-developer#2241)

Signed-off-by: Christoph Jerolimov <[email protected]>

Author: christoph-jerolimov

CONTRIBUTING.md

@@ -7,10 +7,10 @@ We are excited to see you want to be a part of this project by contributing. Her
 ### Clone and Install
 
 ```bash
-git clone https://github.com/your-username/backstage-showcase.git  # Clone your forked repository
-cd backstage-showcase                                              # Change to the project directory
-yarn install                                                       # Install dependencies
-yarn tsc                                                           # Run type generation and checks
+git clone https://github.com/your-username/rhdh.git   # Clone your forked repository
+cd rhdh                                               # Change to the project directory
+yarn install                                          # Install dependencies
+yarn tsc                                              # Run type generation and checks
 ```
 
 ### Run the Showcase App

docs/audit-log.md

@@ -1,6 +1,6 @@
-# Audit Logging for Backstage Showcase
+# Audit Logging for RHDH
 
-Backstage Showcase supports audit logging for both the catalog and scaffolder. Audit logs can be identified by the `isAuditLog: true` field.
+RHDH supports audit logging for both the catalog and scaffolder. Audit logs can be identified by the `isAuditLog: true` field.
 
 ## Configuring the audit logger
 

docs/auth.md

@@ -1,4 +1,4 @@
-# Auth Providers within Backstage Showcase
+# Auth Providers within RHDH
 
 Currently we incorporate many of the Authentication providers available within Backstage. The Showcase supports the following providers:
 
@@ -112,7 +112,7 @@ In an example using Keycloak for authentication with the OIDC provider, there ar
 
 1. Create a realm named keycloak.
 2. Create the client backstage with Client authentication checked.
-3. Set the Valid redirect URIs to `<BACKSTAGE_URL>/api/auth/oidc/handler/frame`. If running Backstage Showcase locally, it would look something like this: `http://localhost:7007/api/auth/oidc/handler/frame`.
+3. Set the Valid redirect URIs to `<BACKSTAGE_URL>/api/auth/oidc/handler/frame`. If running RHDH locally, it would look something like this: `http://localhost:7007/api/auth/oidc/handler/frame`.
 4. Set the `metadataUrl` to the URL of your Keycloak instance and realm. It should look similar to this: `<KEYCLOAK_URL>/realms/keycloak`.
 5. Set the `clientId` to `backstage`.
 6. Obtain the client secret for the client backstage within Keycloak and set `clientSecret`.
@@ -127,7 +127,7 @@ For more information on setting up the OIDC auth provider, consult the [Backstag
 
 ### Sign In Page configuration value
 
-After selecting the authentication provider you wish to use with your Backstage Showcase instance, ensure to add the `signInPage` configuration value to ensure that the frontend displays the appropriate authentication provider.
+After selecting the authentication provider you wish to use with your RHDH instance, ensure to add the `signInPage` configuration value to ensure that the frontend displays the appropriate authentication provider.
 
 - Add the corresponding Authentication provider key as the value to `signInPage` in your `app-config`. Where `provider-id` matches the chosen provider from the table above.
 

docs/dynamic-plugins/debugging.md

@@ -3,7 +3,7 @@
 
 ## Backend Dynamic Plugins Local Debug
 
-For local debugging of Dynamic Plugins you need to clone `backstage-showcase`, run it with debugging enabled and attach your IDE debugger to the backend process. First it is required to build and copy the dynamic plugin:
+For local debugging of Dynamic Plugins you need to clone `rhdh`, run it with debugging enabled and attach your IDE debugger to the backend process. First it is required to build and copy the dynamic plugin:
 
 * Build your plugin and export the dynamic package
 
@@ -16,7 +16,7 @@ yarn build && yarn run export-dynamic
 
 Once the plugin is built and deployed, it is time to prepare the showcase to run it debug mode:
 
-* Go to `backstage-showcase` root directory;
+* Go to `rhdh` root directory;
 * Run `yarn workspace backend start --inspect`
 * In logs you should see something like the following:
 
@@ -30,7 +30,7 @@ Debugger listening on ws://127.0.0.1:9229/9299bb26-3c32-4781-9488-7759b8781db5
 
 ## Backend Dynamic Plugins Container Debug
 
-It is possible to run RHDH on a container and debug plugins that are running on it. In this case you don't need to clone the `backstage-showcase` code locally, instead you must make sure that the running container has the [Node.js debug](https://nodejs.org/en/learn/getting-started/debugging) port open and exposed to the host machine. These are the steps to debug backend dynamic plugins on a container:
+It is possible to run RHDH on a container and debug plugins that are running on it. In this case you don't need to clone the `rhdh` code locally, instead you must make sure that the running container has the [Node.js debug](https://nodejs.org/en/learn/getting-started/debugging) port open and exposed to the host machine. These are the steps to debug backend dynamic plugins on a container:
 
 * Create directory `dynamic-plugins-root`
 * Build your plugin and copy the folder `dist-dynamic` to `dynamic-plugins-root`

docs/e2e-tests/CI.md

@@ -4,7 +4,7 @@ This document provides a comprehensive overview of our Continuous Integration (C
 
 ## GitHub Pull Requests
 
-When a new Pull Request (PR) is opened at [backstage-showcase](https://github.com/redhat-developer/rhdh), tests are triggered based on the nature of the changes and the contributor's role.
+When a new Pull Request (PR) is opened at [rhdh](https://github.com/redhat-developer/rhdh), tests are triggered based on the nature of the changes and the contributor's role.
 
 ### Automatic Triggering of Tests
 

docs/index.md

@@ -1,6 +1,6 @@
-# Getting Started running Backstage Showcase
+# Getting Started running RHDH
 
-There are several different methods for running the Backstage Showcase app today. We currently have support for running the application locally, using a helm chart to deploy to a cluster, and manifests for deployment using ArgoCD.
+There are several different methods for running the RHDH app today. We currently have support for running the application locally, using a helm chart to deploy to a cluster, and manifests for deployment using ArgoCD.
 
 ## Telemetry collection
 
@@ -153,7 +153,7 @@ If you wish to subsequently disable telemetry data collection, use one of the fo
 
 ## Running Locally with a basic configuration
 
-The easiest and fastest method for getting started: Backstage Showcase app, running it locally only requires a few simple steps.
+The easiest and fastest method for getting started: RHDH app, running it locally only requires a few simple steps.
 
 1. Copy `app-config.example.yaml` and rename it as `app-config.local.yaml`.
 

docs/monitoring-and-logging.md

@@ -1,8 +1,8 @@
-# Setting up Metrics Monitoring and Logging for Backstage Showcase
+# Setting up Metrics Monitoring and Logging for RHDH
 
-The Backstage Showcase provides a `/metrics` endpoint on port `9464` that provides OpenTelemetry metrics about your backstage application. This endpoint can be used to monitor your backstage instance using OpenTelemetry and Grafana.
+The RHDH provides a `/metrics` endpoint on port `9464` that provides OpenTelemetry metrics about your backstage application. This endpoint can be used to monitor your backstage instance using OpenTelemetry and Grafana.
 
-When deploying Backstage Showcase onto a kubernetes cluster with the [RHDH Helm chart](https://github.com/redhat-developer/rhdh-chart) or the [RHDH Operator](https://github.com/janus-idp/operator), monitoring and logging for your RHDH instance can be configured using the following steps.
+When deploying RHDH onto a kubernetes cluster with the [RHDH Helm chart](https://github.com/redhat-developer/rhdh-chart) or the [RHDH Operator](https://github.com/janus-idp/operator), monitoring and logging for your RHDH instance can be configured using the following steps.
 
 ## Prerequisites
 
@@ -86,13 +86,13 @@ Similar to the instructions above for a Helm-based deployment, you can then veri
 
 ### Enabling Metrics Monitoring on Azure Kubernetes Service (AKS)
 
-To enable metrics monitoring for Backstage Showcase on Azure Kubernetes Service (AKS), you can use the [Azure Monitor managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview). The AKS cluster will need to have an associated [Azure Monitor workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/containers/prometheus-metrics-enable?tabs=azure-portal).
+To enable metrics monitoring for RHDH on Azure Kubernetes Service (AKS), you can use the [Azure Monitor managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview). The AKS cluster will need to have an associated [Azure Monitor workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/containers/prometheus-metrics-enable?tabs=azure-portal).
 
 One method is to configure the metrics scraping of your AKS cluster using the [Azure Monitor _metrics_ add-on](https://learn.microsoft.com/en-us/azure/azure-monitor/containers/prometheus-metrics-scrape-configuration).
 
 The other method is to configure the Azure Monitor _monitoring_ add-on which also allows you to [send Prometheus metrics to the Log Analytics workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/containers/container-insights-prometheus-logs). These metrics can then be queried using [Log Analytics queries](https://learn.microsoft.com/en-us/azure/azure-monitor/containers/container-insights-log-query#prometheus-metrics) as well as be visible in a Grafana instance.
 
-In both methods, we can configure the metrics scraping to scrap from pods based on pod Annotations. Follow the steps below depending on how the Backstage Showcase application is deployed.
+In both methods, we can configure the metrics scraping to scrap from pods based on pod Annotations. Follow the steps below depending on how the RHDH application is deployed.
 
 #### Helm deployment
 
@@ -196,7 +196,7 @@ InsightsMetrics
 
 ## Logging
 
-Logging in backstage showcase is conducted using the [winston](https://github.com/winstonjs/winston) library. By default, logs of level `debug` are not logged. To enable debug logs, you will need to set the environment variable `LOG_LEVEL` to `debug` in your deployment.
+Logging in RHDH is conducted using the [winston](https://github.com/winstonjs/winston) library. By default, logs of level `debug` are not logged. To enable debug logs, you will need to set the environment variable `LOG_LEVEL` to `debug` in your deployment.
 
 ### Helm deployment
 

docs/patch-package.md

@@ -4,7 +4,7 @@ This guide will show you how to patch a package in Backstage using the `patch-pa
 
 ## Prerequisites
 
-- Have a `backstage-showcase` instance locally cloned
+- Have a `rhdh` instance locally cloned
 - Have a `backstage` instance/fork locally cloned
 
 ## Manually patching a package
@@ -33,11 +33,11 @@ This guide will show you how to patch a package in Backstage using the `patch-pa
 
    # This is an optional step to remove the old .cjs.js and .cjs.js.map files in the dist/cjs directory of the package. Please refer to the caveats section for more information
    update_file_references
-   # Merge the contents of the patched package into the node_modules directory of the backstage-showcase project
-   cp -Rv plugin-scaffolder-backend/* /home/user/backstage-showcase/node_modules/@backstage/plugin-scaffolder-backend
+   # Merge the contents of the patched package into the node_modules directory of the rhdh project
+   cp -Rv plugin-scaffolder-backend/* /home/user/rhdh/node_modules/@backstage/plugin-scaffolder-backend
    ```
 
-1. Then navigate to the `backstage-showcase` project and run the following commands to generate the patch files:
+1. Then navigate to the `rhdh` project and run the following commands to generate the patch files:
 
    ```bash
    # Generate the patch file
@@ -52,26 +52,26 @@ This guide will show you how to patch a package in Backstage using the `patch-pa
 
 1. Create a new branch in your `backstage` instance for your target backstage version
 1. Navigate to the `backstage` project and make your changes to the package/plugin you want to patch as if you were going to submit a PR
-1. Navigate to the `backstage-showcase` project and run the `.scripts/patch-package.sh` to create a patch file for the package(s) you want to patch.
+1. Navigate to the `rhdh` project and run the `.scripts/patch-package.sh` to create a patch file for the package(s) you want to patch.
 
    - Script Usage: `./patch-package.sh [src] [dest] [package-name-1] [package-name-2] ...`
    - The `src` is the path to the `backstage` project containing your patch changes
-   - The `dest` is the path to the `backstage-showcase` project where the patch file will be created
+   - The `dest` is the path to the `rhdh` project where the patch file will be created
    - The `package-name` array of arguments is the name of the package(s) you want to patch
-   - When listing package names, please ensure it matches the package name in the `@backstage/node_modules` directory of the `backstage-showcase` project
+   - When listing package names, please ensure it matches the package name in the `@backstage/node_modules` directory of the `rhdh` project
    - Example usage of patching a plugin and a package:
 
      ```bash
-     ./patch-package.sh /path/to/backstage /path/to/backstage-showcase @backstage/plugin-scaffolder-backend @backstage/integration
+     ./patch-package.sh /path/to/backstage /path/to/rhdh @backstage/plugin-scaffolder-backend @backstage/integration
      ```
 
-1. The script will create patch files in the `patches` directory of the `backstage-showcase` project. Run `yarn install --force` in the `backstage-showcase` project and verify that the patches were applied correctly
+1. The script will create patch files in the `patches` directory of the `rhdh` project. Run `yarn install --force` in the `rhdh` project and verify that the patches were applied correctly
 
 ## Caveats
 
-- The `patch-package` script will not work if the package you are trying to patch is not installed in the `backstage-showcase` project
+- The `patch-package` script will not work if the package you are trying to patch is not installed in the `rhdh` project
 - The `patch-package` script will not be able to patch modifications to the `package.json` to add new dependencies or change the version of existing dependencies
-  - You will need to manually update the `package.json` in the `backstage-showcase` project to include the new dependencies or changes to existing dependencies since the patches are applied after the `yarn install` command is run
+  - You will need to manually update the `package.json` in the `rhdh` project to include the new dependencies or changes to existing dependencies since the patches are applied after the `yarn install` command is run
 - The `patch-package` script will leave behind the old `.cjs.js` and `.cjs.js.map` files in the `dist/cjs` directory of the package if the resultant package's a `dist/cjs` directory that contains more than 2 files
 
   - This is due to the resultant file names after a build being different if any modifications were made to them.
@@ -115,4 +115,4 @@ This guide will show you how to patch a package in Backstage using the `patch-pa
        ```
 
     3. Repeat for any other files that need to be renamed
-    4. Merge the patched package with the `node_modules` package in the `backstage-showcase` project
+    4. Merge the patched package with the `node_modules` package in the `rhdh` project

dynamic-plugins/wrappers/red-hat-developer-hub-backstage-plugin-catalog-backend-module-marketplace-dynamic/package.json

@@ -47,7 +47,7 @@
   },
   "repository": {
     "type": "git",
-    "url": "https://github.com/janus-idp/backstage-showcase",
+    "url": "https://github.com/redhat-developer/rhdh",
     "directory": "dynamic-plugins/wrappers/red-hat-developer-hub-backstage-plugin-catalog-backend-module-marketplace-dynamic"
   },
   "maintainers": [

dynamic-plugins/wrappers/red-hat-developer-hub-backstage-plugin-marketplace-backend-dynamic/package.json

@@ -53,7 +53,7 @@
   ],
   "repository": {
     "type": "git",
-    "url": "https://github.com/janus-idp/backstage-showcase",
+    "url": "https://github.com/redhat-developer/rhdh",
     "directory": "dynamic-plugins/wrappers/red-hat-developer-hub-backstage-plugin-marketplace-backend-dynamic"
   },
   "maintainers": [

dynamic-plugins/wrappers/red-hat-developer-hub-backstage-plugin-marketplace/package.json

@@ -49,7 +49,7 @@
   },
   "repository": {
     "type": "git",
-    "url": "https://github.com/janus-idp/backstage-showcase",
+    "url": "https://github.com/redhat-developer/rhdh",
     "directory": "dynamic-plugins/wrappers/red-hat-developer-hub-backstage-plugin-marketplace"
   },
   "maintainers": [

scripts/update-backstage.mjs

@@ -341,7 +341,7 @@ async function main() {
     updateBuildMetadata(backstageVersion);
 
     console.log(
-      `Successfully updated the Backstage Showcase to ${backstageVersion}!`,
+      `Successfully updated Backstage to ${backstageVersion}!`,
     );
   } catch (error) {
     console.error("An error occurred during the update process:", error);