बीईपी के हर इवेंट टाइप का अपना सिमैंटिक होता है. इसकी कम से कम जानकारी, 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 क्लाइंट से मिले कमांडलाइन को फिर से बनाया गया है. इसमें .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 इवेंट में, वर्कस्पेस स्टेटस
कमांड का नतीजा शामिल होता है.