如需穩定版說明文件，請使用「版本化文件」下拉式選單。預設檢視會反映位於 HEAD 的最新版本。

本頁面由 Cloud Translation API 翻譯而成。

建立事件通訊協定詞彙表

每個 BEP 事件類型都有自己的語意，最小記錄於 build_event_stream.proto 中。以下詞彙說明各種事件類型。

已取消

與其他事件不同，Aborted 沒有對應的 ID 類型，因為 Aborted 事件會「取代」其他類型的事件。這個事件表示建構作業提早終止，且出現在其下的事件 ID 一般並未產生。Aborted 包含列舉且容易理解的說明，解釋建構失敗的原因。

舉例來說，如果建構作業正在評估使用者中斷 Bazel 時的目標，BEP 會包含類似下方的事件：

{
  "id": {
    "targetCompleted": {
      "label": "//:foo",
      "configuration": {
        "id": "544e39a7f0abdb3efdd29d675a48bc6a"
      }
    }
  },
  "aborted": {
    "reason": "USER_INTERRUPTED"
  }
}

ActionExecuted

提供在建構中特定動作執行的詳細資料。根據預設，只有失敗的動作會在 BEP 中加入此事件，以協助您找出建構失敗的根本原因。使用者可以設定 --build_event_publish_all_actions 旗標，納入所有 ActionExecuted 事件。

BuildFinished

指令完成後，系統會傳送單一 BuildFinished 事件，並提供該指令的結束程式碼。這個事件會提供權威性的成功/失敗資訊。

BuildMetadata

包含 --build_metadata 旗標的剖析內容。這個事件之所以存在，是為了透過填充外部資料 (例如 ID) 支援 Bazel 與其他工具的整合。

BuildMetrics

系統會在每個指令的結尾傳送單一 BuildMetrics 事件，其中包含了適合在指令執行期間量化建構工具行為的計數器/測量結果。這些指標表示工作已確實完成，且不會計算重複使用的快取工作。

請注意，如果指令執行期間沒有任何 Java 垃圾收集，系統可能不會填入 memory_metrics。使用者可以設定 --memory_profile=/dev/null 選項，強制垃圾收集器在指令結尾執行填入 memory_metrics。

{
  "id": {
    "buildMetrics": {}
  },
  "buildMetrics": {
    "actionSummary": {
      "actionsExecuted": "1"
    },
    "memoryMetrics": {},
    "targetMetrics": {
      "targetsLoaded": "9",
      "targetsConfigured": "19"
    },
    "packageMetrics": {
      "packagesLoaded": "5"
    },
    "timingMetrics": {
      "cpuTimeInMs": "1590",
      "wallTimeInMs": "359"
    }
  }
}

BuildStarted

BEP 串流中的第一個事件，BuildStarted 會在任何有意義的工作開始之前說明指令的中繼資料。

BuildToolLogs

在指令的結尾會傳送單一 BuildToolLogs 事件，包括建構工具產生的檔案 URI，可協助瞭解或偵錯建構工具行為。部分資訊可能會以內嵌方式加入。

{
  "id": {
    "buildToolLogs": {}
  },
  "lastMessage": true,
  "buildToolLogs": {
    "log": [
      {
        "name": "elapsed time",
        "contents": "MC4xMjEwMDA="
      },
      {
        "name": "process stats",
        "contents": "MSBwcm9jZXNzOiAxIGludGVybmFsLg=="
      },
      {
        "name": "command.profile.gz",
        "uri": "file:///tmp/.cache/bazel/_bazel_foo/cde87985ad0bfef34eacae575224b8d1/command.profile.gz"
      }
    ]
  }
}

CommandLine

BEP 包含多個 CommandLine 事件，其中含有所有指令列引數的表示法 (包括選項和未解讀的引數)。每個 CommandLine 事件在其 StructuredCommandLineId 中都有一個標籤，用於表示其所傳達的表示法；BEP 中會出現三個這類事件：

