Chapter 5. Fixed issues

Previously, the GitHub issues plugin defaulted to using the first GitHub integration it detected for all components. This behavior made it incompatible with setups involving multiple GitHub integration hosts.

Now, GitHub issues plugin supports multiple GitHub integration hosts. It uses the well-known entity slug annotation backstage.io/source-location or backstage.io/managed-by-location to determine the appropriate GitHub integration for a component. If no integration matches the slug, the first GitHub integration is selected, maintaining the previous behavior.

Previously, some API documentation defined in the 3scale backend plugin was not accessible in RHDH.

With this update, all API documentation defined in the 3scale backend plugin is imported and merged in the RHDH.

Previously, when deploying with the Helm Chart, there could be a mismatch between the Route hostname and the baseUrl fields added to the generated app-config ConfigMap. This could sometimes cause failure to authenticate against some providers due to an origin mismatch.

This update fixes this issue by ensuring no mismatch between those values.

Previously, disabling the Role-Based Access Control (RBAC) backend plugin created roles and permission policies, whether the permission framework was enabled or not.

With this update, disabling the RBAC backend plugin no longer creates roles and permission policies.

Before this update, repositories were added to the Developer Hub from various sources, such as app-config files or GitHub discovery. The Bulk Import plugin only tracked repositories accessible using the configured GitHub integrations. When both plugins were enabled, repositories discovered by GitHub Discovery appeared on Bulk Import pages. However, deleting these repositories from Bulk Import Jobs had no effect, as entities from discovery or app-config.yaml file remained in the Developer Hub catalog.

With this update, an alert on the deletion icon notifies the user to modify the source (either the catalog-info within the repository or the app-config.yaml file if the file originates from there) to remove the catalog entity.

Before this update, the custom resources in Kubernetes configuration were pre-configured. As a result, users could see Tekton warnings without configuring the custom resources in Kubernetes.

This update removes the pre-configured custom resources from the Kubernetes configuration. Therefore, users can customize resources to the Kubernetes configuration based on their requirements, preventing unrelated warnings from appearing.

Before this update, Role-Based Access Control (RBAC) backend plugin broke in Backstage 1.31 with an error.

This update resolves compatibility issues with RBAC backend plugin on Backstage versions 1.31 and 1.32 without displaying any errors.

Before this update, the backstage instance failed to start in version 5.1.0, showing an error.

With this update, the Role-Based Access Control (RBAC) Backend plugin now starts successfully in version 5.1.0 without displaying any errors.

Before this update, scaling the deployment to more than one pod caused Role-Based Access Control (RBAC) roles to remain unsynced, allowing only the pod that created the resource to serve it.

With this update, RBAC roles are now properly synced across all pods, with Redis cache and traffic routing configured to ensure consistency across the deployment.

Previously, the CLI examined the dependencies of embedded packages during the export process to know if other packages should be embedded. One of the methods was calling {{require}} when the CLI encountered a built embedded package, which was the case when wrapping an existing plugin.

This update changes the parent directory that the {{require}} uses from the monorepo root to the embedded package. Therefore, the dependent package found is the dependency that is most relevant to the embedded package.

Previously, the CLI failed with a message that native modules are not supported.

This update introduces two new CLI flags that help dynamic plugin developers handle native modules. Both flags accept a list of packages. The --suppress-native-package flag does not require the native module at runtime. It replaces the native module with an empty package that displays an error. The --allow-native-package flag instructs the CLI to allow the native package during checks, and tests a plugin that uses a native module.

Previously, the feature to report a documentation (TechDoc) issue failed. Therefore, when a user selected a text in a TechDoc, a large icon appeared instead of a tooltip button.

With this update, users can select texts when reporting a documentation (TechDoc) issue.

Previously, the export-dynamic-plugin failed with an error that the stdout maxBuffer length was exceeded.

With this update, the CLI redirects the output of the {{yarn install}} command it performs during the export process to a file. Therefore, a successful completion of the {{yarn install}} command and verification of the export-dynamic-plugin, cleans up the file. The file is available for troubleshooting when the dynamic plugin validation checks fail.

Previously, exporting a plugin that has not been updated to a newer backstage version failed due to a semver check performed on dependencies of the dynamic plugin package.

With this update, an --ignore-version-check flag accepts a list of package names causing the CLI to selectively ignore the semver check the CLI performs when evaluating the plugin package dependencies. Therefore, a plugin that has not been updated works because it relies on unchanged interfaces and functions.

With this update, you are now required to enable both ./dynamic-plugins/dist/backstage-community-tech-radar and ./dynamic-plugins/dist/backstage-community-tech-radar-backend-dynamic to use the Tech Radar plugin. You must configure additional settings depending on where you choose to load the JSON data for the plugin.