-
権限セットに変更を加えていますが、DevOps センターが権限セットの完全な削除を検出しています。理由はわかりません。これを回避するには、削除を続行し、クローンを使用してシステムを更新します。
-
クローンされた権限セットには、異なるラベルと API 名が付いています。
-
作業項目を準備し、変更リクエストを確認するとき。 Git では、2 つのファイルではなく 1 つのファイルのデプロイメントが表示されます。
これは難しい問題です。 GitHub は、内容が同じである一連のファイルの削除と追加を認識すると、これを自動的にファイルの移動とみなします (そのため、2 つのファイルではなく 1 つのファイルが変更されたとみなされるのです)。これは一貫性がなく、残念ながら DevOps Center の制御能力の範囲外です。さらに、特定のファイルの削除と追加が検出された場合、DevOps センターはそれらを具体的に認識できる必要があるため、ファイルをそのようにマークします。これにより、一方 (GH) がファイルを移動または名前変更したと主張するのに、DevOps センターが古いファイルを削除して新しい (クローン) ファイルを作成したと主張するなど、2 つのシステム間に矛盾が生じる可能性があります。このため、Git でのファイルの移動や名前変更は常に頭の痛い作業です。実際に変更されている内容で混乱が生じやすくなるため、これらの操作を伴う作業はすべて単独で行うようにするのが最善です。そうは言っても、PermissionSet は、パーミッション セットを取得するときに関連するメタデータを使用して変更を取得する必要がある、基礎となるメタデータ API の問題により、同じ依存関係作成の問題に遭遇することがあります。たとえば、一部の Account.Field を読み取り専用に変更し、それに一致するように PermissionSet PS1 を更新します。 PermissionSet がソース形式で正確に表現されるようにするには、アカウントとフィールド自体を手動でコミットに追加する必要があります。
単一フィールドへの編集アクセスを更新した権限セットがあります。理由が何であれ、DevOps Center はこれを権限セットの削除ではなく変更として検出するため、デプロイできません。
別の組織でも同様のことが起こっているのを見たことがあります。これを修正できた唯一の方法は、基本的に権限セットを複製し、新しい名前を使用することでした。 (または、権限セットを削除してから再度追加することもできます) しかし、それはあまりにも大胆すぎるように思えます。
これについては他の回答で多少触れました。 ただし、PermissionSet には、依存関係とメタデータへの変更の検出方法に関して、いくつかの型破りな動作があります。簡単に言えば、これは、DevOps Center が存在する前に行われた意図的な設計選択の結果として、意図せずに生じた結果であるということです。基本的に、権限オブジェクト (プロファイルと権限セット) が組織から取得されると、多くの場合「最適化」されます。関心のあるオブジェクトに関する関連情報のみを取得します。したがって、システム権限を変更すると、すべての権限スタイルのオブジェクトに常に関連するため、これが検出されます。カスタム オブジェクトを作成して権限セットに追加すると、これもデフォルトで検出されるはずです。その後、権限セットに影響を与えるカスタム オブジェクトに変更を加えると、これが「最適化」される場合があります。変更をプルすると、実際にパーミッションも変更された場合にのみ、カスタム オブジェクトが変更されたものとして表示されます。プロファイルが街にある唯一のゲームで、PermissionSet が存在しなかったときは、プロファイルが非常に大きく、メタデータ API を使用してこのようにすべてのプロファイルを取得するのはコストが高かったため、これは合理的でした。 PermissionSet は、プロファイルの変更に対してすべての依存関係を取得する必要性を回避するために導入され、より重点を置くようになりました。ただし問題の根本は依然として残っており、メタデータ API レベルでの対処が依然として必要です。