इवेंट प्रोटोकॉल की ग्लॉसरी बनाएं

समस्या की शिकायत करें सोर्स देखें

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