failproofai publish يكتب جميع الملفات الثلاث من ملفات السياسات أمامه، ينشئ الإصدار، ويرفعها.
1. اكتب السياسات
ابدأ من شيء يعمل بالفعل بدلاً من قالب فارغ:<name>.mjs، ثم يتوقف — لا شبكة، لا git، لا شيء منشور. الملف الذي يكتبه هو سياسة واحدة تحجب بالفعل git push --force. يرفض استبدال الملف الموجود.
السياسات تستخدم نفس واجهة برمجية التطبيقات مثل أي سياسة مخصصة. حقلان إضافيان مهمان للمجموعة:
defaultEnabled يُعيّن افتراضياً إلى false عندما تحذفه. أمر failproofai policies add البسيط يفعّل فقط ما وسّمته — تثبيت كل السياسات من غريب بدون مراقبة ليس قراراً يجب على المثبّت أن يتخذه نيابة عن المستخدم.
اكتب أي عدد من الملفات تريده؛ ملف واحد لكل فئة يبدو جيداً. كل ملف في المجلد الذي يسجل السياسات سيتم دمجه في الحزمة الوحيدة التي تحتاجها.
2. جرّبها هنا أولاً
قبل أن يراها أي شخص آخر، فرّض الملف على هذا الجهاز:3. انشرها
- يجد ملفات السياسات هنا بـ المحتوى — تلك التي تستورد
failproofaiوتستدعيcustomPolicies.add— بدلاً من اسم الملف، لذا يجدguards.mjsويتجاهلpolicies.mjsغير الصلة. لا ينحدر إلى المجلدات الفرعية، لذا لا يتم التقاط fixture اختبار بالصدفة. - يقرأ المستودع من
git remote get-url origin، في مجلد الملف بدلاً من مجلدك، ويحدد الإصدار. - يجد بيانات اعتمادك:
GITHUB_TOKEN،GH_TOKEN، أوgh auth login. يحتاج إلى كتابة الإصدار وليس أكثر، ولا يتم طباعته أبداً. - ينشئ المستودع إذا لم يكن موجوداً. هذا يحدث قبل البناء، لذا المجموعة المرفوضة في الخطوة التالية يمكن أن تترك مستودع جديد بدون إصدار فيه.
- يبني الأصول الثلاثة، يتحقق منها مع قواعد محمّل السياسات الخاصة — نفس الكود الذي يقرر ما قد يثبّت على جهاز الغريب — لذا المجموعة التي لا تستطيع التثبيت أبداً تفشل هنا، حيث تستطيع إصلاحها.
- ينشئ أو يعيد استخدام الإصدار ويرفع، يستبدل الأصول بنفس الاسم.
أسماء الأصول ثابتة — إنها ما يبني واجهة سطر أوامر المستهلك عناوين URL منها، بدون استدعاء واجهة برمجية وبدون اكتشاف.
مرفوضة في وقت البناء: معرّف ليس
publisher/name، اسم سياسة يحتوي على /، سياسة تعلن alwaysOn، description، category أو match مفقودة، ملف مدخل لا يسجل شيئاً، وملف مدخل يستورد ملفات محلية.
تجاوز أي شيء قررته:
--id يحدد معرّف المجموعة عندما يجب أن يختلف عن المستودع، --tag يحدد علامة الإصدار، --notes يستبدل ملاحظات الإصدار المُنتجة — وهي حيث policies show --releases تقرأ أعداد كل إصدار والتزام من — --out يختار حيث الأصول مكتوبة (افتراضي dist-pack)، و --dry-run يبنيها بدون نشر ولا يحتاج بيانات اعتماد.
يمكن لأي شخص الآن تثبيتها مع failproofai policies add acme/support-agent. انظر مجموعات السياسات لتثبيت إصدار والأخذ بجزء فقط من واحدة.
أدرجها في مركز السياسات
أضف موضوعfailproofai-policies إلى المستودع على GitHub. لا توجد نموذج تقديم ولا قائمة انتظار موافقة: زاحف مركز السياسات يلتقط المستودع في الممر التالي. الموضوع يضعه فقط قيد الدراسة — ما يدرجه هو إصدار بيانه يتحقق ضد SHA256SUMS الخاص به ويُحلل تحت نفس القواعد التي تستخدمها واجهة سطر الأوامر، وهو بالضبط ما failproofai publish ينتجه.
كيفية تحديد الإصدار
الإصدار هو الـ commit الذي تنشر منه — SHA القصير له، اثنا عشر حرفاً:a1b2c3d4e5f6. لا شيء لاختياره ولا شيء للزيادة، والإصدار يسمي بالضبط حيث جاءت البايتات، لذا نشر نفس المصدر مرتين يعطي نفس الإصدار.
يتم قراءته من الشجرة أمامك، ليس أبداً من إصدارات المستودع، لذا نسخة طازجة وجهاز معزول الهواء يحسبان نفس الإجابة بدون السؤال GitHub عما حدث قبل.
لأن الإصدار يسمي commit، هذا commit يجب أن يكون موجوداً. في محطة طرفية، publish يصنعه لك: يهيئ مستودع عندما لا يكون هناك واحد، والتزامات ملفات السياسات المتغيّرة قبل البناء. يرفض بدلاً من ذلك — يسمي --version كطريقة للخروج — عندما يعمل بدون محطة طرفية (التزام مصنوع على عداء CI لن يكون موجوداً في مكان آخر)، عندما ملفات أخرى غير السياسات لم تُلتزم، أو في checkout بدون التزامات بعد. علامة على HEAD تفوز على SHA — شخص وسّم v1.2.0 قال ما هذا الإصدار.
SHA لا يحمل ترتيباً من تلقاء نفسه، لذا استخدم failproofai policies show <owner>/<repo> --releases لرؤية أي إصدار جاء أولاً — الأحدث في الأعلى.
شحن إصدار جديد
التزم التغيير وشغّلfailproofai publish مرة أخرى — الالتزام الجديد هو الإصدار الجديد. المستهلكون يشغّلون نفس failproofai policies add. بدون محطة طرفية، أو مع علامة اختيار، يبقون على المجموعة الجزئية التي اختاروها وسياسة أطفأوها تبقى مطفأة؛ في محطة طرفية بدون علامة، يفتح المختار مع تحديد مسبق بقيمك الافتراضية وإجابتهم تستبدل اختيارهم.
تغيير اسم سياسة هو تغيير كسر: جهاز كان قد أطفأه يطفئ اسماً لا يعود موجوداً، والاسم الجديد يصل بأي defaultEnabled يقول.
ما يثق به مستخدموك
SHA256SUMS يعيش في نفس الإصدار مثل الأصل، لذا يثبت البايتات هي تلك التي نشرتها — ليس من أنت. أي شخص يمكنه الكتابة إلى المستودع يمكنه كتابة كلا الملفات. حماية مستخدميك هي أن الـ digest مثبت عند التثبيت، لذا ما شحنته لا يمكنه التغيير تحتهم بعد ذلك.
انشر من مستودع تتحكم في الوصول للكتابة فيه، وتعامل مع إصدار مجموعة مثل نشر حزمة.
المستودع يجب أن يكون أيضاً عام. عمليات التثبيت HTTPS مجهولة بدون بيانات اعتماد لتقديمها، لذا مستودع خاص موجود يتم رفضه قبل أي شيء مبني أو مرفوع، وواحد publish ينشئ عام لنفس السبب. --allow-private يتجاوز ذلك لشخص يسلّم الملفات الثلاثة بطريقة أخرى، ويقول بصراحة أن لا policies add يمكنه الوصول إليها. فقط الإصدار يهم: عمليات التثبيت تقرأ releases/download/<tag>/<asset> ولا تلمس شجرة git الخاصة بك.
لاحظ قبل أن تفرّض
البيان قد يعلن"effect": "observe" — failproofai publish --effect observe هو ما يحدده. تلك السياسات تعمل وأحكامها مسجلة ومرفوضة — لا شيء محجوب. إنها الطريقة لقياس قاعدة جديدة ضد حركة حقيقية قبل أن تستطيع قطع عمل أي شخص.