GH Actions - Cache Poisoning
कैश पॉइज़निंग
action/cache गिट एक्शन का उपयोग CI में कहीं भी किया जा सकता है: एक चरण चलाने के दौरान और दूसरा चरण वर्कफ़्लो के बाद (यदि रन एक्शन ने कैश-मिस लौटाया हो).
रन एक्शन - कैश खोजने और प्राप्त करने के लिए उपयोग किया जाता है। खोज कैश कुंजी का उपयोग करके की जाती है, जिसका परिणाम एक कैश-हिट (सफलता, कैश में डेटा मिला) या कैश-मिस होता है। यदि पाया जाता है, तो फ़ाइल और निर्देशिकाएँ कैश से प्राप्त की जाती हैं और सक्रिय उपयोग के लिए डाउनलोड की जाती हैं। यदि परिणाम कैश-मिस है, तो चाहिए गए फ़ाइल और निर्देशिकाएँ पहली बार उन्हें बुलाया जाता है जैसे कि वे होते हैं।
वर्कफ़्लो के बाद का एक्शन - कैश को सहेजने के लिए उपयोग किया जाता है। यदि रन एक्शन में कैश कॉल का परिणाम कैश-मिस लौटाता है, तो यह एक्शन द्वारा वह निर्देशिकाओं की वर्तमान स्थिति को सहेजेगा जिन्हें हम कैश करना चाहते हैं और दिए गए कुंजी के साथ। यह एक्शन स्वचालित रूप से होता है और उद्देश्य से निर्देशित नहीं किया जाना चाहिए।
पहुँच प्रतिबंध अलग-अलग शाखाओं के बीच एक मानसिक सीमा बनाकर कैश आइसोलेशन और सुरक्षा प्रदान करती हैं (उदाहरण के लिए: शाखा Feature-A के लिए बनाए गए कैश [मुख्य शाखा के साथ] को शाखा Feature-B [मुख्य शाखा के साथ] के लिए पुल अनुरोध तक पहुँच नहीं होगी).
कैश एक्शन पहले कुंजी के लिए कैश हिट खोजता है और वर्कफ़्लो रन करने वाली शाखा में कुंजी को बहाल करता है। यदि मौजूदा शाखा में कोई हिट नहीं है, तो कैश एक्शन माता शाखा और अपस्ट्रीम शाखाओं में कुंजी खोजता है और कुंजी को बहाल करता है।
कैश का उपयोग शाखा (वर्तमान और माता), अर्थात् कहीं भी कैश की पहुँच प्रतिबंध द्वारा सीमित होता है, जिसका अर्थ है कि उसी शाखा के सभी वर्कफ़्लो को रन के लिए प्रदान की जाती है।
एक और महत्वपूर्ण नोट है कि GitHub परिवर्तनों की अनुमति नहीं देता है जब एंट्री पुश की जाती है - कैश एंट्री रीड-ओनली रिकॉर्ड होती हैं।
हमने एक उदाहरण CI का उपयोग किया जिसमें दो वर्कफ़्लो शामिल थे। यह उदाहरण दिखाता है कि एक हमला कैसे कम अनुमति वाले वर्कफ़्लो से उच्च अनुमति वाले वर्कफ़्लो में पिवट कर सकता है।
यूनिट-टेस्ट वर्कफ़्लो यूनिट-टेस्ट और कोड कवरेज टूल चलाता है। हम मानते हैं कि इनमें से एक टूल खतरनाक या दूरस्थ कोड निष्पादन के प्रति संकल्पित है। वर्क
Last updated