Skip to main content
एक पैक GitHub रिलीज़ से जुड़ी तीन फाइलें हैं। failproofai publish इन सभी को सामने आने वाली नीति फाइलों से लिखता है, रिलीज़ बनाता है, और उन्हें अपलोड करता है।

1. नीतियां लिखें

टेम्पलेट से शुरुआत करने के बजाय किसी ऐसी चीज़ से शुरुआत करें जो पहले से काम कर रही हो:
यह पूछता है कि पैक का नाम क्या है, <name>.mjs लिखता है, और रुक जाता है — कोई नेटवर्क नहीं, कोई git नहीं, कुछ भी प्रकाशित नहीं। यह फाइल जो लिखता है वह एक नीति है जो पहले से git push --force को ब्लॉक करता है। यह किसी मौजूदा फाइल को ओवरराइट नहीं करता। नीतियां किसी भी कस्टम नीति के समान API का उपयोग करती हैं। एक पैक के लिए दो अतिरिक्त फील्ड महत्वपूर्ण हैं:
जब आप इसे छोड़ देते हैं तो defaultEnabled डिफ़ॉल्ट रूप से false होता है। एक सादा failproofai policies add केवल वह चीज़ें स्विच करता है जिन्हें आपने चिह्नित किया है — किसी अजनबी की हर नीति को बिना निगरानी के इंस्टॉल करना एक ऐसा निर्णय नहीं है जो इंस्टॉलर को अपने उपयोगकर्ता के लिए करना चाहिए। जितनी चाहें उतनी फाइलें लिखें; एक प्रति श्रेणी अच्छी दिखती है। निर्देशिका में वह सभी फाइलें जो नीतियां पंजीकृत करती हैं, एक पैक को बंडल किया जाता है।
बंडलिंग के लिए bun की आवश्यकता है। इसके बिना, एक आत्मनिर्भर फाइल तक सीमित रहें। किसी भी तरह, प्रकाशित प्रविष्टि इंस्टॉल समय पर स्थानीय फाइलें आयात नहीं कर सकती: केवल प्रविष्टि डाइजेस्ट-पिन की जाती है, इसलिए एक पैक जो भाई-बहनों तक पहुंचता है, ईमानदारी से यह दावा नहीं कर सकता कि डाइजेस्ट वह कवर करता है जो चलता है — और publish इसे अस्वीकार कर देता है।

2. पहले यहां इसे आजमाएं

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

3. इसे प्रकाशित करें

यह पता लगाता है कि कहां प्रकाशित करना है, क्या बंडल करना है और इसे क्या संस्करण देना है, और केवल तब पूछता है जब कुछ नहीं बताता। क्रम में, यदि कुछ गलत है तो रिलीज़ बनाने से पहले रुकता है:
  1. सामग्री द्वारा नीति फाइलें ढूंढता है — वे जो failproofai आयात करती हैं और customPolicies.add कॉल करती हैं — फाइल नाम के अनुसार नहीं, इसलिए यह guards.mjs ढूंढता है और एक असंबंधित policies.mjs को अनदेखा करता है। यह उप-निर्देशिकाओं में नहीं जाता, इसलिए एक परीक्षण फिक्स कभी गलती से नहीं चुना जाता।
  2. git remote get-url origin से रिपो पढ़ता है, आपकी निर्देशिका के बजाय फाइल की निर्देशिका में, और संस्करण तय करता है।
  3. आपके क्रेडेंशियल को ढूंढता है: GITHUB_TOKEN, GH_TOKEN, या gh auth login। इसे रिलीज़-राइट की आवश्यकता है और कुछ नहीं, और कभी नहीं छाया जाता।
  4. भंडार बनाता है यदि यह मौजूद नहीं है। यह निर्माण से पहले होता है, इसलिए अगले चरण में अस्वीकार किया गया एक पैक इसमें कोई रिलीज़ के साथ एक नया भंडार छोड़ सकता है।
  5. तीन संपत्तियां बनाता है, उन्हें लोडर के अपने नियमों से सत्यापित करता है — वही कोड जो तय करता है कि किसी अजनबी की मशीन पर क्या इंस्टॉल हो सकता है — इसलिए एक पैक जो कभी इंस्टॉल नहीं हो सकता वह यहां विफल हो जाता है, जहां आप अभी भी इसे ठीक कर सकते हैं।
  6. रिलीज़ बनाता या पुनः उपयोग करता है और अपलोड करता है, समान नाम की संपत्तियों को बदलता है।
