Dependabot का शोर घटाएँ—तीन दिन की रोक सुरक्षा अपडेट पर लागू नहीं

Dependabot की अनावश्यक पुल रिक्वेस्ट घटाने के लिए संस्करण अपडेट की जाँच साप्ताहिक रखें, गौण और सुधार संस्करणों को समूहित करें और प्रमुख संस्करणों के लिए लंबी रोक तय करें। GitHub का विकल्प संदर्भ बताता है कि तीन दिन की डिफ़ॉल्ट रोक केवल संस्करण अपडेट पर लागू होती है, सुरक्षा अपडेट पर नहीं।

इसके लिए रिपॉजिटरी की .github निर्देशिका में dependabot.yml रखें। GitHub की विन्यास प्रक्रिया के अनुसार फ़ाइल में पैकेज प्रबंधक, निर्भरता फ़ाइलों का स्थान और संस्करण जाँच की आवृत्ति लिखी जाती है। नीचे का नमूना मूल निर्देशिका में निर्भरता फ़ाइलों वाली npm परियोजना के लिए है; सुरक्षा अपडेट का समूह उसी फ़ाइल में अलग नियम से रखा गया है।

कॉपी करने योग्य विन्यास

निम्न दो पंक्तियाँ इसी क्रम में .github/dependabot.yml में रखें। दूसरी पंक्ति संक्षिप्त विन्यास प्रारूप में है; उसे एक ही पंक्ति में कॉपी करें। यह उदाहरण गौण और सुधार संस्करणों को एक समूह में रखता है, प्रमुख संस्करणों को देर से पात्र बनाता है और सुरक्षा सुधारों के लिए अलग समूह बनाता है।

version: 2

updates: [{package-ecosystem: 'npm', directory: '/', schedule: {interval: 'weekly'}, cooldown: {semver-major-days: 14}, groups: {routine: {patterns: ['*'], update-types: ['minor', 'patch']}, security: {applies-to: 'security-updates', patterns: ['*']}}}]

प्रमुख संस्करणों के लिए चौदह दिन उदाहरण के तौर पर चुनी गई अवधि है। सामान्य संस्करणों के लिए तीन दिन की डिफ़ॉल्ट रोक बनी रहती है; उसे फ़ाइल में दोहराने की आवश्यकता नहीं है। प्रमुख संस्करण समूह में नहीं हैं, इसलिए पात्र होने पर उनकी अलग पुल रिक्वेस्ट बन सकती है। इससे संभावित बड़े बदलाव सामान्य समूह की समीक्षा में शामिल नहीं होते।

नमूने में मूल निर्देशिका का पथ तभी सही है जब परियोजना की निर्भरता फ़ाइलें वहीं हों। वे किसी उपनिर्देशिका में हैं तो उसका वास्तविक पथ लिखें। दूसरे पैकेज प्रबंधक की निर्भरताओं के लिए अलग प्रविष्टि चाहिए; इस विन्यास के समूह केवल यहाँ चुने गए पैकेज प्रबंधक की निर्भरताओं पर काम करेंगे।

समय-सारणी, रोक और समूह किस क्रम में काम करते हैं

समय-सारणी तय करती है कि Dependabot नए संस्करण कब खोजेगा। निर्धारित जाँच के समय किसी रिलीज़ की रोक अवधि अभी चल रही हो तो उस संस्करण को छोड़ दिया जाता है। अवधि पूरी होने पर संस्करण अगली निर्धारित जाँच में फिर पात्र हो सकता है; रोक समाप्त होने का क्षण अपने आप पुल रिक्वेस्ट खुलने का समय नहीं बनता।

नमूने की साप्ताहिक जाँच में गौण और सुधार संस्करण सामान्य रोक पार करने के बाद विचार में आते हैं। प्रमुख संस्करणों पर चुनी गई चौदह दिन की अवधि लागू होती है। टीम अपनी समीक्षा क्षमता के अनुसार इस उदाहरण अवधि को बदल सकती है: लंबी अवधि प्रमुख बदलावों की समीक्षा पीछे ले जाएगी, जबकि छोटी अवधि उन्हें जल्दी सामने ला सकती है।

समूह बनाने का काम पात्र अपडेट को साझा पुल रिक्वेस्ट में समेटना है। नमूने का नियमित समूह गौण और सुधार संस्करणों को शामिल करता है; तारांकन चिह्न चुने गए पैकेज प्रबंधक की मिलती हुई निर्भरताओं को दर्शाता है। किसी निर्भरता का बदलाव समूह के नियम से न मिले तो उसकी अलग पुल रिक्वेस्ट बन सकती है। समूह का नियम जाँच का दिन या रिलीज़ की रोक अवधि नहीं बदलता।

