Rust इंटरव्यू: आप CI के लिए Rust 1.97 चेतावनी (warning) नीति कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और दायरा

Rust 1.97 Cargo में build.warnings प्रस्तुत करता है: warn डिफ़ॉल्ट है, allow समायोज्य लिंट्स (adjustable lints) को छुपाता है, और deny स्थानीय पैकेजों से लिंट चेतावनियों पर बिल्ड को विफल कर देता है। इस व्यवहार को CARGO_BUILD_WARNINGS या --keep-going के साथ भी बदला जा सकता है। यह रिलीज़ डिफ़ॉल्ट रूप से सफल लिंकर stderr को भी दृश्यमान बनाती है और विशेष linker_messages लिंट प्रस्तुत करती है।

यह उन इंजीनियरों को लक्षित करता है जो Rust वर्कस्पेस, कंपाइलर टूलचेन, या रिलीज़ पाइपलाइन बनाए रखते हैं। मान लें कि कई स्थानीय क्रेट्स, तृतीय-पक्ष निर्भरताएं (third-party dependencies), Linux और Windows बिल्ड, और एक क्रॉस-कंपाइल किया गया लक्ष्य (cross-compiled target) है। लक्ष्य हर पीली लाइन को लाल करना नहीं है; प्रत्येक सिग्नल के लिए एक ओनर, एक विफलता गेट (failure gate), और समाधान का मार्ग होना आवश्यक है।

साक्षात्कारकर्ता क्या मूल्यांकन करता है

• क्या आप स्थानीय-कोड लिंट्स, निर्भरता आउटपुट, लिंकर डायग्नोस्टिक्स, और कंपाइलेशन त्रुटियों को अलग कर सकते हैं?
• क्या आप RUSTFLAGS=-Dwarnings को एकमात्र समाधान मानने के बजाय warn, allow, और deny की सीमाओं की व्याख्या कर सकते हैं?
• क्या आप त्वरित स्थानीय फीडबैक, CI प्रवर्तन (enforcement), और विभिन्न लक्ष्यों में पुनरुत्पादकता (reproducibility) के बीच संतुलन बना सकते हैं?
• क्या आप अपवादों (exceptions) को ऑडिट करने योग्य रख सकते हैं और कैश, बिल्ड स्क्रिप्ट्स, और टूलचेन अपग्रेड पर पड़ने वाले प्रभावों की व्याख्या कर सकते हैं?

एक कमजोर उत्तर कहता है "CI में -D warnings का उपयोग करें।" एक मजबूत उत्तर पहले सिग्नलों को वर्गीकृत करता है, Cargo-स्तरीय नीति चुनता है, और बेसलाइन, ओनर्स, और सत्यापन कमांड्स के साथ फॉल्स पॉजिटिव्स को नियंत्रित करता है।

पहले स्पष्ट करने योग्य प्रश्न

1. क्या गेट में केवल वर्कस्पेस क्रेट्स शामिल होने चाहिए, या निर्भरताएं और लिंकर आउटपुट भी? Cargo का build.warnings मुख्य रूप से स्थानीय पैकेजों पर लागू होता है; निर्भरता चेतावनियों के लिए अलग से निगरानी की आवश्यकता होती है।
2. क्या CI एकाधिक लक्ष्यों का निर्माण करता है? क्रॉस-कंपाइलेशन के लिए लिंकर, sysroot, SDK, और लक्ष्य-विशिष्ट डायग्नोस्टिक्स के लिए अलग-अलग रिकॉर्ड की आवश्यकता होती है।
3. क्या एक ही रन में प्रत्येक समस्या को एकत्र करना आवश्यक है? यदि हाँ, तो --keep-going संबंधित चेतावनियों और त्रुटियों को इकट्ठा करने में मदद करता है, लेकिन यह किसी विफल बिल्ड को सफल नहीं बनाता है।
4. क्या अस्थायी अपवादों की अनुमति है? लिंट या संदेश, लक्ष्य, कारण, ओनर, और समीक्षा तिथि रिकॉर्ड करें, अन्यथा allow स्थायी रूप से खामोशी बन जाता है।

एक 30-सेकंड का उत्तर

