बीईपी के हर इवेंट टाइप का अपना सिमैंटिक होता है. इसकी कम से कम जानकारी, build_event_stream.proto में मौजूद होती है. यहां दी गई शब्दावली में, हर इवेंट टाइप के बारे में बताया गया है.
रद्द किया गया
अन्य इवेंट के उलट, Aborted के लिए कोई आईडी टाइप नहीं होता. ऐसा इसलिए, क्योंकि Aborted इवेंट, अन्य टाइप के इवेंट की जगह लेता है. इस इवेंट से पता चलता है कि बिल्ड की प्रोसेस बीच में ही रुक गई थी. साथ ही, जिस इवेंट आईडी के तहत यह दिखता है वह सामान्य तरीके से जनरेट नहीं हुआ था. Aborted में एक एनम और लोगों के लिए आसान शब्दों में लिखा गया ब्यौरा शामिल होता है. इससे यह पता चलता है कि बिल्ड की प्रोसेस पूरी क्यों नहीं हुई.
उदाहरण के लिए, अगर कोई बिल्ड किसी टारगेट का आकलन कर रहा है और उपयोगकर्ता Bazel को बीच में ही रोक देता है, तो बीईपी में इस तरह का इवेंट दिखता है:
{
"id": {
"targetCompleted": {
"label": "//:foo",
"configuration": {
"id": "544e39a7f0abdb3efdd29d675a48bc6a"
}
}
},
"aborted": {
"reason": "USER_INTERRUPTED"
}
}
ActionExecuted
इससे, बिल्ड में किसी खास
ऐक्शन के एक्ज़ीक्यूशन के बारे में जानकारी मिलती है. डिफ़ॉल्ट रूप से, यह इवेंट बीईपी में सिर्फ़ उन ऐक्शन के लिए शामिल होता है जो फ़ेल हो गए हैं. इससे, बिल्ड के फ़ेल होने की असल वजह की पहचान करने में मदद मिलती है. उपयोगकर्ता, --build_event_publish_all_actions फ़्लैग सेट करके, सभी ActionExecuted इवेंट शामिल कर सकते हैं.
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": Bazel क्लाइंट से Bazel को मिली कमांड लाइन को फिर से बनाया गया है. इसमें .rc फ़ाइलों से लिए गए स्टार्टअप विकल्प शामिल नहीं हैं."canonical": .rc फ़ाइलों को बड़ा करके और इनवोकेशन नीति लागू करके, असल कमांड लाइन."tool":--experimental_tool_command_lineविकल्प से भरा गया. यह बीईपी के ज़रिए, Bazel को रैप करने वाले टूल की कमांड लाइन की जानकारी देने में मददगार होता है. यह base64-encodedCommandLineबाइनरी प्रोटोकॉल बफ़र मैसेज हो सकता है, जिसका सीधे तौर पर इस्तेमाल किया जाता है. इसके अलावा, यह एक स्ट्रिंग भी हो सकती है जिसे पार्स किया जाता है, लेकिन इंटरप्रेट नहीं किया जाता. ऐसा इसलिए, क्योंकि टूल के विकल्प, 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 इवेंट के चाइल्ड में सभी टारगेट होते हैं. अगर पैटर्न, किसी 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 इवेंट भेजा जाता है. इसमें, टेस्ट के नतीजों को इंटरप्रेट करने के लिए ज़रूरी जानकारी शामिल होती है. इसमें, हर टेस्ट के लिए प्रयासों, शार्ड, और रन की संख्या शामिल होती है. इससे, बीईपी के उपभोक्ताओं को इन डाइमेंशन के हिसाब से आर्टफ़ैक्ट में अंतर करने में मदद मिलती है. FLAKY टेस्ट को FAILED टेस्ट से अलग करने के लिए, TestStatus को एग्रीगेट करते समय, हर टेस्ट के लिए प्रयासों और रन को ध्यान में रखा जाता है.
UnstructuredCommandLine
CommandLine के उलट, इस इवेंट में, पार्स नहीं किए गए कमांड लाइन
फ़्लैग, स्ट्रिंग के फ़ॉर्म में शामिल होते हैं. ये फ़्लैग, सभी
.bazelrc फ़ाइलों को बड़ा करने और
--config फ़्लैग को ध्यान में रखने के बाद, बिल्ड टूल को मिलते हैं.
किसी दिए गए कमांड के एक्ज़ीक्यूशन को सटीक तौर पर फिर से जनरेट करने के लिए, UnstructuredCommandLine इवेंट का इस्तेमाल किया जा सकता है.
WorkspaceConfig
WorkspaceConfig के एक इवेंट में, वर्कस्पेस के बारे में कॉन्फ़िगरेशन की जानकारी शामिल होती है. जैसे कि एक्ज़ीक्यूशन रूट.
WorkspaceStatus
एक सिंगल WorkspaceStatus इवेंट में, वर्कस्पेस स्टेटस
कमांड का नतीजा शामिल होता है.