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

ダウンロードされたファイルの、サブリソースの整合性形式で予想されるチェックサム。 これは、ダウンロードしたファイルのチェックサムと一致する必要があります。リモート ファイルが変更される可能性があるため、チェックサムを省略することはセキュリティ上のリスクになります。このフィールドを省略すると、ビルドが非密閉型になります。開発を容易にするために省略することもできますが、出荷前にこの属性または sha256 を設定する必要があります。

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

パッチツールに渡される引数。デフォルトは -p0 ですが、通常、git で生成されるパッチには -p1 が必要になります。複数の -p 引数が指定されている場合、最後の引数が有効になります。-p 以外の引数が指定されている場合、Bazel はフォールバックして、Bazel ネイティブのパッチ実装ではなくパッチ コマンドライン ツールを使用します。パッチ コマンドライン ツールにフォールバックし、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"、"ztar"、" "tar.zst" のいずれかを明示的に指定できます。

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

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

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

このリポジトリの WORKSPACE ファイルの内容。「workspace_file」または「workspace_file_content」はいずれか 1 つでも指定できます。両方を指定することもできません。

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

ホスト名をカスタム認可パターンにマッピングする辞書（省略可）。この辞書に 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。 指定されていて空でない場合、Bazel は、同じ正規 ID のリクエストによってキャッシュに追加された場合を除き、キャッシュからファイルを取得しません。指定しないか空の場合、Bazel はデフォルトではファイルの URL を正規 ID として使用します。これにより、ハッシュを更新せずに URL を更新してしまうというよくある間違いを検出できます。この場合、ビルドはローカルで成功しますが、キャッシュにファイルがないマシンでは失敗します。この動作は、--repo_env=BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0 で無効にできます。

ダウンロードしたファイルへのパス。

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

ダウンロードされたファイルの、サブリソースの整合性形式で予想されるチェックサム。 これは、ダウンロードしたファイルのチェックサムと一致する必要があります。リモート ファイルが変更される可能性があるため、チェックサムを省略することはセキュリティ上のリスクになります。このフィールドを省略すると、ビルドが非密閉型になります。開発を容易にするために省略することもできますが、出荷前にこの属性または 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。 指定されていて空でない場合、Bazel は、同じ正規 ID のリクエストによってキャッシュに追加された場合を除き、キャッシュからファイルを取得しません。指定しないか空の場合、Bazel はデフォルトではファイルの URL を正規 ID として使用します。これにより、ハッシュを更新せずに URL を更新してしまうというよくある間違いを検出できます。この場合、ビルドはローカルで成功しますが、キャッシュにファイルがないマシンでは失敗します。この動作は、--repo_env=BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0 で無効にできます。

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

ダウンロードされたファイルの、サブリソースの整合性形式で予想されるチェックサム。 これは、ダウンロードしたファイルのチェックサムと一致する必要があります。リモート ファイルが変更される可能性があるため、チェックサムを省略することはセキュリティ上のリスクになります。このフィールドを省略すると、ビルドが非密閉型になります。開発を容易にするために省略することもできますが、出荷前にこの属性または 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 は成功するまで順番に試行されるため、最初にローカル ミラーをリストする必要があります。すべてのダウンロードが失敗すると、そのルールは失敗します。 すべての URL の末尾は「.jar」にする必要があります。