“मैं आउटपुट को स्थानीय समायोज्य लिंट्स, तृतीय-पक्ष निर्भरता चेतावनियों, लिंकर डायग्नोस्टिक्स, और कंपाइलेशन त्रुटियों में वर्गीकृत करूँगा। तेज़ फीडबैक के लिए स्थानीय विकास warn पर रहता है; CI वर्कस्पेस क्रेट्स के लिए deny और पूरा परिणाम एकत्र करने के लिए --keep-going का उपयोग करता है। अपस्ट्रीम में चेतावनी होने के कारण प्रत्येक बदलाव को ब्लॉक करने के बजाय निर्भरताएं दृश्यमान रहती हैं और अपग्रेड के लिए ट्रैक की जाती हैं। लिंकर आउटपुट को प्रति लक्ष्य एक बेसलाइन मिलती है, और केवल सत्यापित हानिरहित संदेशों की स्पष्ट रूप से अनुमति दी जाती है। प्रत्येक अपवाद का एक ओनर और समाप्ति तिथि होती है। मैं मल्टी-टार्गेट बिल्ड, कैश-हिट माप, और टूलचेन व निर्भरता अपग्रेड ड्रिल्स के साथ नीति को मान्य करूँगा।”

चरण-दर-चरण समाधान

1. सिग्नल की सीमाएं परिभाषित करें

एग्जिट कोड, stderr, और लिंट स्तरों को अलग करें। कंपाइलेशन त्रुटियां हमेशा ब्लॉक करती हैं। build.warnings स्थानीय पैकेजों में समायोज्य लिंट्स को नियंत्रित करता है। निर्भरता आउटपुट विस्तृत लॉग में रहता है ताकि अपस्ट्रीम रखरखाव चुपचाप इस रिपॉजिटरी को न सौंपा जाए। लिंकर डायग्नोस्टिक्स टूलचेन और लक्ष्य द्वारा रिकॉर्ड किए जाते हैं।

2. वातावरण को स्तरित (layer) करें

स्थानीय विकास को warn पर रखें: डेवलपर्स पूरे पुराने बैकलॉग से रुके बिना समस्याओं को देख सकते हैं। CI में रिपॉजिटरी के अपने पैकेजों के लिए deny का उपयोग करें ताकि नया कोड समायोज्य लिंट्स न जोड़ सके। रिलीज़ पाइपलाइन टूलचेन, लॉकफ़ाइल, और लक्ष्य मैट्रिक्स को भी पिन करती है ताकि "मेरी मशीन पर काम करता है" कोई रिलीज़ मानदंड न बने।

[build]
warnings = "warn"

[lints.rust]
linker_messages = "allow"

linker_messages = "allow" लाइन केवल तभी मान्य होती है जब उस प्लेटफ़ॉर्म के संदेश को हानिरहित दिखाया गया हो; यह सभी लिंकर stderr के लिए वाइल्डकार्ड नहीं है। CI एक पर्यावरण चर के साथ स्थानीय-पैकेज चेतावनी स्तर को बदल सकता है:

CARGO_BUILD_WARNINGS=deny cargo check --workspace --all-targets --keep-going

3. निर्भरताओं और कैश को संभालें

निर्भरता चेतावनियों को क्रेट, संस्करण, लक्ष्य, और पहली बार देखे गए बिल्ड के साथ एक अपग्रेड बोर्ड या अनुमत सूची (allowlist) पर रखें। अपस्ट्रीम जोखिम को विश्व स्तर पर न छुपाएं। Rust 1.97 के रिलीज़ नोट्स में कहा गया है कि चेतावनी व्यवहार बदलने से अंतर्निहित बिल्ड कैश अमान्य नहीं होता है। फिर भी हिट दर की निगरानी करें क्योंकि लक्ष्य, टूलचेन, या rustflags बदलने से अलग-अलग कैश कुंजियाँ (cache keys) बन सकती हैं।

4. क्रॉस-कंपाइलेशन को स्पष्ट करने योग्य बनाएं

प्रत्येक लक्ष्य के लिए, कंपाइलर संस्करण, लिंकर पथ, sysroot, SDK, बिल्ड-स्क्रिप्ट आउटपुट, और चेतावनी बेसलाइन बनाए रखें। यदि किसी प्लेटफ़ॉर्म को अस्थायी लिंकर अपवाद की आवश्यकता है, तो इसे उस लक्ष्य तक सीमित रखें और लिंकर बदलने पर इसकी पुन: जांच करें। "Linux शांत है" इस बात का प्रमाण नहीं है कि Windows सुरक्षित है।

5. अपवाद और निकास पथ डिज़ाइन करें

एक अपवाद चार फ़ील्ड रिकॉर्ड करता है: सटीक लिंट या संदेश, लक्ष्य, ओनर, और समाप्ति तिथि। प्रत्येक टूलचेन अपग्रेड और रिलीज़ उम्मीदवार के लिए चेतावनी रिपोर्ट पुन: उत्पन्न करें। यदि अपवादों की संख्या या पुनरावृत्ति बढ़ती है, तो बिल्ड मैट्रिक्स के विस्तार को रोकें और पहले कारण को दूर करें।

