BazelCon 2025 報名和 CFP現已開放！

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

建立事件通訊協定詞彙表

回報問題查看來源 Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

每個 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 旗標的剖析內容。這個事件的存在是為了支援 Bazel 與其他工具的整合，方法是透過外部資料 (例如 ID)。

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 事件。至少會有一項設定事件。id 會由 TargetConfigured 和 TargetComplete 事件 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"
      }
    ]
  }
}

擷取

表示 Fetch 作業是指令執行作業的一部分。與其他事件不同，如果系統重複使用快取擷取結果，這個事件不會顯示在 BEP 串流中。

NamedSetOfFiles

NamedSetOfFiles 事件會回報與指令評估期間產生的檔案 depset 相符的結構。以遞移方式納入的 depsets 會以 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 事件 children 中的所有目標。如果模式擴展至任何 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 事件。這是目標「規則類型」屬性的權威來源。套用至目標的設定會顯示在事件的已發布 children 中。

舉例來說，使用 --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

如果要求進行測試，系統會為每項測試傳送 TestSummary 事件 (target, configuration)，其中包含解讀測試結果所需的資訊。測試次數、分片和執行次數都會納入，方便 BEP 消費者區分這些維度的構件。系統在產生匯總 TestStatus 時，會考量每次測試的嘗試次數和執行次數，藉此區分 FLAKY 測試和 FAILED 測試。

UnstructuredCommandLine

與 CommandLine 不同，這個事件會以字串形式，攜帶建構工具在展開所有 .bazelrc 檔案並考量 --config 標記後，遇到的未剖析指令列標記。

UnstructuredCommandLine 事件可用於精確重現特定指令的執行情況。

WorkspaceConfig

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

WorkspaceStatus

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

建立事件通訊協定詞彙表 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

已取消