हर बीईपी इवेंट टाइप का अपना सिमैंटिक होता है. इस बारे में कम से कम जानकारी build_event_stream.proto में दी गई है. नीचे दी गई शब्दावली हर इवेंट टाइप के बारे में बताती है.
रद्द किया गया
दूसरे इवेंट से अलग, Aborted
में उससे जुड़ा आईडी टाइप नहीं होता, क्योंकि
Aborted
इवेंट, दूसरे तरह के इवेंट को बदल देता है. इस इवेंट से पता चलता है कि
बिल का बिल्ड पहले ही खत्म हो गया था और जिस इवेंट आईडी के तहत यह दिखता है वह आम तौर पर
नहीं बनाया गया था. Aborted
में एक Enum और लोगों के हिसाब से जानकारी देने वाला ब्यौरा होता है, जो यह बताता है कि बिल्ड क्यों पूरा नहीं हुआ.
उदाहरण के लिए, अगर कोई बिल्ड तब टारगेट का आकलन करता है, जब उपयोगकर्ता 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"
: Bazel से मिलने के बाद कमांडलाइन, फिर से तैयार की गई. इसमें .rc फ़ाइलों से स्टार्टअप के विकल्प नहीं मिले."canonical"
: .rc फ़ाइलों के साथ लागू होने वाली कमांडलाइन को बड़ा किया गया और उसे शुरू करने की नीति लागू की गई."tool"
:--experimental_tool_command_line
विकल्प से भरा गया. इससे बीईपी के ज़रिए, बैजल को रैप करने वाले टूल की कमांड-लाइन समझने में मदद मिलती है. यह base64 कोड वालाCommandLine
बाइनरी प्रोटोकॉल बफ़र मैसेज हो सकता है, जिसे सीधे तौर पर इस्तेमाल किया जाता है. इसके अलावा, यह एक ऐसी स्ट्रिंग हो सकती है जिसे पार्स तो किया जाता है, लेकिन इसका मतलब नहीं निकाला जाता (टूल के विकल्प, 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
स्ट्रक्चर की रिपोर्ट करते हैं.
ट्रांज़िट के तौर पर शामिल किए गए डेटा सेट की पहचान, 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",
"--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"
}
}
}
प्रगति
प्रोग्रेस इवेंट में, स्टैंडर्ड आउटपुट और मानक गड़बड़ी शामिल होती है जो 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
इवेंट भेजा जाता है. साथ ही, हर टेस्ट को चलाने के लिए भी इसे भेजा जाता है. इसकी मदद से BEP उपभोक्ताओं को यह पता चलता है कि उनकी जांच में कौन-कौनसी कार्रवाइयां फ़ेल हुई हैं. साथ ही, वे हर टेस्ट ऐक्शन के लिए टेस्ट आउटपुट (जैसे कि लॉग, test.xml फ़ाइलें) की पहचान कर सकते हैं.
TestSummary
अगर टेस्टिंग का अनुरोध किया जाता है, तो हर टेस्ट के लिए TestSummary
इवेंट भेजा जाता है (target,
configuration)
. इसमें टेस्ट के नतीजों को समझने के लिए ज़रूरी जानकारी होती है. हर टेस्ट में कितनी बार कोशिश, शार्ड और रन किया जा सकता है, इसे भी शामिल किया जाता है, ताकि बीईपी उपभोक्ता इन डाइमेंशन में आर्टफ़ैक्ट में अंतर कर सकें. एग्रीगेट TestStatus
टेस्ट करते समय, हर टेस्ट के लिए की गई कोशिशों और रनों को ध्यान में रखा जाता है, ताकि FAILED
टेस्ट और FLAKY
टेस्ट के बीच अंतर किया जा सके.
UnstructuredCommandLine
CommandLine से अलग, यह इवेंट स्ट्रिंग के रूप में पार्स न किए गए कमांडलाइन फ़्लैग को उसी तरह ले जाता है जैसा कि बिल्ड टूल में मिलता है. यह सभी .bazelrc
फ़ाइलों को बड़ा करने और --config
फ़्लैग को ध्यान में रखकर बनाया गया होता है.
किसी निर्देश को लागू करने से जुड़ी सटीक प्रोसेस को फिर से पूरा करने के लिए, UnstructuredCommandLine
इवेंट पर भरोसा किया जा सकता है.
WorkspaceConfig
एक WorkspaceConfig
इवेंट में, फ़ाइल फ़ोल्डर के कॉन्फ़िगरेशन की जानकारी होती है, जैसे कि एक्ज़ीक्यूशन रूट.
WorkspaceStatus
WorkspaceStatus
के एक इवेंट में, वर्कस्पेस की स्थिति
कमांड का नतीजा शामिल होता है.