हर बीईपी इवेंट टाइप के अपने सिमैंटिक होते हैं. इनके बारे में build_event_stream.proto में कम से कम जानकारी दी गई है. यहां दी गई शब्दावली में, हर इवेंट टाइप के बारे में बताया गया है.
रद्द किया गया
अन्य इवेंट के उलट, Aborted के लिए कोई आईडी टाइप नहीं होता, क्योंकि Aborted इवेंट, अन्य टाइप के इवेंट को बदल देता है. इस इवेंट से पता चलता है कि बिल्ड को समय से पहले बंद कर दिया गया था. साथ ही, जिस इवेंट आईडी के तहत यह इवेंट दिखता है उसे सामान्य तरीके से नहीं बनाया गया था. Aborted में एक enum और ऐसी जानकारी होती है जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. इससे यह पता चलता है कि बिल्ड पूरा क्यों नहीं हुआ.
उदाहरण के लिए, अगर कोई बिल्ड किसी टारगेट का आकलन कर रहा है और उपयोगकर्ता 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": Reconstructed commandline as Bazel received it from the Bazel client, without startup options sourced from .rc files."canonical": .rc फ़ाइलों के साथ कमांडलाइन को बड़ा किया गया है और इनवॉकेशन की नीति लागू की गई है."tool": यह वैल्यू,--experimental_tool_command_lineविकल्प से अपने-आप भर जाती है. यह BEP के ज़रिए, 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 से मेल खाने वाली स्ट्रक्चर की रिपोर्ट करते हैं.
ट्रांज़िटिव तौर पर शामिल किए गए डिपसेट को 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",
"--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 इवेंट के children में सभी टारगेट मौजूद होते हैं. अगर पैटर्न किसी भी 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 इवेंट भेजा जाता है. इसमें टेस्ट के नतीजों को समझने के लिए ज़रूरी जानकारी होती है. हर टेस्ट के लिए कोशिशों, शार्ड, और रन की संख्या शामिल की जाती है, ताकि बीईपी के उपभोक्ता इन डाइमेंशन के हिसाब से आर्टफ़ैक्ट में अंतर कर सकें. कुल TestStatus स्कोर जनरेट करते समय, हर टेस्ट के लिए किए गए कोशिशों और रन की संख्या को ध्यान में रखा जाता है. इससे FLAKY टेस्ट को FAILED टेस्ट से अलग किया जा सकता है.
UnstructuredCommandLine
CommandLine के उलट, इस इवेंट में अनपार्स्ड कमांडलाइन फ़्लैग को स्ट्रिंग के तौर पर शामिल किया जाता है. इन्हें बिल्ड टूल, सभी .bazelrc फ़ाइलों को बड़ा करने और --config फ़्लैग को ध्यान में रखने के बाद पाता है.
UnstructuredCommandLine इवेंट का इस्तेमाल, किसी कमांड को सटीक तरीके से फिर से चलाने के लिए किया जा सकता है.
WorkspaceConfig
एक WorkspaceConfig इवेंट में, वर्कस्पेस के कॉन्फ़िगरेशन की जानकारी होती है. जैसे, एक्ज़ीक्यूशन रूट.
WorkspaceStatus
एक WorkspaceStatus इवेंट में, workspace status
command का नतीजा शामिल होता है.