HTTP リポジトリ ルール

このリポジトリの一意の名前。

リポジトリ ディレクトリからの相対パスの宛先ディレクトリ。アーカイブ内のファイルパスに strip_prefix（存在する場合）を適用した後、このディレクトリに展開されます。たとえば、add_prefix = "bar" と strip_prefix = "foo-1.2.3" の場合、ファイル foo-1.2.3/src/foo.h は bar/src/foo.h に展開されます。

ホスト名をカスタム認可パターンにマッピングする辞書（省略可）。この辞書に URL のホスト名が含まれている場合、その値は HTTP リクエストの認可ヘッダーを生成するときにパターンとして使用されます。これにより、多くの一般的なクラウド ストレージ プロバイダで使用されているカスタム認可スキームを使用できます。このパターンは現在、<login> と <password> の 2 つのトークンをサポートしています。これらのトークンは、同じホスト名の netrc ファイル内の同等の値に置き換えられます。フォーマット後、結果は HTTP リクエストの Authorization フィールドの値として設定されます。ベアラー トークンを使用して oauth2 対応 API への HTTP ダウンロードの属性と netrc の例:

auth_patterns = {
    "storage.cloudprovider.com": "Bearer <password>"
}

machine storage.cloudprovider.com
        password RANDOM-TOKEN

Authorization: Bearer RANDOM-TOKEN

このリポジトリの BUILD ファイルとして使用するファイル。この属性は絶対ラベルです（メイン リポジトリの場合は「@//」を使用します）。ファイル名は BUILD にする必要はありませんが、BUILD にすることもできます（リポジトリの実際の BUILD ファイルと区別するために、BUILD.new-repo-name などの名前を付けるとよいでしょう。build_file または build_file_content のいずれかを指定できます。両方は指定できません。

このリポジトリの BUILD ファイルの内容。build_file または build_file_content のいずれかを指定できます。両方は指定できません。

ダウンロードしたファイルの正規 ID。指定されていて空でない場合、同じ正規 ID を持つリクエストによってキャッシュに追加されていない限り、Bazel はキャッシュからファイルを取得しません。指定しない場合や空の場合は、Bazel はデフォルトでファイルの URL を正規 ID として使用します。これにより、ハッシュを更新せずに URL を更新するという一般的な間違いを検出できます。この間違いにより、ローカルではビルドが成功しても、キャッシュにファイルがないマシンではビルドが失敗します。この動作は、--repo_env=BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0 で無効にできます。

ダウンロードしたファイルの Subresource Integrity 形式の想定チェックサム。これは、ダウンロードしたファイルのチェックサムと一致している必要があります。_リモート ファイルが変更される可能性があるため、チェックサムを省略することはセキュリティ上のリスクです。_ 最善の場合、このフィールドを省略すると、ビルドが非ヘルメティックになります。開発を容易にするために省略できますが、出荷前にこの属性または「sha256」のいずれかを設定する必要があります。

認証に使用する .netrc ファイルの場所

パッチツールに渡される引数。デフォルトは -p0 ですが、通常、git によって生成されたパッチには -p1 が必要です。-p 引数が複数指定されている場合は、最後の引数が有効になります。-p 以外の引数が指定されている場合、Bazel は Bazel ネイティブのパッチ実装ではなく、patch コマンドライン ツールを使用します。パッチ コマンドライン ツールにフォールバックし、patch_tool 属性が指定されていない場合、patch が使用されます。これは、[patches] 属性のパッチファイルにのみ影響します。

パッチ適用後に Linux / macOS で適用される Bash コマンドのシーケンス。

パッチの適用後に Windows で適用する PowerShell コマンドのシーケンス。この属性が設定されていない場合、patch_cmds は Windows で実行されます。この場合、Bash バイナリが存在している必要があります。

使用する patch(1) ユーティリティ。これが指定されている場合、Bazel は Bazel ネイティブのパッチ実装ではなく、指定されたパッチツールを使用します。

アーカイブの抽出後にパッチとして適用するファイルのリスト。デフォルトでは、Bazel ネイティブのパッチ実装が使用されますが、これはファズ マッチとバイナリ パッチをサポートしていません。ただし、patch_tool 属性が指定されている場合、または patch_args 属性に「-p」以外の引数がある場合は、Bazel はパッチ コマンドライン ツールを使用します。

リモートパッチのファイル名から削除される先頭のスラッシュの数。

パッチファイルの URL と完全性値のマップ。アーカイブの抽出後に適用され、[patches] 属性からパッチファイルを適用する前に適用されます。Bazel ネイティブのパッチ実装を使用します。パッチストリップ番号は「remote_patch_strip」で指定できます。

ローカル リポジトリ名からグローバル リポジトリ名への辞書。これにより、このリポジトリの依存関係のワークスペース依存関係解決を制御できます。

たとえば、エントリ「"@foo": "@bar"」は、このリポジトリが「@foo」に依存するすべての場合（「@foo//some:target」への依存関係など）に、グローバルに宣言された「@bar」（「@bar//some:target」）内でその依存関係を解決することを宣言します。

