GitHub Actions रनर कब रुकेगा? नई API अंतिम तारीख बताएगी
GitHub ने 3 सितंबर 2026 को स्वयं-होस्टेड Actions रनर के संस्करण-विशिष्ट समर्थन कार्यक्रम के लिए नई REST API उपलब्ध कराई। 3 सितंबर की आधिकारिक घोषणा के अनुसार, उत्तर में runner_version, registration_deprecates_at और runtime_deprecates_at मिलते हैं; अनुरोध रिपॉजिटरी, संगठन या उद्यम स्तर पर किया जा सकता है।
इस सुविधा का सीधा अर्थ यह है कि सभी रनर के लिए कोई एक साझा अंतिम तारीख नहीं खोजनी होगी। अनुरोध में दिया गया संस्करण तय करता है कि कौन-सा कार्यक्रम लौटेगा। TechPillow का 5 सितंबर का विवरण भी पंजीकरण और कार्य निष्पादन की अलग समय-सीमाएँ मिलने तथा तीनों प्रशासनिक स्तरों पर जाँच की उपलब्धता दर्ज करता है।
पंजीकरण और कार्य निष्पादन की तारीखें अलग हैं
नई व्यवस्था में पहली तारीख बताती है कि पुराने संस्करण वाले रनर का पंजीकरण कब असमर्थित होगा। इसका असर नई मशीन जोड़ने, बदली हुई मशीन को दोबारा जोड़ने और माँग के अनुसार अस्थायी रनर तैयार करने वाली प्रणालियों पर पड़ सकता है। कोई पहले से पंजीकृत मशीन उस समय कार्य कर रही हो, तब भी उसी संस्करण से नई क्षमता जोड़ने का रास्ता बंद हो सकता है।
दूसरी तारीख उस संस्करण पर कार्य निष्पादन समर्थन की सीमा बताती है। यह सक्रिय कार्यप्रवाह के लिए अधिक प्रत्यक्ष जोखिम है: सीमा आने पर उस संस्करण पर कार्य भेजे जाने या चलाए जाने पर भरोसा नहीं किया जा सकता। इसलिए निगरानी प्रणाली को दोनों तारीखों को एक ही सामान्य “समर्थन समाप्त” स्थिति में नहीं मिलाना चाहिए।
पंजीकरण की निकट सीमा क्षमता बदलने या मशीन फिर जोड़ने का खतरा दिखाती है, जबकि कार्य निष्पादन की निकट सीमा मौजूदा काम रुकने की आशंका बताती है। उत्तर में कोई तारीख न मिले तो उसे सुरक्षित स्थिति मानने के बजाय “जानकारी उपलब्ध नहीं” के रूप में दर्ज करना अधिक उचित है।
तीन प्रशासनिक स्तरों पर अनुरोध ऐसे बनेंगे
रिपॉजिटरी के लिए अनुरोध-पथ GET /repos/{owner}/{repo}/actions/runners/deprecations/{version} है। संगठन के लिए GET /orgs/{org}/actions/runners/deprecations/{version} और उद्यम के लिए GET /enterprises/{enterprise}/actions/runners/deprecations/{version} उपयोग होता है। हर अनुरोध केवल पथ में दिए गए संस्करण का कार्यक्रम लौटाता है, पूरे रनर समूह की संयुक्त रिपोर्ट नहीं।
GitHub का आधिकारिक REST संदर्भ बताता है कि रिपॉजिटरी अनुरोध के लिए प्रशासकीय पहुँच और सूक्ष्म अनुमति वाले टोकन में प्रशासन की पढ़ने की अनुमति चाहिए। संगठन स्तर पर प्रशासकीय पहुँच के साथ स्वयं-होस्टेड रनर पढ़ने की अनुमति आवश्यक है, जबकि उद्यम स्तर की जाँच के लिए उद्यम के रनर प्रबंधित करने वाला अधिकार चाहिए।
अनुमति का स्तर उसी दायरे में रखा जा सकता है जहाँ चेतावनी बनाई जा रही है। किसी एक रिपॉजिटरी की रखरखाव जाँच को पूरे संगठन या उद्यम का व्यापक अधिकार देना आवश्यक नहीं है। दूसरी ओर, केंद्रीय बेड़ा प्रबंधन को हर रिपॉजिटरी पर अलग अनुरोध भेजने के बजाय उपलब्ध उच्च प्रशासनिक स्तर का उपयोग करना पड़ सकता है।
संदर्भ में वर्णित उत्तर पंजीकरण और कार्य निष्पादन, दोनों की समाप्ति तारीखों के लिए है, लेकिन प्रकाशित नमूना उत्तर में सभी घोषित कुंजियाँ दिखाई नहीं देतीं। इस कारण उत्तर पढ़ने वाला स्वचालन प्रत्येक कुंजी की उपस्थिति अलग जाँचे और किसी एक तारीख के न मिलने पर पूरा उत्तर अस्वीकार न करे।
रनर सूची से उन्नयन चेतावनी बनाने की जाँच-सूची
समापन अंतरापृष्ठ स्वयं रनर समूह की खोज नहीं करता; वह केवल पूछे गए संस्करण का कार्यक्रम देता है। चेतावनी बनाने के लिए पहले संबंधित प्रशासनिक स्तर की रनर सूची चाहिए, फिर उसमें मिले अलग-अलग संस्करणों के कार्यक्रम पूछने होंगे। समान संस्करण वाली कई मशीनों के लिए एक ही जाँच परिणाम दोबारा उपयोग किया जा सकता है।
- रनर सूची से प्रत्येक मशीन का नाम, स्थिति, संस्करण और उपयोग किए गए लेबल दर्ज करें।
- दोहराए गए संस्करण हटाकर हर विशिष्ट संस्करण के लिए उपयुक्त प्रशासनिक स्तर पर कार्यक्रम माँगें।
- लौटी हुई दोनों तारीखें उसी संस्करण वाली मशीनों से जोड़ें और उन्हें अलग क्षेत्रों में सुरक्षित रखें।
- पंजीकरण की निकट सीमा को क्षमता बदलने के जोखिम तथा कार्य निष्पादन की निकट सीमा को सक्रिय काम रुकने के जोखिम के रूप में चिह्नित करें।
- अनुमति की विफलता, अमान्य संस्करण, अनुपस्थित तारीख और असफल अनुरोध के लिए अलग जाँच स्थितियाँ रखें।
एक सशर्त उदाहरण में, किसी संगठन के स्थायी और अल्पकालिक रनर एक ही पुराने संस्करण पर हों तो उस संस्करण का कार्यक्रम केवल एक बार माँगा जा सकता है। परिणाम सभी संबंधित मशीनों से जोड़ा जाएगा, लेकिन प्राथमिकता उनके उपयोग के अनुसार बदल सकती है: अस्थायी क्षमता के लिए पंजीकरण सीमा पहले महत्वपूर्ण होगी, जबकि लगातार कार्य चलाने वाली मशीनों के लिए निष्पादन सीमा अधिक गंभीर होगी।
GitHub ने चेतावनी जारी करने के लिए कोई सार्वभौमिक अग्रिम अवधि निर्धारित नहीं की है। संगठन को अपनी अवधि इस आधार पर तय करनी होगी कि नया संस्करण जाँचने, रनर छवि बदलने, चरणबद्ध तैनाती करने और विफल मशीन वापस लेने में कितना स्थानीय समय लगता है। यह अवधि API से मिलने वाला तथ्य नहीं, बल्कि रखरखाव नीति का निर्णय होगी।
केवल निकटतम तारीख से प्राथमिकता तय नहीं होगी
दो संस्करणों की अंतिम तारीख समान होने पर उनका परिचालन प्रभाव अलग हो सकता है। प्राथमिकता बनाते समय उस संस्करण पर सक्रिय मशीनों की संख्या, आवश्यक कार्यप्रवाहों की निर्भरता, लेबल की उपलब्धता और खराब मशीन को फिर पंजीकृत करने की सामान्य प्रक्रिया देखनी होगी। नई API इनमें से कोई स्थानीय जानकारी नहीं देती।
उपयोगी चेतावनी में प्रशासनिक स्तर, संस्करण, दोनों उपलब्ध समय-सीमाएँ, प्रभावित मशीनें और पिछली सफल जाँच का समय शामिल किया जा सकता है। इससे संचालक समझ सकेगा कि समस्या नई क्षमता जोड़ने की है, मौजूदा काम चलाते रहने की है या केवल अधूरी प्रतिक्रिया की जाँच करनी है।
तारीखों को स्थायी विन्यास मानना भी जोखिमपूर्ण होगा। संस्करण का कार्यक्रम समय के साथ बदला जा सकता है, इसलिए रखरखाव प्रणाली को उसे समय-समय पर फिर पढ़ना चाहिए और बदले हुए मान पर नई चेतावनी बनानी चाहिए। पुरानी संग्रहीत प्रतिक्रिया केवल पिछली स्थिति का अभिलेख है।
अभी क्या निश्चित है
नई सुविधा संस्करण के आधार पर मशीन-पठनीय समर्थन कार्यक्रम देती है और पंजीकरण तथा कार्य निष्पादन की सीमाओं को अलग रखती है। वास्तविक अंतिम समय जानने के लिए संबंधित रनर संस्करण और सही प्रशासनिक दायरे के साथ अनुरोध करना आवश्यक है; किसी सामान्य कैलेंडर तारीख से पूरे स्वयं-होस्टेड बेड़े का निष्कर्ष नहीं निकाला जा सकता।
अब खुला प्रश्न प्रत्येक संगठन की अपनी उन्नयन अवधि और जोखिम प्राथमिकता है। API तारीख देती है, लेकिन कितनी जल्दी बदलाव शुरू करना है और किन कार्यप्रवाहों को पहले स्थानांतरित करना है, यह रनर सूची तथा स्थानीय निर्भरताओं को जोड़ने के बाद ही तय होगा।
यह भी पढ़ें:
हमारे न्यूज़लेटर की सदस्यता लें
Web3, AI और क्रिप्टो की नवीनतम खबरें सीधे अपने इनबॉक्स में पाएँ।