第5章 修正された問題

以前は、GitHub Issues プラグインは、検出した最初の GitHub インテグレーションをすべてのコンポーネントに対してデフォルトで使用していました。この動作により、複数の GitHub インテグレーションホストに関連するセットアップとの互換性がありませんでした。

GitHub Issues プラグインが、複数の GitHub インテグレーションホストをサポートするようになりました。これは、有名なエンティティースラグアノテーションの backstage.io/source-location または backstage.io/managed-by-location を使用して、コンポーネントに適切な GitHub インテグレーションを決定します。スラグに一致するインテグレーションがない場合は、最初の GitHub インテグレーションが選択され、以前の動作を維持します。

以前は、3scale バックエンドプラグインで定義された一部の API ドキュメントは、RHDH でアクセスできませんでした。

この更新により、3scale バックエンドプラグインで定義されたすべての API ドキュメントがインポートされ、RHDH にマージされるようになりました。

以前は、Helm チャートを使用してデプロイする場合、Route ホスト名と、生成された app-config ConfigMap に追加された baseUrl フィールドとの間に不一致が生じる可能性がありました。これにより、作成元が一致しないため、一部のプロバイダーに対する認証に失敗する場合がありました。

この更新では、それらの値の間で不一致が発生しないようにすることで、この問題を修正しています。

以前は、ロールベースアクセス制御 (RBAC) バックエンドプラグインを無効にすると、パーミッションフレームワークが有効かどうかに関わらず、ロールとパーミッションポリシーが作成されていました。

この更新により、RBAC バックエンドプラグインを無効にすると、ロールとパーミッションポリシーが作成されなくなりました。

この更新前は、app-config ファイルまたは GitHub 検出などのさまざまなソースからリポジトリーが Developer Hub に追加されていました。Bulk Import プラグインは、設定された GitHub インテグレーションを使用してアクセス可能なリポジトリーのみを追跡していました。両方のプラグインが有効になっていた場合、GitHub Discovery によって検出されたリポジトリーは Bulk Import ページに表示されていました。ただし、検出または app-config.yaml ファイルからのエンティティーが Developer Hub カタログに残るため、これらのリポジトリーを Bulk Import ジョブから削除しても影響はありませんでした。

この更新により、削除アイコンにアラートが表示され、ユーザーに対してカタログエンティティーを削除するためにソース (リポジトリー内の catalog-info または app-config.yaml ファイル (このファイルが元になっている場合)) を修正するよう通知されます。

この更新前は、Kubernetes 設定のカスタムリソースは事前設定されていました。その結果、Kubernetes でカスタムリソースを設定しなくても、Tekton 警告が表示される可能性がありました。

この更新により、事前設定されたカスタムリソースが Kubernetes 設定から削除されます。したがって、ユーザーは要件に基づいて Kubernetes 設定のリソースをカスタマイズして、関連性のない警告が表示されないようにすることができます。

この更新前は、Backstage 1.31 でロールベースアクセス制御 (RBAC) バックエンドプラグインがエラーを表示して壊れていました。

この更新では、エラーを表示せずに Backstage バージョン 1.31 および 1.32 の RBAC バックエンドプラグインとの互換性の問題が解決されました。

この更新前は、バックステージインスタンスがバージョン 5.1.0 で起動できず、エラーが表示されていました。

この更新により、ロールベースアクセス制御 (RBAC) バックエンドプラグインが、エラーを表示せずにバージョン 5.1.0 で正常に起動するようになりました。

この更新前は、デプロイメントを複数の Pod にスケーリングすると、ロールベースアクセス制御 (RBAC) のロールが同期されずに残り、リソースを作成した Pod のみがそれを提供することができました。

この更新により、RBAC ロールはすべての Pod で適切に同期され、デプロイメント全体で一貫性を確保するために Redis キャッシュとトラフィックルーティングが設定されています。

以前は、CLI はエクスポートプロセス中に埋め込みパッケージの依存関係を調べ、他のパッケージを組み込む必要があるかどうかを確認していました。その方法の 1 つは、CLI が組み込まれたパッケージに遭遇した際に {{require}} を呼び出すことでした。これは、既存のプラグインをラップする場合に該当していました。

この更新により、{{require}} が使用する親ディレクトリーが monorepo ルートから組み込みパッケージに変更されます。そのため、見つかった依存パッケージは、組み込みパッケージに最も関連する依存関係です。

以前は、ネイティブモジュールがサポートされていないというメッセージが表示されて CLI が失敗していました。

この更新では、動的プラグイン開発者のネイティブモジュールの処理に役立つ 2 つの新しい CLI フラグが導入されました。どちらのフラグもパッケージのリストを受け入れます。--suppress-native-package フラグは、ランタイムでネイティブモジュールを必要としません。これは、エラーを表示する空のパッケージでネイティブモジュールを置き換えます。--allow-native-package フラグは、CLI に対してチェック時にネイティブパッケージを許可し、ネイティブモジュールを使用するプラグインをテストするよう指示します。

以前は、ドキュメント (TechDoc) の問題を報告する機能が失敗していました。したがって、ユーザーが TechDoc でテキストを選択した場合、ツールチップボタンではなく大きなアイコンが表示されました。

この更新により、ユーザーは、ドキュメント (TechDoc) の問題を報告するときに、テキストを選択できるようになりました。

以前は、export-dynamic-plugin は、stdout maxBuffer の長さが超過しているというエラーで失敗していました。

この更新により、CLI はエクスポートプロセス中に実行する {{yarn install}} コマンドの出力をファイルにリダイレクトするようになりました。したがって、{{yarn install}} コマンドを正常に完了し、export-dynamic-plugin を検証すると、ファイルをクリーンアップします。このファイルは、動的プラグイン検証チェックが失敗した場合にトラブルシューティングに使用できます。

以前は、semver チェックが動的プラグインパッケージの依存関係に対して実行されるため、新しいバックステージバージョンに更新されていないプラグインのエクスポートに失敗していました。

この更新で、--ignore-version-check フラグがパッケージ名のリストを受け入れるようになり、これが原因で CLI は、プラグインパッケージの依存関係を評価する際に CLI が実行する semver チェックを選択的に無視するようになりました。したがって、更新されていないプラグインは、変更されていないインターフェースや関数に依存しているため機能します。

この更新により、Tech Radar プラグインを使用するには、./dynamic-plugins/dist/backstage-community-tech-radar および ./dynamic-plugins/dist/backstage-community-tech-radar-backend-dynamic の両方を有効にする必要があります。プラグインの JSON データを読み込む場所に応じて、追加の設定を行う必要があります。