संपत्ति के नाम निर्धारित हैं — वे वह हैं जिन्हें एक उपभोक्ता का CLI अपने URLs से बनाता है, कोई API कॉल के साथ नहीं और कोई खोज नहीं। निर्माण समय पर अस्वीकार किया गया: एक id जो publisher/name नहीं है, / युक्त नीति नाम, alwaysOn घोषित करने वाली नीति, description, category या match का अभाव, एक प्रविष्टि जो कुछ नहीं पंजीकृत करती, और एक प्रविष्टि जो स्थानीय फाइलें आयात करती है। जो कुछ भी यह तय करता है उसे ओवरराइड करें:
--id पैक id सेट करता है जब यह रिपो से अलग होना चाहिए, --tag रिलीज़ का टैग सेट करता है, --notes जनरेट की गई रिलीज़ नोट्स को बदलता है — यह वह है जहां policies show --releases प्रत्येक रिलीज़ के गणना और कमिट को पढ़ता है — --out चुनता है कि संपत्तियां कहां लिखी जाएं (डिफ़ॉल्ट dist-pack), और --dry-run उन्हें प्रकाशित किए बिना बनाता है और कोई क्रेडेंशियल की आवश्यकता नहीं है। कोई भी अब इसे failproofai policies add acme/support-agent के साथ इंस्टॉल कर सकता है। संस्करण को पिन करने और केवल एक के हिस्से को लेने के लिए नीति पैक देखें।

इसे नीति हब पर सूचीबद्ध करें

GitHub पर भंडार में failproofai-policies विषय जोड़ें। कोई सबमिशन फॉर्म नहीं है और कोई अनुमोदन कतार नहीं है: नीति हब क्रॉलर अपने अगले पास पर भंडार को उठाता है। विषय केवल इसे विचार के लिए रखता है — यह क्या सूचीबद्ध करता है वह एक रिलीज़ है जिसका मैनिफेस्ट अपने SHA256SUMS के विरुद्ध सत्यापित होता है और CLI उपयोग करने वाले समान नियमों के तहत पार्स करता है, जो ठीक वही है जो failproofai publish उत्पादित करता है।

संस्करण कैसे तय किया जाता है

संस्करण कमिट है जिससे आप प्रकाशित कर रहे हैं — इसका संक्षिप्त sha, बारह वर्ण: a1b2c3d4e5f6। चुनने के लिए कुछ नहीं है और बढ़ाने के लिए कुछ नहीं है, और संस्करण ठीक उसी स्थान का नाम देता है जहां बाइट्स आए हैं, इसलिए समान स्रोत को दो बार प्रकाशित करने से समान संस्करण मिलता है। यह आपके सामने के पेड़ से पढ़ा जाता है, कभी भी भंडार की रिलीज़ से नहीं, इसलिए एक ताज़ा क्लोन और एक एयर-गैप्ड मशीन GitHub से पूछे बिना समान उत्तर की गणना करते हैं कि पहले क्या हुआ। क्योंकि संस्करण एक कमिट का नाम देता है, यह कमिट मौजूद होना चाहिए। एक टर्मिनल पर, publish यह आपके लिए बनाता है: यह एक भंडार को आरंभ करता है जब कोई नहीं है, और निर्माण से पहले परिवर्तित नीति फाइलों को कमिट करता है। यह अस्वीकार करता है — --version को तरीका के रूप में नाम देता है — जब यह टर्मिनल के बिना चलता है (एक CI धावक पर किया गया कमिट और कहीं मौजूद नहीं होगा), जब नीतियों के अलावा अन्य फाइलें अनकमिटेड हों, या एक चेकआउट में जिसमें अभी तक कोई कमिट नहीं है। HEAD पर एक टैग sha को जीतता है — किसी ने जिसने v1.2.0 को टैग किया है, ने कहा है कि यह रिलीज़ क्या है। एक sha अपने आप में कोई क्रम नहीं रखता है, इसलिए यह देखने के लिए failproofai policies show <owner>/<repo> --releases का उपयोग करें कि कौन सी रिलीज़ पहले आई — शीर्ष पर सबसे नई।