ダウンロードされたファイルの想定される SHA-256。これは、ダウンロードしたファイルの SHA-256 と一致する必要があります。リモート ファイルが変更される可能性があるため、SHA-256 を省略することはセキュリティ上のリスクです。このフィールドを省略すると、ビルドが非密閉になります。開発を容易にするために省略可能ですが、出荷前にこの属性または「integrity」のいずれかを設定する必要があります。

抽出されたファイルから削除するディレクトリ接頭辞。多くのアーカイブには、アーカイブ内の有用なファイルをすべて含む最上位ディレクトリがあります。この接頭辞を build_file で何度も指定する代わりに、このフィールドを使用して、抽出されたすべてのファイルから接頭辞を削除できます。たとえば、foo-lib-latest.zip を使用しているとします。この foo-lib-1.2.3/ディレクトリには WORKSPACE ファイルがあり、さらに、src/ディレクトリ、lib/ディレクトリ、test/ディレクトリにはビルドする実際のコードが格納されています。「foo-lib-1.2.3」ディレクトリを最上位ディレクトリとして使用するには、「strip_prefix = "foo-lib-1.2.3"」を指定します。 このディレクトリの外部にファイルがある場合、それらのファイルは破棄され、アクセスできなくなります（最上位のライセンス ファイルなど）。これには、先頭が接頭辞で、ディレクトリ内にないファイル/ディレクトリ（例:foo-lib-1.2.3.release-notes など）。指定された接頭辞がアーカイブ内のディレクトリと一致しない場合、Bazel はエラーを返します。

ダウンロードしたファイルのアーカイブ タイプ。デフォルトでは、アーカイブ タイプは URL のファイル拡張子から決定されます。ファイルに拡張子がない場合は、次のいずれかを明示的に指定できます。「zip」、「jar」、「war」、「aar」、「tar」、「tar.gz」、「tgz」、「tar.xz」、「txz」、「tar.zst」、「tzst」、「tar.bz2」、「ar」、「deb」

Bazel で使用可能なファイルの URL。ファイル、http または https の URL を指定してください。リダイレクトが行われます。認証はサポートされていません。取得元の代替 URL を指定できる urls パラメータを使用すると、柔軟性を高めることができます。

Bazel で使用可能なファイルの URL のリスト。各エントリはファイル、http または https URL である必要があります。リダイレクトが行われます。認証はサポートされていません。URL は、成功するまで順番に試行されるため、ローカルミラーを最初にリストする必要があります。すべてのダウンロードが失敗した場合、ルールは失敗します。

このリポジトリの WORKSPACE ファイルとして使用するファイル。「workspace_file」または「workspace_file_content」のいずれかを指定するか、どちらも指定しないことができます。両方を指定することはできません。

このリポジトリの WORKSPACE ファイルのコンテンツ。「workspace_file」または「workspace_file_content」のいずれかを指定するか、どちらも指定しないことができます。両方を指定することはできません。

このリポジトリの一意の名前。

ホスト名をカスタム認証パターンにマッピングする辞書（省略可）。この辞書に URL のホスト名が含まれている場合、その値は HTTP リクエストの認可ヘッダーを生成するときにパターンとして使用されます。これにより、多くの一般的なクラウド ストレージ プロバイダで使用されているカスタム認可スキームを使用できます。現在、このパターンでは <login> と <password> の 2 つのトークンがサポートされています。これらのトークンは、同じホスト名の netrc ファイルで同等の値に置き換えられます。フォーマット後、結果は HTTP リクエストの Authorization フィールドの値として設定されます。ベアラー トークンを使用して oauth2 対応 API への HTTP ダウンロードの属性と netrc の例:

auth_patterns = {
    "storage.cloudprovider.com": "Bearer <password>"
}

machine storage.cloudprovider.com
        password RANDOM-TOKEN

Authorization: Bearer RANDOM-TOKEN

ダウンロードしたファイルの正規 ID。指定されていて空でない場合、同じ正規 ID を持つリクエストによってキャッシュに追加されていない限り、Bazel はキャッシュからファイルを取得しません。指定しない場合や空の場合は、Bazel はデフォルトでファイルの URL を正規 ID として使用します。これにより、ハッシュを更新せずに URL を更新するという一般的な間違いを検出できます。この間違いにより、ローカルではビルドが成功しても、キャッシュにファイルがないマシンではビルドが失敗します。この動作は、--repo_env=BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0 で無効にできます。

ダウンロードしたファイルに割り当てられたパス

ダウンロードしたファイルを実行可能にするかどうか。

ダウンロードしたファイルの Subresource Integrity 形式の想定チェックサム。これは、ダウンロードしたファイルのチェックサムと一致している必要があります。_リモート ファイルが変更される可能性があるため、チェックサムを省略することはセキュリティ上のリスクです。_ 最善の場合、このフィールドを省略すると、ビルドが非ヘルメティックになります。開発を容易にするために省略できますが、出荷前にこの属性または「sha256」のいずれかを設定する必要があります。

