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