एक नया संस्करण शिप करना

परिवर्तन को कमिट करें और फिर से failproofai publish चलाएं — नया कमिट नया संस्करण है। उपभोक्ता समान failproofai policies add चलाते हैं। टर्मिनल के बिना, या चयन फ्लैग के साथ, वे उप-समुच्चय को रखते हैं जिसे उन्होंने चुना था और एक नीति जिसे उन्होंने बंद किया वह बंद रहता है; कोई फ्लैग के साथ एक टर्मिनल पर, पिकर आपके डिफ़ॉल्ट के साथ पूर्व-चेकित खुलता है और उनका उत्तर उनके चयन को बदलता है। नीति के नाम को बदलना एक महत्वपूर्ण परिवर्तन है: एक मशीन जिसने इसे बंद किया था, एक ऐसा नाम बंद कर रहा है जो अब मौजूद नहीं है, और नया नाम जो भी defaultEnabled कहता है उसमें आता है।

आपके उपयोगकर्ता क्या विश्वास कर रहे हैं

SHA256SUMS उसी रिलीज़ में रहता है जहां कलाकृति है, इसलिए यह साबित करता है कि बाइट्स वह हैं जो आपने प्रकाशित किए — आप कौन हैं नहीं। जो कोई भी भंडार में लिख सकता है वह दोनों फाइलें लिख सकता है। आपके उपयोगकर्ताओं की सुरक्षा यह है कि जब वे इंस्टॉल करते हैं तो डाइजेस्ट पिन किया जाता है, इसलिए जो आपने शिप किया वह उसके बाद उनके अंतर्गत नहीं बदल सकता। एक ऐसे भंडार से प्रकाशित करें जिसकी लिखने की पहुंच आप नियंत्रित करते हैं, और एक पैक रिलीज़ को पैकेज प्रकाशित करने की तरह मानें। भंडार भी सार्वजनिक होना चाहिए। इंस्टॉल गुमनाम HTTPS है कोई क्रेडेंशियल के साथ जो प्रस्ताव देने के लिए है, इसलिए एक मौजूदा निजी रिपो कुछ भी बनाने या अपलोड करने से पहले अस्वीकार कर दिया जाता है, और एक जो publish बनाता है वह समान कारण के लिए सार्वजनिक है। --allow-private किसी के लिए उस को ओवरराइड करता है जो तीनों संपत्तियों को दूसरे तरीके से सौंप रहा है, और स्पष्ट रूप से कहता है कि कोई भी policies add उन तक नहीं पहुंच सकता। केवल रिलीज़ महत्वपूर्ण है: इंस्टॉल releases/download/<tag>/<asset> पढ़ते हैं और कभी आपके git पेड़ को स्पर्श नहीं करते।

लागू करने से पहले देखें

एक मैनिफेस्ट "effect": "observe" घोषित कर सकता है — failproofai publish --effect observe वह है जो इसे सेट करता है। वह नीतियां चलती हैं और उनके निर्णय दर्ज और त्याग दिए जाते हैं — कुछ नहीं ब्लॉक किया जाता है। यह किसी के काम को बाधित करने से पहले वास्तविक ट्रैफिक के खिलाफ एक नई नियम को मापने का तरीका है।