हर BEP इवेंट टाइप के अपने सिमेंटिक्स होते हैं, जिन्हें कम से कम 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
बीईपी स्ट्रीम के पहले इवेंट, 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
BEP में कई CommandLine इवेंट होते हैं, जिनमें सभी कमांड-लाइन आर्ग्युमेंट के बारे में बताया जाता है. इनमें विकल्प और ऐसे आर्ग्युमेंट शामिल होते हैं जिनकी व्याख्या नहीं की जा सकती.
हर CommandLine इवेंट के StructuredCommandLineId में एक लेबल होता है. इससे पता चलता है कि इवेंट किस तरह का है. बीईपी में इस तरह के तीन इवेंट दिखते हैं:
"original": कमांडलाइन को फिर से बनाया गया, जिस तरह Basel को Bagel क्लाइंट से मिला. इसमें .rc फ़ाइलों से, स्टार्टअप के विकल्प नहीं थे."canonical": असरदार कमांडलाइन, जिसमें .rc फ़ाइलों को बड़ा किया गया है और उसे शुरू करने की नीति लागू की गई है."tool":--experimental_tool_command_lineविकल्प से पॉप्युलेट किया जाता है. इससे, बीईपी के ज़रिए बेज़ल को रैप करने वाले टूल की कमांड-लाइन के बारे में बताने में मदद मिलती है. यह एक base64 कोड में बदला गयाCommandLineबाइनरी प्रोटोकॉल बफ़र मैसेज हो सकता है. इसका इस्तेमाल सीधे तौर पर किया जाता है. इसके अलावा, यह एक ऐसी स्ट्रिंग हो सकती है जिसे पार्स किया गया हो, लेकिन उसका मतलब न समझा गया हो. ऐसा इसलिए हो सकता है, क्योंकि टूल के विकल्प बेज़ल से अलग हो सकते हैं.
कॉन्फ़िगरेशन
किसी बिल्ड में टॉप-लेवल टारगेट में इस्तेमाल किए गए हर 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 इवेंट जनरेट होता है. इससे यह पता चलता है कि वर्कस्पेस में सिमलिंक कैसे मैनेज किए जाने चाहिए.
इसकी मदद से, ऐसे टूल बनाए जा सकते हैं जो Bagel को रिमोट तौर पर इस्तेमाल करते हों. साथ ही, लोकल वर्कस्पेस को इस तरह व्यवस्थित करते हों जैसे कि Basel को स्थानीय तौर पर चलाया गया हो.
{
"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"
}
}
}
प्रगति
प्रोग्रेस इवेंट में, स्टैंडर्ड आउटपुट और स्टैंडर्ड गड़बड़ी शामिल होती है. यह गड़बड़ी, कमांड के एक्ज़ीक्यूट करने के दौरान Basel की तरफ़ से जनरेट होती है. ये इवेंट उन इवेंट की ज़रूरत के मुताबिक अपने-आप जनरेट होते हैं जिनकी घोषणा लॉजिकल "पैरंट" इवेंट (खास तौर पर, 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 इवेंट में, वर्कस्पेस की स्थिति के लिए दिए गए निर्देश का नतीजा होता है.