本頁面由 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

提供在建構中執行特定 Action 的詳細資料。根據預設，這個事件只會針對失敗的動作納入 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 的工具，然後安排本機工作區，彷彿 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 檔案相符。遞移納入的 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 事件包含工作區狀態指令的結果。