GitHub パッケージ ファイアウォールのトラブルシューティング

キャッシュされたパッケージまたは構成の問題が、GitHub package firewall による予期しないインストール結果を説明しているかどうかを確認します。

メモ

この機能は現在 パブリック プレビュー であり、変更される可能性があります。

ポリシー変更後もパッケージがインストールされる

パッケージ マネージャーとレジストリ プロキシは、ローカル キャッシュから以前にダウンロードしたパッケージを再利用できます。 新しい要求が GitHub package firewallに達しなかった場合、ファイアウォールは更新されたポリシーに対してパッケージを評価できません。 これにより、ポリシーを変更したり例外を削除したりした後で、パッケージがインストールされてしまう可能性があります。

ローカル npm キャッシュを確認する

確認: パッケージは、同じファイアウォール エンドポイントを介して、別のテスト環境で npm キャッシュを空にした状態でもインストールされますか?

  1. 該当する場合は、正確なパッケージ名、バージョン、およびスコープを書き留めます。 企業のポリシーまたは例外で、そのバージョンが許可されているかどうかを確認します。

  2. 元のプロジェクト以外の一時的なプロジェクトで、既定のレジストリ設定やスコープ固有のレジストリ設定など、同じエンタープライズの GitHub package firewall エンドポイントと認証を使用するように npm を構成します。 元のプロジェクトとロックファイルを変更せずに、共有 npm キャッシュをクリアしないでください。 「GitHub パッケージ ファイアウォールを使用したエンドポイントの保護」を参照してください。

  3. 新しい空のキャッシュ ディレクトリを使用して、正確なバージョンをインストールします。 PACKAGE-NAME、EXACT-VERSION、およびEMPTY-CACHE-DIRECTORYをパッケージ名、バージョン、キャッシュ ディレクトリ パスに置き換えます。 --ignore-scripts オプションを使用すると、パッケージ ライフサイクル スクリプトが実行されなくなります。

    npm install PACKAGE-NAME@EXACT-VERSION \
  --cache EMPTY-CACHE-DIRECTORY --ignore-scripts

  4. 結果を元のプロジェクトと比較してください:

    • ファイアウォールでテストがブロックされている場合は、元のプロジェクトのインストール済みパッケージ、キャッシュ、レジストリ構成、およびロックファイルの違いを確認します。 ブロックされたテストだけでは、元のインストールを許可した違いは特定されません。
    • テストが成功した場合は、そのバージョンのリクエストが同じ企業のファイアウォール エンドポイントに到達したことを確認し、ポリシーと例外を再確認してください。 npm がキャッシュされたコンテンツを使用したと想定しないでください。

Artifactory キャッシュ

メモ

このガイダンスは、npm パッケージの実験用 Artifactory 統合にのみ適用されます。 空のローカル npm キャッシュでも、Artifactory は、ファイアウォール経由で新しい要求を送信することなく、キャッシュされたコンテンツを提供できます。

npm が Artifactory からパッケージを取得する場合は、Artifactory がキャッシュされたコンテンツを提供したかどうかを確認します。 また、仮想 npm リポジトリがファイアウォールでバックアップされたリモートを使用しており、パブリック npm レジストリからパッケージを直接取得するリモートが含まれていないことも確認します。 「GitHub パッケージ ファイアウォールを使用したエンドポイントの保護」を参照してください。