हर बीईपी इवेंट टाइप के अपने सिमैंटिक होते हैं. इनके बारे में build_event_stream.proto में कम से कम जानकारी दी गई है. यहां दी गई शब्दावली में, हर इवेंट टाइप के बारे में बताया गया है.
रद्द किया गया
अन्य इवेंट के उलट, Aborted का कोई आईडी टाइप नहीं होता, क्योंकि Aborted इवेंट, अन्य टाइप के इवेंट को बदल देता है. इस इवेंट से पता चलता है कि बिल्ड जल्दी खत्म हो गया और जिस इवेंट आईडी के तहत यह दिखता है उसे सामान्य तौर पर नहीं बनाया गया था. Aborted में एक enum और ऐसी जानकारी होती है जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. इससे यह पता चलता है कि बिल्ड पूरा क्यों नहीं हुआ.
उदाहरण के लिए, अगर कोई बिल्ड किसी टारगेट का आकलन कर रहा है और उपयोगकर्ता Bazel को रोकता है, तो बीईपी में इस तरह का इवेंट शामिल होता है:
{
"id": {
"targetCompleted": {
"label": "//:foo",
"configuration": {
"id": "544e39a7f0abdb3efdd29d675a48bc6a"
}
}
},
"aborted": {
"reason": "USER_INTERRUPTED"
}
}
ActionExecuted
यह किसी बिल्ड में किसी खास कार्रवाई के एक्ज़ीक्यूशन के बारे में जानकारी देता है. डिफ़ॉल्ट रूप से, यह इवेंट सिर्फ़ उन कार्रवाइयों के लिए बीईपी में शामिल होता है जो पूरी नहीं हो सकीं. इससे, बिल्ड फ़ेल होने की असल वजह का पता लगाने में मदद मिलती है. उपयोगकर्ता, सभी ActionExecuted इवेंट शामिल करने के लिए, --build_event_publish_all_actions फ़्लैग सेट कर सकते हैं.
BuildFinished
कमांड पूरी होने के बाद, एक BuildFinished इवेंट भेजा जाता है. इसमें कमांड के लिए एग्ज़िट कोड शामिल होता है. इस इवेंट से, पुष्टि की गई जानकारी मिलती है कि लेन-देन पूरा हुआ या नहीं.
BuildMetadata
इसमें --build_metadata फ़्लैग के पार्स किए गए कॉन्टेंट शामिल होते हैं. यह इवेंट, 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
बीईपी स्ट्रीम में पहला इवेंट, BuildStarted होता है. इसमें मेटाडेटा शामिल होता है, जो किसी भी काम के शुरू होने से पहले कमांड के बारे में बताता है.
BuildToolLogs
किसी कमांड के खत्म होने पर, एक BuildToolLogs इवेंट भेजा जाता है. इसमें बिल्ड टूल से जनरेट की गई फ़ाइलों के यूआरआई शामिल होते हैं. इनसे बिल्ड टूल के व्यवहार को समझने या डीबग करने में मदद मिल सकती है. कुछ जानकारी को इनलाइन शामिल किया जा सकता है.
{
"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
बीईपी में कई CommandLine इवेंट होते हैं. इनमें सभी कमांड-लाइन आर्ग्युमेंट (विकल्प और बिना मतलब के आर्ग्युमेंट शामिल हैं) के बारे में जानकारी होती है.
हर CommandLine इवेंट के StructuredCommandLineId में एक लेबल होता है. इससे पता चलता है कि यह इवेंट किस तरह की जानकारी देता है. बीईपी में ऐसे तीन इवेंट दिखते हैं:
"original": Reconstructed commandline as Bazel received it from the Bazel client, without startup options sourced from .rc files."canonical": .rc फ़ाइलों को बड़ा करके और लागू की गई नीति को लागू करके, कमांडलाइन को असरदार बनाया गया है."tool": यह वैल्यू,--experimental_tool_command_lineविकल्प से अपने-आप भर जाती है. यह BEP के ज़रिए, Bazel को रैप करने वाले टूल की कमांड-लाइन को दिखाने के लिए काम आता है. यह base64 में कोड किया गयाCommandLineबाइनरी प्रोटोकॉल बफ़र मैसेज हो सकता है. इसका इस्तेमाल सीधे तौर पर किया जाता है. इसके अलावा, यह ऐसी स्ट्रिंग भी हो सकती है जिसे पार्स किया जाता है, लेकिन इंटरप्रेट नहीं किया जाता. ऐसा इसलिए, क्योंकि टूल के विकल्प, Bazel के विकल्पों से अलग हो सकते हैं.
कॉन्फ़िगरेशन
बिल्ड में टॉप-लेवल के टारगेट में इस्तेमाल किए गए हर configuration के लिए, एक Configuration इवेंट भेजा जाता है. कम से कम एक कॉन्फ़िगरेशन इवेंट हमेशा मौजूद होना चाहिए. id का फिर से इस्तेमाल TargetConfigured और TargetComplete इवेंट आईडी करते हैं. साथ ही, मल्टी-कॉन्फ़िगरेशन बिल्ड में इन इवेंट को अलग-अलग करने के लिए, इसका इस्तेमाल करना ज़रूरी है.
{
"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"
}
]
}
}
लाएं
इससे पता चलता है कि कमांड को पूरा करने के लिए, फ़ेच करने की कार्रवाई की गई है. अन्य इवेंट के उलट, अगर कैश मेमोरी में सेव किए गए फ़ेच के नतीजे का दोबारा इस्तेमाल किया जाता है, तो यह इवेंट बीईपी स्ट्रीम में नहीं दिखता.
NamedSetOfFiles
NamedSetOfFiles इवेंट, कमांड के आकलन के दौरान जनरेट हुई फ़ाइलों के depset से मेल खाने वाले स्ट्रक्चर की रिपोर्ट करते हैं.
ट्रांज़िटिव तौर पर शामिल किए गए depsets को NamedSetOfFilesId से पहचाना जाता है.
स्ट्रीम के NamedSetOfFiles इवेंट को समझने के बारे में ज़्यादा जानने के लिए, बीईपी के उदाहरणों वाला पेज देखें.
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",
"--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 में शामिल टेस्ट टारगेट का सेट. जिन पैटर्न को हल नहीं किया जा सका उनके लिए, बीईपी में एक अतिरिक्त 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) कॉम्बिनेशन के लिए, बीईपी में एक TargetComplete इवेंट शामिल किया जाता है. इस इवेंट में, टारगेट के पूरा होने/न होने की जानकारी और टारगेट के लिए अनुरोध किए गए आउटपुट ग्रुप शामिल होते हैं.
{
"id": {
"targetCompleted": {
"label": "//examples/py:bep",
"configuration": {
"id": "a5d130b0966b4a9ca2d32725aa5baf40e215bcfc4d5cdcdc60f5cc5b4918903b"
}
}
},
"completed": {
"success": true,
"outputGroup": [
{
"name": "default",
"fileSets": [
{
"id": "0"
}
]
}
]
}
}
TargetConfigured
विश्लेषण के चरण को पूरा करने वाले हर टारगेट के लिए, बीईपी में 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 इवेंट भेजा जाता है. ऐसा हर टेस्ट के लिए, हर शार्ड के लिए, और हर रन के लिए किया जाता है. इससे बीईपी के उपभोक्ताओं को यह पता चलता है कि कौनसी टेस्ट कार्रवाइयां, टेस्ट में फ़ेल हुई हैं. साथ ही, उन्हें हर टेस्ट कार्रवाई के लिए टेस्ट आउटपुट (जैसे कि लॉग, test.xml फ़ाइलें) का पता चलता है.
TestSummary
अगर टेस्टिंग का अनुरोध किया जाता है, तो हर टेस्ट (target,
configuration) के लिए एक TestSummary इवेंट भेजा जाता है. इसमें टेस्ट के नतीजों को समझने के लिए ज़रूरी जानकारी होती है. हर टेस्ट के लिए, कोशिशों, शार्ड, और रन की संख्या शामिल की जाती है, ताकि बीईपी उपभोक्ताओं को इन डाइमेंशन के हिसाब से आर्टफ़ैक्ट में अंतर करने में मदद मिल सके. कुल TestStatus स्कोर जनरेट करते समय, हर टेस्ट के लिए किए गए कोशिशों और रन की संख्या को ध्यान में रखा जाता है. इससे FLAKY टेस्ट को FAILED टेस्ट से अलग किया जा सकता है.
UnstructuredCommandLine
CommandLine के उलट, इस इवेंट में पार्स न किए गए कमांडलाइन फ़्लैग, स्ट्रिंग के तौर पर शामिल होते हैं. ये फ़्लैग, बिल्ड टूल को तब मिलते हैं, जब वह सभी .bazelrc फ़ाइलों को बड़ा कर देता है और --config फ़्लैग को ध्यान में रखता है.
UnstructuredCommandLine इवेंट का इस्तेमाल, किसी कमांड को सटीक तरीके से फिर से चलाने के लिए किया जा सकता है.
WorkspaceConfig
एक WorkspaceConfig इवेंट में, वर्कस्पेस के कॉन्फ़िगरेशन की जानकारी होती है. जैसे, एक्ज़ीक्यूशन रूट.
WorkspaceStatus
एक WorkspaceStatus इवेंट में, workspace status
command का नतीजा शामिल होता है.