"original"：在 Bazel 從 Bazel 用戶端收到該指令列時，重新建立指令列，且未使用 .rc 檔案中的啟動選項。
"canonical"：已展開並套用叫用政策的 .rc 檔案有效指令列。
"tool"：從 --experimental_tool_command_line 選項填入。這有助於傳送透過 BEP 包裝 Bazel 的工具指令列。這可以是直接使用 Base64 編碼的 CommandLine 二進位通訊協定緩衝區訊息，或是已剖析但尚未解譯的字串 (因為工具的選項可能與 Bazel 不同)。

設定

針對建構中頂層目標使用的每 configuration，系統就會傳送 Configuration 事件。一律至少包含一個設定事件。TargetConfigured 和 TargetComplete 事件 ID 會重複使用 id，而在多重設定版本中，這是區分這些事件的必要元素。

{
  "id": {
    "configuration": {
      "id": "a5d130b0966b4a9ca2d32725aa5baf40e215bcfc4d5cdcdc60f5cc5b4918903b"
    }
  },
  "configuration": {
    "mnemonic": "k8-fastbuild",
    "platformName": "k8",
    "cpu": "k8",
    "makeVariable": {
      "COMPILATION_MODE": "fastbuild",
      "TARGET_CPU": "k8",
      "GENDIR": "bazel-out/k8-fastbuild/bin",
      "BINDIR": "bazel-out/k8-fastbuild/bin"
    }
  }
}

ConvenienceSymlinksIdentified

實驗功能。如果設定了 --experimental_convenience_symlinks_bep_event 選項，build 指令會產生單一 ConvenienceSymlinksIdentified 事件，以指出如何管理工作區的符號連結。這樣即可建構可從遠端叫用 Bazel 的工具，然後將本機工作區比照在本機執行的方式安排。

{
  "id": {
    "convenienceSymlinksIdentified":{}
  },
  "convenienceSymlinksIdentified": {
    "convenienceSymlinks": [
      {
        "path": "bazel-bin",
        "action": "CREATE",
        "target": "execroot/google3/bazel-out/k8-fastbuild/bin"
      },
      {
        "path": "bazel-genfiles",
        "action": "CREATE",
        "target": "execroot/google3/bazel-out/k8-fastbuild/genfiles"
      },
      {
        "path": "bazel-out",
        "action": "CREATE",
        "target": "execroot/google3/bazel-out"
      }
    ]
  }
}

擷取

表示指令執行過程中發生了擷取作業。與其他事件不同，如果重複使用快取的擷取結果，這個事件就不會顯示在 BEP 串流中。

NamedSetOfFiles

NamedSetOfFiles 事件會回報與指令評估期間產生之檔案的 depset 相符的結構。轉換納入的依附元件依 NamedSetOfFilesId 識別。

如要進一步瞭解如何解讀串流的 NamedSetOfFiles 事件，請參閱 BEP 範例頁面。

OptionsParsed

單一 OptionsParsed 事件會列出套用至指令的所有選項，並將啟動選項和指令選項分開。以及 InvocationPolicy (如果有的話)。

{
  "id": {
    "optionsParsed": {}
  },
  "optionsParsed": {
    "startupOptions": [
      "--max_idle_secs=10800",
      "--noshutdown_on_low_sys_mem",
      "--connect_timeout_secs=30",
      "--output_user_root=/tmp/.cache/bazel/_bazel_foo",
      "--output_base=/tmp/.cache/bazel/_bazel_foo/a61fd0fbee3f9d6c1e30d54b68655d35",
      "--deep_execroot",
      "--expand_configs_in_place",
      "--idle_server_tasks",
      "--write_command_log",
      "--nowatchfs",
      "--nofatal_event_bus_exceptions",
      "--nowindows_enable_symlinks",
      "--noclient_debug",
    ],
    "cmdLine": [
      "--enable_platform_specific_config",
      "--build_event_json_file=/tmp/bep.json"
    ],
    "explicitCmdLine": [
      "--build_event_json_file=/tmp/bep.json"
    ],
    "invocationPolicy": {}
  }
}

PatternExpanded