認証に使用する .netrc ファイルの場所

ローカル リポジトリ名からグローバル リポジトリ名への辞書。これにより、このリポジトリの依存関係のワークスペース依存関係解決を制御できます。

たとえば、エントリ「"@foo": "@bar"」は、このリポジトリが「@foo」に依存するすべての場合（「@foo//some:target」への依存関係など）に、グローバルに宣言された「@bar」（「@bar//some:target」）内でその依存関係を解決することを宣言します。

ダウンロードされたファイルの想定される SHA-256。これは、ダウンロードしたファイルの SHA-256 と一致する必要があります。リモート ファイルが変更される可能性があるため、SHA-256 を省略することはセキュリティ上のリスクです。このフィールドを省略すると、ビルドが非密閉になります。開発を容易にするために設定できますが、出荷前に設定する必要があります。

Bazel で使用可能なファイルの URL。ファイル、http または https の URL を指定してください。リダイレクトが行われます。認証はサポートされていません。取得元の代替 URL を指定できる urls パラメータを使用すると、柔軟性を高めることができます。

Bazel で使用できるようにするファイルの URL のリストです。 各エントリはファイル、http または https URL である必要があります。リダイレクトが行われます。認証はサポートされていません。URL は、成功するまで順番に試行されるため、ローカルミラーを最初にリストする必要があります。すべてのダウンロードが失敗した場合、ルールは失敗します。

このリポジトリの一意の名前。

ホスト名をカスタム認可パターンにマッピングする辞書（省略可）。この辞書に URL のホスト名が含まれている場合、その値は HTTP リクエストの認可ヘッダーを生成するときにパターンとして使用されます。これにより、多くの一般的なクラウド ストレージ プロバイダで使用されているカスタム認可スキームを使用できます。現在、このパターンでは <login> と <password> の 2 つのトークンがサポートされています。これらのトークンは、同じホスト名の netrc ファイルで同等の値に置き換えられます。フォーマット後、結果は HTTP リクエストの Authorization フィールドの値として設定されます。署名なしトークンを使用して OAuth2 対応 API に HTTP ダウンロードを行う場合の属性と netrc の例:

auth_patterns = {
    "storage.cloudprovider.com": "Bearer <password>"
}

machine storage.cloudprovider.com
        password RANDOM-TOKEN

Authorization: Bearer RANDOM-TOKEN

ダウンロードしたファイルの正規 ID。指定されていて空でない場合、同じ正規 ID を持つリクエストによってキャッシュに追加されていない限り、Bazel はキャッシュからファイルを取得しません。指定しない場合や空の場合は、Bazel はデフォルトでファイルの URL を正規 ID として使用します。これにより、ハッシュを更新せずに URL を更新するという一般的な間違いを検出できます。この間違いにより、ローカルではビルドが成功しても、キャッシュにファイルがないマシンではビルドが失敗します。この動作は、--repo_env=BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0 で無効にできます。

ダウンロードされた jar に割り当てられたファイル名

ダウンロードしたファイルの Subresource Integrity 形式の想定チェックサム。これは、ダウンロードしたファイルのチェックサムと一致している必要があります。_リモート ファイルが変更される可能性があるため、チェックサムを省略することはセキュリティ上のリスクです。_ 最善の場合、このフィールドを省略すると、ビルドが非ヘルメティックになります。開発を容易にするために省略できますが、出荷前にこの属性または「sha256」のいずれかを設定する必要があります。

認証に使用する .netrc ファイルの場所

ローカル リポジトリ名からグローバル リポジトリ名への辞書。これにより、このリポジトリの依存関係について、ワークスペースの依存関係の解決を制御できます。

たとえば、エントリ「"@foo": "@bar"」は、このリポジトリが「@foo」に依存するすべての場合（「@foo//some:target」への依存関係など）に、グローバルに宣言された「@bar」（「@bar//some:target」）内でその依存関係を解決することを宣言します。

ダウンロードされたファイルの想定される SHA-256。これは、ダウンロードしたファイルの SHA-256 と一致する必要があります。リモート ファイルが変更される可能性があるため、SHA-256 を省略することはセキュリティ上のリスクです。このフィールドを省略すると、ビルドが非密閉になります。開発を容易にするために省略可能ですが、出荷前にこの属性または「integrity」のいずれかを設定する必要があります。

Bazel で使用可能なファイルの URL。ファイル、http または https の URL を指定してください。リダイレクトが行われます。認証はサポートされていません。取得元の代替 URL を指定できる urls パラメータを使用すると、柔軟性を高めることができます。 URL の末尾は「.jar」にする必要があります。

Bazel で使用可能なファイルの URL のリスト。各エントリはファイル、http または https URL である必要があります。リダイレクトが行われます。認証はサポートされていません。URL は、1 つが成功するまで順番に試行されるため、ローカル ミラーを先頭に指定する必要があります。すべてのダウンロードが失敗した場合、ルールは失敗します。すべての URL は「.jar」で終わる必要があります。