LayerFS के साथ लोकल डेवलपमेंट

Native Shell की रिपॉज़िटरी में एक स्थानीय LayerFS वर्कफ़्लो शामिल है, जिससे पुन: उपयोग योग्य बिल्ड वर्कस्पेस का परीक्षण किया जा सकता है। यह कमिट किए गए सोर्स ट्री को इम्पोर्ट करता है, Linux Sandbox के अंदर Cargo चलाता है, परिणामस्वरूप बनी फ़ाइलें सहेजता है और उस सहेजी गई स्थिति के फ़ोर्क से टेस्ट दोबारा चलाता है। सोर्स एडिटिंग और Git कमिट आपके मौजूदा NSH चेकआउट में ही होते हैं।

#स्नैपशॉट क्या सहेजता है

LayerFS एक फ़ाइलसिस्टम ट्री सहेजता है: सोर्स फ़ाइलें, Git मेटाडेटा, अनदेखी (ignored) फ़ाइलें और वर्कस्पेस के अंदर बने बिल्ड आउटपुट। फ़ोर्क एक सहेजे गए ट्री से शुरू होता है और अपने बदलाव अलग से दर्ज करता है। इससे कई टास्क एक ही बिल्ट स्थिति से शुरू हो सकते हैं, जबकि उनके बदलाव एक-दूसरे से अलग रहते हैं।

NSH के स्थानीय ट्रायल में, पहली ब्रांच nsh-package के टेस्ट चलाती है और target/ तथा एक ignored प्रोब फ़ाइल सहेजती है। दूसरी ब्रांच उस कमिट से शुरू होती है, उन फ़ाइलों की जाँच करती है और टेस्ट ऑफ़लाइन दोबारा चलाती है। तीसरी ब्रांच मूल सोर्स स्थिति से शुरू होती है और आइसोलेशन की पुष्टि करती है।

Phase	क्या होता है
Init	चेकआउट के HEAD कमिट का एक्सपोर्ट और एक नई .git डायरेक्टरी इम्पोर्ट करें
Build	एक वर्कस्पेस फ़ोर्क करें और cargo +1.98.1 test --locked -p nsh-package चलाएँ
Commit	जनरेट हुई target/ और प्रोब फ़ाइल को LayerFS हिस्ट्री में सहेजें
Reuse	सहेजी गई ब्रांच को फ़ोर्क करें, उसे माउंट करें और --offline के साथ टेस्ट दोबारा चलाएँ
Verify	कमिट हिस्ट्री पढ़ें और जाँचें कि मूल सोर्स ब्रांच साफ़ बनी हुई है

हर इनवोकेशन एक नया Store बनाता है और यह पूरा क्रम चलाता है। स्नैपशॉट का पुन: उपयोग उसी इनवोकेशन की ब्रांचों के बीच होता है। ट्रायल में मापने योग्य लाभ यह है कि एक और उपयोग योग्य, परीक्षित वर्कस्पेस तक पहुँचने में कितनी लागत लगती है, जिसमें माउंट, कमिट और अनमाउंट का समय भी शामिल है।

#डेवलपमेंट एनवायरनमेंट तैयार करें

NSH repository के एक चेकआउट के साथ निम्नलिखित का उपयोग करें:

• एक स्थानीय Linux Docker इंजन, जिसके Store वॉल्यूम के लिए ext4, XFS या Btrfs हो, और जो Linux पर या OrbStack जैसे macOS एनवायरनमेंट के माध्यम से चल रहा हो।
• Docker Engine जो API 1.54 या उससे नया संस्करण परोसता हो; सत्यापित स्थानीय सेटअप Engine 29.7.2 का उपयोग करता है।
• /dev/fuse, जिसमें Docker को उस डिवाइस और CAP_SYS_ADMIN को Sandbox के लिए उपलब्ध कराने की अनुमति हो।
• Git और Python 3.12 या नया संस्करण; Linux पर rustup और एक C/C++ कंपाइलर।
• पिन किए गए LayerFS सोर्स, Cargo डिपेंडेंसी और रनटाइम इमेज को प्राप्त करने के लिए नेटवर्क एक्सेस।

ट्रायल LayerFS 1.0.0 बिल्ड करता है, जो सोर्स कमिट 2aaf2552ce21154928b9f9c83582e41a637f5910 पर पिन है। इसकी रनटाइम इमेज Linux प्रोसेस के लिए Rust 1.98.1, Node और clang उपलब्ध कराती है। upstream SDK guide Store और Sandbox के लाइफ़साइकल का वर्णन करती है।

ये कमांड NSH चेकआउट के रूट से चलाएँ:

./scripts/layerfs prepare
./scripts/layerfs smoke
./scripts/layerfs status

एक्ज़ीक्यूटेबल Python 3.12 या नया संस्करण चुनता है, जिसमें macOS पर Homebrew की इंस्टॉलेशन भी शामिल है, और सक्रिय Docker कॉन्टेक्स्ट से सॉकेट खोज लेता है। किसी स्थानीय सॉकेट को स्पष्ट रूप से चुनने के लिए --docker-socket PATH का उपयोग करें।