6. सत्यापित करें कि नीति काम करती है

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

उच्च गुणवत्ता वाला नमूना उत्तर

“मैं एक वैश्विक -Dwarnings के साथ शुरुआत नहीं करूँगा। पहले मैं यह परिभाषित करूँगा कि क्या गेट वर्कस्पेस रिग्रेशन की सुरक्षा करता है या प्रत्येक टूल संदेश की। Rust 1.97 का build.warnings स्थानीय क्रेट्स के लिए एक अच्छी सीमा है: विकास को warn पर रखें, फिर एक रन में अधिक परिणाम एकत्र करने के लिए CI में cargo check --workspace --all-targets --keep-going के साथ CARGO_BUILD_WARNINGS=deny का उपयोग करें। निर्भरता चेतावनियां एक अपग्रेड कतार में जाती हैं; उन्हें दृश्यमान और संस्करणित रहना चाहिए, लेकिन अपस्ट्रीम चेतावनी को स्वचालित रूप से एप्लिकेशन कोड को ब्लॉक नहीं करना चाहिए।

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

सामान्य गलतियाँ

• गलती: वैश्विक RUSTFLAGS=-Dwarnings सेट करना। → यह क्यों विफल होता है: यह कंपाइलर, बिल्ड-स्क्रिप्ट, और निर्भरता सीमाओं को मिला देता है, इसलिए एक अपग्रेड असंबंधित आउटपुट को अस्पष्टीकृत विफलता में बदल सकता है। → सुधार: Cargo की स्थानीय-पैकेज चेतावनी नीति का उपयोग करें और निर्भरताओं तथा लिंकर्स को अलग से ट्रैक करें।
• गलती: हर लाल रेखा को हटाने के लिए allow का उपयोग करना। → यह क्यों विफल होता है: समायोज्य लिंट्स, कंपाइलेशन त्रुटियां, और गैर-लिंट लिंकर stderr अलग-अलग सिग्नल हैं। → सुधार: केवल सत्यापित लिंट्स या संदेशों की अनुमति दें और रॉ लॉग बनाए रखें।
• गलती: --keep-going को सफलता मानना। → यह क्यों विफल होता है: यह परिणाम एकत्र करता है; यह त्रुटियों को सफल बिल्ड में नहीं बदलता है। → सुधार: अंतिम एग्जिट कोड की जांच करें और क्रेट तथा लक्ष्य के अनुसार रिपोर्ट वर्गीकृत करें।
• गलती: केवल डिफ़ॉल्ट लक्ष्य को मान्य करना। → यह क्यों विफल होता है: लिंकर्स, SDKs, और बिल्ड स्क्रिप्ट्स प्लेटफ़ॉर्म के अनुसार भिन्न होते हैं। → सुधार: प्रत्येक रिलीज़ लक्ष्य के लिए एक स्वतंत्र बेसलाइन और अपग्रेड ड्रिल बनाएं।

फॉलो-अप और उत्तर

क्या होगा यदि कोई निर्भरता क्रेट रिलीज़ लॉग को चेतावनियों से भर देता है?

इसे शांत करने के बजाय क्रेट, संस्करण और लक्ष्य के अनुसार एकत्रित करें। यदि चेतावनी अपस्ट्रीम में ठीक हो गई है, तो एक प्रतिवर्ती (reversible) अपग्रेड शेड्यूल करें। यदि अपग्रेड के लिए प्रतीक्षा करनी होगी, तो संस्करण सीमा और जोखिम ओनर को रिकॉर्ड करें, और रिपॉजिटरी लिंट्स को निर्भरता अवलोकन से अलग रखें। केवल तभी ब्लॉक करें जब निर्भरता किसी घोषित रिलीज़ सुरक्षा गेट का उल्लंघन करती हो।

RUSTFLAGS=-Dwarnings के साथ सब कुछ क्यों नहीं संभालते?

ग्लोबल rustflags बिल्ड स्क्रिप्ट्स, प्रोसीजरल मैक्रोज़, और लक्ष्य चयन को प्रभावित करते हैं, जिससे सीमा को समझाना कठिन हो जाता है और संभावित रूप से क्रॉस-प्लेटफ़ॉर्म व्यवहार और कैश कुंजियाँ बदल जाती हैं। Cargo का build.warnings संकीर्ण नियम बताता है: CI स्थानीय पैकेजों से समायोज्य लिंट्स को रोकता है, जबकि अन्य आउटपुट अपने स्वयं के ऑडिट पथ का अनुसरण करते हैं।

किसी लक्ष्य की लिंकर चेतावनी हर बिल्ड पर बदलती है। आप क्या करते हैं?

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