PatternExpanded 事件用於表示所有符合指令列模式的目標組合。如果指令成功，單一事件會顯示 PatternExpandedId 中的所有模式，以及 PatternExpanded 事件的子項中的所有目標。如果模式擴充為 test_suite 包含的測試目標組合，則為任何 test_suite。針對每個無法解析的模式，BEP 會包含額外的 Aborted 事件，其中包含識別模式的 PatternExpandedId。

{
  "id": {
    "pattern": {
      "pattern":["//base:all"]
    }
  },
  "children": [
    {"targetConfigured":{"label":"//base:foo"}},
    {"targetConfigured":{"label":"//base:foobar"}}
  ],
  "expanded": {
    "testSuiteExpansions": {
      "suiteLabel": "//base:suite",
      "testLabels": "//base:foo_test"
    }
  }
}

進度

進度事件包含 Bazel 在指令執行期間產生的標準輸出和標準錯誤。此外，這些事件也會視需要自動產生，用來公告邏輯「父項」事件尚未宣布的事件 (尤其是 NamedSetOfFiles)。

TargetComplete

針對完成執行階段的每個 (target, configuration, aspect) 組合，BEP 會包含 TargetComplete 事件。這個事件包含目標的成功/失敗，以及目標要求的輸出群組。

{
  "id": {
    "targetCompleted": {
      "label": "//examples/py:bep",
      "configuration": {
        "id": "a5d130b0966b4a9ca2d32725aa5baf40e215bcfc4d5cdcdc60f5cc5b4918903b"
      }
    }
  },
  "completed": {
    "success": true,
    "outputGroup": [
      {
        "name": "default",
        "fileSets": [
          {
            "id": "0"
          }
        ]
      }
    ]
  }
}

TargetConfigured

對於完成分析階段的每個目標，BEP 中會包含 TargetConfigured 事件。這是目標「規則種類」屬性的權威來源。套用至目標的設定會顯示在事件的已宣告「子項」中。

舉例來說，使用 --experimental_multi_cpu 選項進行建構時，可能會針對具有兩個設定的單一目標產生下列 TargetConfigured 事件：

{
  "id": {
    "targetConfigured": {
      "label": "//starlark_configurations/multi_arch_binary:foo"
    }
  },
  "children": [
    {
      "targetCompleted": {
        "label": "//starlark_configurations/multi_arch_binary:foo",
        "configuration": {
          "id": "c62b30c8ab7b9fc51a05848af9276529842a11a7655c71327ade26d7c894c818"
        }
      }
    },
    {
      "targetCompleted": {
        "label": "//starlark_configurations/multi_arch_binary:foo",
        "configuration": {
          "id": "eae0379b65abce68d54e0924c0ebcbf3d3df26c6e84ef7b2be51e8dc5b513c99"
        }
      }
    }
  ],
  "configured": {
    "targetKind": "foo_binary rule"
  }
}

TargetSummary

針對每個執行的 (target, configuration) 組合，系統會在匯總成功結果中納入 TargetSummary 事件，結果涵蓋所設定目標的執行作業，以及套用至該設定目標的所有層面。

TestResult

如果要求測試，系統會針對每次測試嘗試、資料分割和每次測試執行 TestResult 事件。這可讓 BEP 取用者準確識別未通過測試的測試動作，並找出每個測試動作的測試輸出內容 (例如記錄、test.xml 檔案)。

TestSummary

如果要求測試，系統會為每個測試 (target, configuration) 傳送 TestSummary 事件，其中包含解讀測試結果的必要資訊。每項測試的嘗試次數、資料分割和執行作業次數皆包含在內，可讓 BEP 取用者區分這些維度的構件。產生匯總 TestStatus 來區分 FLAKY 測試和 FAILED 測試時，系統會將每次測試的嘗試和執行次數納入考量。

UnstructuredCommandLine

與 CommandLine 不同的是，這個事件會在展開所有 .bazelrc 檔案並考慮使用 --config 標記後，以字串格式包含未剖析的指令列旗標。

UnstructuredCommandLine 事件可能會仰賴精確地重現指定的指令執行作業。

WorkspaceConfig

單一 WorkspaceConfig 事件包含工作區的相關設定資訊，例如執行根目錄。

WorkspaceStatus

單一 WorkspaceStatus 事件包含 workspace 狀態指令的結果。