prepare Docker API की जाँच करता है, Rust 1.85.1 इंस्टॉल करता है और पिन किया गया डेमन, Node addon और रनटाइम इमेज बिल्ड करता है। macOS पर यह इन्हें एक अस्थायी Linux बिल्ड कंटेनर में तैयार करता है। यह सामान्य Cargo रजिस्ट्री और target/ का पुन: उपयोग करता है, जिसमें मौजूदा CARGO_TARGET_DIR सेटिंग भी शामिल है। रनटाइम इमेज का सटीक ID और डेमन का पाथ .nsh/layerfs/deployment.json में दर्ज किए जाते हैं। status सहेजे गए बिल्ड आउटपुट और इमेज की जाँच करता है और नवीनतम सत्यापन परिणाम दिखाता है।

smoke चेकआउट के कमिट किए गए HEAD से .nsh/layerfs/nsh-<id>/input बनाता है, फिर उस इनपुट को एक नए Store में इम्पोर्ट करता है। सोर्स एडिट शामिल करने के लिए, इसे चलाने से पहले उन्हें अपनी टॉपिक ब्रांच में कमिट करें। जनरेट किया गया इनपुट एक नई Git रिपॉज़िटरी से शुरू होता है और अपने बिल्ड आउटपुट Sandbox के अंदर प्राप्त करता है।

कंट्रोल प्रोसेस Store को एक नामित स्थानीय Docker वॉल्यूम में खोलता है। Sandbox डेमन उसी Store को खोलता है और ब्रांच का फ़ाइलसिस्टम व्यू माउंट करता है; Cargo उसी माउंट किए गए वर्कस्पेस में चलता है। सोर्स बदलावों को एडिट और कमिट करने की जगह आपका सामान्य चेकआउट ही रहता है।

#परिणाम पढ़ें

कमांड रसीद (receipt) डायरेक्टरी और Store वॉल्यूम का नाम प्रिंट करता है। "ok": true और हर phase के बीते समय की जाँच के लिए जनरेट हुई result.json खोलें। उसी डायरेक्टरी में settings.json होती है, जो सोर्स कमिट और इमेज की पहचान बताती है, और trace.jsonl, जो SDK कॉल दर्ज करती है।

स्थानीय सत्यापन में Build और Reuse दोनों phase में 22 पैकेज टेस्ट चले। शुरुआती build/test phase में डिपेंडेंसी डाउनलोड शामिल थे; ऑफ़लाइन phase ने सहेजी गई target/ और उसी Sandbox की Cargo रजिस्ट्री का उपयोग किया। इसका मूल्य आँकते समय पूरे चक्र की तुलना अपने वर्कलोड पर सामान्य Cargo बिल्ड से करें।

बिल्ट स्थिति का पुन: उपयोग करते समय एक जैसे ऑपरेटिंग सिस्टम, आर्किटेक्चर, टूलचेन और डिपेंडेंसी का उपयोग करें। इस गाइड का वर्कलोड Linux nsh-package टेस्ट सूट है; प्लेटफ़ॉर्म UI जाँचें अपने-अपने प्लेटफ़ॉर्म एनवायरनमेंट में चलती हैं (Testing)।

#उपयोगी काम सहेजें और Store को प्रबंधित करें

सोर्स बदलाव Git में रखें और उन्हें pull request के माध्यम से सबमिट करें। ट्रायल दोबारा बनाए जा सकने वाले वर्कस्पेस हिस्ट्री के लिए LayerFS की Disposable Store प्रोफ़ाइल का उपयोग करता है। माप दर्ज करते समय उपयोगी रसीदें अलग से सुरक्षित रखें।

जनरेट किया गया इनपुट अपने शुरुआती कमिट के दौरान स्वचालित Git मेंटेनेंस को अक्षम कर देता है, ताकि LayerFS के इम्पोर्ट करते समय ऑब्जेक्ट डेटाबेस स्थिर रहे। ट्रायल के भीतर Git status जाँचें --no-optional-locks का उपयोग करती हैं, ताकि status पढ़ने से मूल इंडेक्स सुरक्षित रहे। कस्टम स्क्रिप्ट के लिए, किसी ट्री को इम्पोर्ट या कमिट करने से पहले बैकग्राउंड राइटर पूरे कर लें।

सफलतापूर्वक अनमाउंट किए गए Sandbox LayerFS के idle टाइमआउट के बाद रुक जाते हैं। हर ट्रायल अपना Store वॉल्यूम बनाए रखता है; उस विशेष वॉल्यूम और उसके कंटेनरों को रसीद में दिए गए पहचानकर्ताओं के आधार पर प्रबंधित करें। विफल ऑपरेशन निदान के लिए अपनी दर्ज की गई स्थिति बनाए रखता है। maintainer reference में स्क्रिप्ट, रसीदें और संसाधन क्लीनअप का विवरण है।