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