नियमित कर्मचारियों की मदद से आपका काम तेज़ी से हो सकता है. अगर आपने आपने अपने ऐप्लिकेशन में बार-बार कुछ ऐसा किया हो जिसकी स्टार्टअप लागत ज़्यादा हो या क्रॉस-ऐक्शन कैशिंग का फ़ायदा मिलता है, तो हो सकता है कि आपको मैन्युअल तौर पर कर्मचारी को ये कार्रवाइयां करने के लिए कहेंगे.
Basel सर्वर stdin/stdout का इस्तेमाल करके कर्मचारी से संपर्क करता है. यह
प्रोटोकॉल बफ़र या JSON स्ट्रिंग का इस्तेमाल करती है.
वर्कर लागू करने के दो हिस्से होते हैं:
कर्मचारी को
लगातार काम करने वाला कर्मचारी कुछ ज़रूरी शर्तों को पूरा करता है:
- यह लिखा है
WorkRequests
stdinसे. - यह लिखते हैं
WorkResponses
(और सिर्फ़
WorkResponses)stdoutतक. - यह
--persistent_workerफ़्लैग को स्वीकार करता है. रैपर को--persistent_workerकमांड लाइन फ़्लैग और खुद को सिर्फ़ तभी स्थायी बनाता है, जब फ़्लैग कर दिया जाता है, नहीं तो इसे एक-एक करके कंपाइल करना होगा और बाहर निकलना होगा.
अगर आपका प्रोग्राम इन ज़रूरी शर्तों को पूरा करता है, तो इसका इस्तेमाल लगातार कर्मचारी!
काम के अनुरोध
WorkRequest में वर्कर के लिए आर्ग्युमेंट की एक सूची होती है.
पाथ-डाइजेस्ट पेयर उन इनपुट को दिखाते हैं जिन्हें कर्मचारी ऐक्सेस कर सकता है (यह
लागू है, लेकिन इस जानकारी का इस्तेमाल कैश मेमोरी में करने के लिए किया जा सकता है) और अनुरोध आईडी, जो 0 है
एक ही जगह पर काम करना पड़ता है.
ध्यान दें: प्रोटोकॉल बफ़र में, "स्नेक केस" का इस्तेमाल किया जाता है (request_id),
JSON प्रोटोकॉल में "कैमल केस" का इस्तेमाल किया जाता है (requestId). इस दस्तावेज़ में ऊंट के केस का इस्तेमाल किया गया है
के उदाहरण हैं, लेकिन फ़ील्ड के बारे में बात करते समय सांप का केस
प्रोटोकॉल का इस्तेमाल करना चाहिए.
{
"arguments" : ["--some_argument"],
"inputs" : [
{ "path": "/path/to/my/file/1", "digest": "fdk3e2ml23d"},
{ "path": "/path/to/my/file/2", "digest": "1fwqd4qdd" }
],
"requestId" : 12
}
वैकल्पिक verbosity फ़ील्ड का इस्तेमाल, डीबग करने के ज़्यादा आउटपुट का अनुरोध करने के लिए किया जा सकता है
से मिलता है. यह पूरी तरह कर्मचारी पर निर्भर करता है कि वह क्या और कैसे काम करेगा. ज़्यादा
वैल्यू, ज़्यादा शब्दों वाले आउटपुट को दिखाती हैं. --worker_verbose फ़्लैग को पास किया जा रहा है
Basel, verbosity फ़ील्ड को 10 पर सेट करता है, लेकिन छोटी या बड़ी वैल्यू का इस्तेमाल किया जा सकता है
का इस्तेमाल करके मैन्युअल रूप से किया जा सकता है.
वैकल्पिक sandbox_dir फ़ील्ड का इस्तेमाल सिर्फ़ वे कर्मचारी करते हैं जो सहायता करते हैं
मल्टीप्लेक्स सैंडबॉक्सिंग.
काम से जुड़े जवाब
WorkResponse में एक अनुरोध आईडी, एक शून्य या नॉन-ज़ीरो एक्ज़िट कोड होता है, और
ऐसी आउटपुट स्ट्रिंग जो प्रोसेस या एक्ज़ीक्यूट करते समय हुई किसी भी गड़बड़ी के बारे में बताती है
अनुरोध किया है. output फ़ील्ड में कम शब्दों वाली जानकारी होती है; पूरे लॉग हो सकते हैं
कर्मचारी के stderr पर होना चाहिए. क्योंकि कर्मचारी सिर्फ़ जानकारी लिख सकते हैं
WorkResponses, stdout के लिए काम करता है. आम तौर पर, कर्मचारी stdout को रीडायरेक्ट करता है
stderr में इस्तेमाल किए जाने वाले किसी भी टूल की तुलना कर सकता है.
{
"exitCode" : 1,
"output" : "Action failed with the following message:\nCould not find input
file \"/path/to/my/file/1\"",
"requestId" : 12
}
प्रोटोबफ़ के नियम के मुताबिक, सभी फ़ील्ड वैकल्पिक होते हैं. हालांकि, Basel को
WorkRequest और उससे जुड़े WorkResponse में एक ही अनुरोध हो
id, इसलिए अगर वह शून्य नहीं है, तो अनुरोध आईडी दर्ज करना आवश्यक है. यह एक मान्य है
WorkResponse.
{
"requestId" : 12,
}
0 का request_id "सिंगलप्लेक्स" को दिखाता है अनुरोध, इस अनुरोध के समय उपयोग किया जाता है
को अन्य अनुरोधों के साथ प्रोसेस नहीं किया जा सकता. सर्वर गारंटी देता है कि
किसी दिए गए वर्कर को या तो केवल request_id 0 या केवल
request_id, शून्य से ज़्यादा है. सिंगलप्लेक्स अनुरोध, सीरियल में भेजे जाते हैं
उदाहरण के लिए, सर्वर तब तक दूसरा अनुरोध नहीं भेजता, जब तक कि उसे
जवाब (रद्द करने के अनुरोधों को छोड़कर, नीचे देखें).
ज़रूरी जानकारी
- प्रत्येक प्रोटोकॉल बफ़र से पहले उसकी लंबाई
varintप्रारूप में होती है (देखेंMessageLite.writeDelimitedTo(). - JSON के अनुरोधों और उनके जवाबों के पहले, साइज़ दिखाने वाला संकेत नहीं होता.
- JSON अनुरोधों का स्ट्रक्चर, प्रोटोबफ़ के स्ट्रक्चर जैसा ही रहता है, लेकिन स्टैंडर्ड नियम का इस्तेमाल किया जाता है JSON और सभी फ़ील्ड के नामों के लिए ऊंट केस का इस्तेमाल करें.
- पुराने और आगे जाने वाले कोड के साथ काम करने वाली प्रॉपर्टी को पहले जैसा बनाए रखने के लिए प्रोटोबफ़ के तौर पर, JSON कर्मियों को इन मैसेज में अज्ञात फ़ील्ड को सहन करना चाहिए, और अनुपलब्ध मानों के लिए प्रोटोबफ़ डिफ़ॉल्ट का उपयोग करें.
- Basel, अनुरोधों को प्रोटोबफ़ के तौर पर सेव करता है और इनका इस्तेमाल करके उन्हें JSON में बदलता है प्रोटोबफ़ का JSON फ़ॉर्मैट
रद्द किया जाना
दूसरा तरीका यह है कि वर्कर, काम खत्म होने से पहले काम के अनुरोधों को रद्द करने की अनुमति दे सकते हैं.
यह डाइनैमिक एक्ज़ीक्यूशन के मामले में खास तौर पर मददगार है, जहां लोकल
तेज़ी से रिमोट तरीके से एक्ज़ीक्यूट करने की वजह से, एक्ज़ीक्यूशन में नियमित तौर पर रुकावट आ सकती है. अनुमति देने के लिए
रद्द करने के बाद, supports-worker-cancellation: 1 को
execution-requirements फ़ील्ड (नीचे देखें) और
--experimental_worker_cancellation फ़्लैग.
रद्द करने का अनुरोध एक WorkRequest होता है, जिसमें cancel फ़ील्ड सेट होता है (और
इसी तरह एक रद्द जवाब, was_cancelled के साथ एक WorkResponse होता है
फ़ील्ड सेट). सिर्फ़ एक फ़ील्ड, जिसे रद्द करने के अनुरोध या रद्द करने के अनुरोध में होना चाहिए
रिस्पॉन्स request_id है. इससे पता चलता है कि किस अनुरोध को रद्द करना है. request_id
सिंगलप्लेक्स वर्कर के लिए फ़ील्ड 0 होगा या पिछले फ़ील्ड का नॉन-0 request_id होगा
मल्टीप्लेक्स कर्मियों को WorkRequest भेजा. सर्वर, सदस्यता रद्द करने के अनुरोध भेज सकता है
उन अनुरोधों के लिए जिनके जवाब कर्मचारी ने पहले ही दे दिए हैं. इस मामले में,
अनुरोध पर ध्यान नहीं देना चाहिए.
रद्द नहीं किए गए WorkRequest मैसेज का सिर्फ़ एक बार जवाब देना ज़रूरी है, चाहे या
नहीं, इसे रद्द किया गया. सर्वर से अनुरोध रद्द करने के बाद, वर्कर
request_id सेट और was_cancelled के साथ WorkResponse की मदद से जवाब दें
फ़ील्ड को 'सही' पर सेट किया गया है. नियमित WorkResponse भेजना भी स्वीकार किया जाता है, लेकिन
output और exit_code फ़ील्ड को अनदेखा कर दिया जाएगा.
WorkRequest के लिए जवाब भेजे जाने के बाद, वर्कर को
फ़ाइलों को अपनी वर्किंग डायरेक्ट्री में सेव कर सकते हैं. सर्वर फ़ाइलों को खाली कर सकता है,
इसमें कुछ समय के लिए सेव की गई फ़ाइलें भी शामिल हैं.
कर्मचारी का इस्तेमाल करने वाला नियम बनाना
आपको एक ऐसा नियम भी बनाना होगा जो लागू की जाने वाली कार्रवाइयों को जनरेट करता हो कर्मचारी. स्टारलार्क के लिए कर्मचारी का इस्तेमाल करने वाला नियम बनाना कोई दूसरा नियम बनाना.
इसके अलावा, नियम में वर्कर का रेफ़रंस होना चाहिए और इसके तहत की जाने वाली कार्रवाइयों की कुछ शर्तें होती हैं.
कर्मचारी को रेफ़र किया जा रहा है
वर्कर का इस्तेमाल करने वाले नियम में, वर्कर के बारे में बताने वाला फ़ील्ड शामिल होना चाहिए
, इसलिए आपको \*\_binary नियम का एक इंस्टेंस बनाना होगा, ताकि
अपने कर्मचारी को. अगर आपके वर्कर को MyWorker.Java कहा जाता है, तो यह
संबंधित नियम:
java_binary(
name = "worker",
srcs = ["MyWorker.Java"],
)
इससे "कर्मचारी" लेबल जोड़ा गया है, जो वर्कर बाइनरी से जुड़ा है. इसके बाद, आपको ऐसे नियम को तय करता है जो वर्कर का इस्तेमाल करता है. इस नियम से एक ऐसा एट्रिब्यूट तय होना चाहिए जो वर्कर बाइनरी को दिखाता है.
अगर आपकी बनाई गई वर्कर बाइनरी, "वर्क" नाम के पैकेज में है, जो सबसे ऊपर है , यह एट्रिब्यूट की परिभाषा हो सकती है:
"worker": attr.label(
default = Label("//work:worker"),
executable = True,
cfg = "exec",
)
cfg = "exec" बताता है कि वर्कर को आपके डिवाइस पर चलने के लिए बनाया जाना चाहिए
टारगेट प्लैटफ़ॉर्म के बजाय इस्तेमाल करने के लिए प्लैटफ़ॉर्म (यानी, वर्कर का इस्तेमाल किया जाता है)
बिल्ड के दौरान टूल के तौर पर).
काम से जुड़ी कार्रवाई की ज़रूरी शर्तें
वर्कर का इस्तेमाल करने वाला नियम, वर्कर के लिए कार्रवाइयां बनाता है. ये कार्रवाइयों की कुछ ज़रूरी शर्तें होती हैं.
"तर्क" फ़ील्ड. यह स्ट्रिंग की एक सूची लेता है, जिसमें से अंतिम जो स्टार्टअप होने पर वर्कर को भेजे जाते हैं. इसमें अंतिम तत्व "तर्क" सूची एक
flag-file(@-पूर्वानुमान) तर्क है. कर्मचारियों ने पढ़ा तय फ़्लैगफ़ाइल से हर WorkRequest के आधार पर आर्ग्युमेंट. आपका नियम इस फ़्लैगफ़ाइल में वर्कर के लिए नॉन-स्टार्टअप तर्क लिख सकता है."execution-requirements" फ़ील्ड, जिसमें एक शब्दकोश होता है जिसमें
"supports-workers" : "1","supports-multiplex-workers" : "1"या दोनों."तर्क" और "लागू करने की ज़रूरी शर्तें" सभी फ़ील्ड में वैल्यू डालना ज़रूरी है कर्मियों को कार्रवाइयां भेजी गईं. इसके अलावा, ऐसी कार्रवाइयां जिन्हें JSON कर्मियों को
"requires-worker-protocol" : "json"को ज़रूरी शर्तों वाला फ़ील्ड."requires-worker-protocol" : "proto"भी एक्ज़ीक्यूशन की एक मान्य ज़रूरत होती है. हालांकि, प्रोटो वर्कर के लिए यह ज़रूरी नहीं होती, क्योंकि वे डिफ़ॉल्ट हैं.प्रोग्राम चलाने की ज़रूरी शर्तों में
worker-key-mnemonicभी सेट किया जा सकता है. यह यह तब फ़ायदेमंद हो सकता है, जब एक से ज़्यादा ऐक्शन टाइप के लिए एक्ज़ीक्यूटेबल का फिर से इस्तेमाल किया जा रहा हो और इस वर्कर की कार्रवाइयों में अंतर करना है.कार्रवाई के दौरान, जनरेट की गई अस्थायी फ़ाइलों को कर्मचारी की डायरेक्ट्री पर जाएं. इससे सैंडबॉक्सिंग की सुविधा चालू हो जाती है.
"कर्मचारी" के साथ नियम की परिभाषा मानते हुए एट्रिब्यूट की वैल्यू ऊपर बताई गई है. इसके अलावा,
से लेकर "srcs" इनपुट के बारे में बताने वाला एट्रिब्यूट, एक "आउटपुट" विशेषता
आउटपुट और "आर्ग" की वैल्यू दिखाता है कर्मचारी को दिखाने वाला एट्रिब्यूट
स्टार्टअप तर्क हो, तो ctx.actions.run को किया जाने वाला कॉल यह हो सकता है:
ctx.actions.run(
inputs=ctx.files.srcs,
outputs=[ctx.outputs.output],
executable=ctx.executable.worker,
mnemonic="someMnemonic",
execution_requirements={
"supports-workers" : "1",
"requires-worker-protocol" : "json"},
arguments=ctx.attr.args + ["@flagfile"]
)
एक अन्य उदाहरण के लिए, देखें परसिस्टेंट वर्कर को लागू करना.
उदाहरण
Basel कोड बेस का इस्तेमाल होता है Java कंपाइलर वर्कर, इसके अलावा, JSON वर्कर का उदाहरण इसका इस्तेमाल हमारे इंटिग्रेशन टेस्ट में किया जाता है.
आप इनका इस्तेमाल कर सकते हैं मैल बनाना का इस्तेमाल करें.
एक ऐसे नियम के उदाहरण के लिए जो कर्मचारी का उपयोग करता है, बेज़ल के लिए देखें वर्कर इंटिग्रेशन टेस्ट.
बाहरी योगदान देने वालों ने कई भाषाओं में कर्मचारियों को काम पर रखा है; CANNOT TRANSLATE इसे देखो बेज़ल के ज़रिए लगातार काम करने वाले कर्मचारियों पर, कई तरीकों से काम करने की सुविधा लागू करना. आप GitHub पर और भी कई उदाहरण देखें!