हर बीईपी इवेंट टाइप का अपना सेमेनटिक्स होता है. इसकी जानकारी, build_event_stream.proto में कम से कम होती है. नीचे दी गई ग्लॉसरी में हर तरह के इवेंट के बारे में बताया गया है.
रद्द किया गया
अन्य इवेंट के उलट, Aborted का कोई आईडी टाइप नहीं होता, क्योंकि Aborted इवेंट, अन्य टाइप के इवेंट को बदल देता है. इस इवेंट से पता चलता है कि बिल्ड जल्दी खत्म हो गया और वह इवेंट आईडी, जिससे यह दिखता है वह सामान्य तरीके से जनरेट नहीं हुआ. Aborted में एक सूची और आसान शब्दों में जानकारी होती है, ताकि यह बताया जा सके कि बिल्ड पूरा क्यों नहीं हुआ.
उदाहरण के लिए, अगर कोई उपयोगकर्ता Bazel को बीच में रोकता है, तो बिल्ड किसी टारगेट का आकलन कर रहा होता है. ऐसे में, BEP में इस तरह का इवेंट शामिल होता है:
{
"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
BEP स्ट्रीम का पहला इवेंट, 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 में एक लेबल होता है, जिससे पता चलता है कि वह किस तरह का डेटा दिखाता है. BEP में ऐसे तीन इवेंट दिखते हैं:
"original": .rc फ़ाइलों से मिले स्टार्टअप विकल्पों के बिना, कमांडलाइन को फिर से बनाया गया, जैसा कि Bazel को Bazel क्लाइंट से मिला था."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 से मैच करने वाले स्ट्रक्चर की रिपोर्ट करते हैं.
ट्रांज़िटिव तरीके से शामिल किए गए डिप्सेट की पहचान 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) कॉम्बिनेशन के लिए, बीईपी में एक 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 इवेंट भेजा जाता है. साथ ही, हर टेस्ट के लिए एक शर्ड चलाया जाता है. इससे BEP के उपयोगकर्ता, यह सटीक तौर पर पता लगा सकते हैं कि किन जांच कार्रवाइयों की जांच पूरी नहीं हुई. साथ ही, हर जांच कार्रवाई के लिए जांच के आउटपुट (जैसे, लॉग,
test.xml फ़ाइलें) की पहचान कर सकते हैं.
TestSummary
अगर टेस्टिंग का अनुरोध किया जाता है, तो हर टेस्ट (target,
configuration) के लिए एक TestSummary इवेंट भेजा जाता है. इसमें टेस्ट के नतीजों को समझने के लिए ज़रूरी जानकारी होती है. हर टेस्ट के लिए, कोशिशों, शार्ड, और रन की संख्या शामिल की जाती है, ताकि बीईपी के उपभोक्ता इन डाइमेंशन में आर्टफ़ैक्ट के बीच अंतर कर सकें. FLAKY टेस्ट को FAILED टेस्ट से अलग करने के लिए, कुल TestStatus जनरेट करते समय, हर टेस्ट के लिए किए गए प्रयासों और रन को ध्यान में रखा जाता है.
UnstructuredCommandLine
CommandLine के उलट, यह इवेंट स्ट्रिंग फ़ॉर्म में ऐसे कमांडलाइन फ़्लैग दिखाता है जिन्हें पार्स नहीं किया गया है. ये ऐसे फ़्लैग होते हैं जो सभी .bazelrc फ़ाइलों को बड़ा करने और --config फ़्लैग को ध्यान में रखने के बाद, बिल्ड टूल को मिलते हैं.
किसी दिए गए कमांड को सटीक तौर पर दोहराने के लिए, UnstructuredCommandLine इवेंट का इस्तेमाल किया जा सकता है.
WorkspaceConfig
किसी एक WorkspaceConfig इवेंट में, वर्कस्पेस के बारे में कॉन्फ़िगरेशन की जानकारी होती है. जैसे, एक्सीक्यूशन रूट.
WorkspaceStatus
किसी एक WorkspaceStatus इवेंट में, वर्कस्पेस के स्टेटस के लिए दिए गए निर्देश का नतीजा होता है.