बीईपी के हर इवेंट टाइप का अपना सिमैंटिक होता है. इसकी कम से कम जानकारी, build_event_stream.proto में मौजूद होती है. यहां दी गई शब्दावली में, हर इवेंट टाइप के बारे में बताया गया है.
रद्द किया गया
अन्य इवेंट के उलट, Aborted के लिए कोई आईडी टाइप नहीं होता. ऐसा इसलिए, क्योंकि Aborted इवेंट, अन्य टाइप के इवेंट की जगह लेता है. इस इवेंट से पता चलता है कि बिल्ड की प्रोसेस बीच में ही रुक गई थी. साथ ही, जिस इवेंट आईडी के तहत यह दिखता है वह सामान्य तरीके से जनरेट नहीं हुआ था. Aborted में एक एनम और उपयोगकर्ता के लिए आसान शब्दों में लिखा गया ब्यौरा शामिल होता है. इससे यह पता चलता है कि बिल्ड की प्रोसेस पूरी क्यों नहीं हुई.
उदाहरण के लिए, अगर कोई बिल्ड किसी टारगेट का आकलन कर रहा है और उपयोगकर्ता 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": 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 भी शामिल होती है. हालांकि, यह ज़रूरी नहीं है कि 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 इवेंट में, वर्कस्पेस स्टेटस
कमांड का नतीजा शामिल होता है.