इन नियंत्रणों को अलग समझना उपयोगी है। केवल साप्ताहिक जाँच रखने से उसी दिन कई अलग पुल रिक्वेस्ट आ सकती हैं; केवल समूह बनाने से हाल में जारी संस्करण की पात्रता नहीं टलती। समय-सारणी समीक्षा का अवसर तय करती है, रोक नए संस्करण को कुछ समय के लिए बाहर रखती है और समूह उस अवसर पर पात्र बदलावों को समेटता है।

सुरक्षा अपडेट का अलग रास्ता

सुरक्षा सुधारों का समूह नियमित संस्करण समूह से अलग है। GitHub के सुरक्षा अपडेट निर्देश के अनुसार समूहित सुरक्षा पुल रिक्वेस्ट के लिए निर्भरता ग्राफ़, Dependabot अलर्ट और Dependabot सुरक्षा अपडेट सक्षम होने चाहिए। विन्यास फ़ाइल में समूह लिखना इन सुविधाओं को अपने आप चालू नहीं करता।

सुरक्षा समूह उपलब्ध सुधारों को साझा पुल रिक्वेस्ट में ला सकता है। यदि टीम हर सुरक्षा सुधार की अलग पुल रिक्वेस्ट चाहती है, तो नमूने से केवल सुरक्षा समूह हटाए और सुरक्षा अपडेट की सुविधा चालू रखे। समूह बनाने या हटाने के इस चुनाव से संस्करण अपडेट की डिफ़ॉल्ट रोक सुरक्षा सुधारों पर लागू नहीं होने लगती।

साप्ताहिक अंतराल संस्करण अपडेट की जाँच को नियंत्रित करता है। सुरक्षा सुधार की समीक्षा को उस जाँच के दिन से बाँधकर योजना न बनाएँ: सुरक्षा अपडेट की अपनी सुविधा और पात्रता होती है। अलग समूह का लाभ यह है कि सुरक्षा से जुड़े बदलाव नियमित संस्करण बदलावों में नहीं मिलते; फिर भी किसी निश्चित समय तक सुधार पहुँचने की गारंटी इस विन्यास से नहीं मिलती।

अपने रिपॉजिटरी के लिए क्या बदलें

सबसे पहले पैकेज प्रबंधक और निर्भरता फ़ाइलों का स्थान मिलाएँ। कई परियोजनाओं वाले रिपॉजिटरी में हर प्रविष्टि का पथ उसी परियोजना तक सीमित रखें। समूह का नाम बदला जा सकता है, लेकिन उसके मिलान और संस्करण प्रकार के नियम तय करते हैं कि कौन-सा बदलाव साझा पुल रिक्वेस्ट में जाएगा।

यदि टीम संस्करण अपडेट की समीक्षा किसी निश्चित स्थानीय समय पर करती है, तो समय-सारणी में दिन, समय और समय क्षेत्र भी तय किए जा सकते हैं। केवल साप्ताहिक अंतराल लिखने से टीम के लिए तय घड़ी का समय नहीं चुना जाता। यह समीक्षा व्यवस्था का चुनाव है; सुरक्षा अपडेट की रोक के लिए इसे इस्तेमाल करने की आवश्यकता नहीं है।

विन्यास जोड़ने के बाद रिपॉजिटरी के निर्भरता ग्राफ़ में Dependabot की स्थिति से निगरानी में आए पैकेज प्रबंधक और पिछली संस्करण जाँच देखी जा सकती है। अपेक्षित संस्करण पुल रिक्वेस्ट न दिखे तो पहले निर्भरता फ़ाइल का पथ, फिर रोक अवधि और अगली जाँच देखें। सुरक्षा समूह खाली हो तो सक्षम सुरक्षा सुविधाओं और उपलब्ध सुधारों की स्थिति अलग से जाँचें।

यह भी पढ़ें:

• EPFO UAN में Aadhaar, PAN और बैंक KYC कैसे अपडेट करें—लंबित मंजूरी का समाधान भी
• पुराना YouTube Studio ऐप बंद हुआ—मोबाइल काम जारी रखने के लिए अपडेट करें
• EU का AI लेबल नियम लागू: भारतीय क्रिएटर भी दायरे से बाहर नहीं