الإطلاقات
SubLane دليل: الإطلاقات.
The Release سير العمل يبدأ عندما يدفع متعهد v* لا يوجد إطلاق تلقائي على الفرع العادي يدفع أو يسحب الطلبات
عقد الإصدار
استخدام البطاقات الكانتونية مثل v0.1.0 أو v0.1.0-rc.1- نسخة الطلب ونسخته Docker نسخة من البطاقة تحذف الرصاص vمكونات العددية الرئيسية، والفضاء الأبيض، والخصائص القصفية، والسيمفير، بناء البيانات الفوقية (SmVer)+...يجب أن تكون أجهزة تحديد الهوية العددية جاهزة للنشر.
ويشمل كل الإفراج ما يلي:
sublane_VERSION_linux_amd64.tar.gzوsublane_VERSION_linux_arm64.tar.gz.docker.compose.yamlوSHA256SUMSلملفات الإفراج العام- نموذج متعدد المعالم
ghcr.io/murongg/sublane:VERSIONصورة، بالإضافة إلى علامتي الهندسة. - احتفظ بسجلات إطلاق "غيرلوغ" من تاريخ "جيت" مع "جيت كليف" المثبتة 2.14.2
فقط أعلى علامة ثابتة موجودة حالياً في المستودع يمكنها تحديث Docker latest القناة والقناة GitHubآخر تعيينات السحب، أو نسخة الصيانة القديمة لا تنقل تلك القنوات إلى الوراء أبداً، إذا فشلت أعلى علامة مستقرة، أعيدوا تشغيل ذلك الإفراج، وعلامات أقل لا تأخذ مكانها عمداً، فالنشرات يجب أن تلصق نسخة أو نبذة بدلاً من الاعتماد على latest.
المستودعات للمرة الأولى
استخدامات تدفق العمل GITHUB_TOKENنطاقها contents: write و packages: write فقط في وظيفة النشر لا تحتاج إلى Docker حساب أو وصول شخصي إلى (كين) GitHub ويجب أن تسمح سياسة المستودع/التنظيم باتخاذ إجراءات ونشر مجموعة تدابير بناء الثقة في القطاع العام، وأن تُسند جميع المعالين إلى الالتزام الكامل بموئل الخدمات.
وعلامة المصدر الوديّة تربط الصورة بالمستودع، يمكن أن تكون حزمة الـ"جي آر" خاصّة أصلاً حتى لمستودع للمصدر العامّ، بعد أول منشور ناجح، تحقق من مواقع وصول الحزمة و تجعلها علنية إذا كانت السحبات المجهولة مقصودة. GitHub' وثائق سجل الحاويات- الاحتفاظ بمجموعات منشورة مرتبطة بهذا المستودع، بحيث تحافظ تدفقات العمل اللاحقة على إمكانية الحصول على الكتابة.
نشر نسخة
التكوين والاستعراض CHANGELOG.md على فرع التنمية الخاص بك مع make changelogثم إلزمها بوثائق إطلاق السراح ودمج هذه التغييرات وتدفق العمل في مرحلة الإفراج أولاً make check- اختيار نسخة جديدة غير مستخدمة؛ لا تحرك بطاقة إطلاق قائمة.
على سبيل المثال، بعد الاختيار v0.1.0:
git switch main
git pull --ff-only
make publish-check TAG=v0.1.0
make publish TAG=v0.1.0make publish-check يدير نفس الضوء دون خلق أو دفع علامة. make publish يخلق علامة مشروحة عند الالتزام موضع التفتيش ويدفع فقط تلك العلامة، ويحتاج كلاهما إلى شجرة عمل نظيفة (بما في ذلك الملفات غير المتعقبة)، main فرع، تدفق العمل الحالي للإفراج في ذلك الالتزام، و بالضبط واحد origin الوجهة التي main يطابق الـ (HAD) المحلي أو الـ (البطاقات) المكررة من بعد لا يتم تحويل أي فرع أو دمجه أو دفعه تلقائياً
وتحدد العلامة نوع الإطلاق؛ ولا يلزم وجود أي علم منفصل مسبق الإجازات:
make publish TAG=v0.1.0-rc.1يمكنك أن تهرب أيضاً node scripts/publish.mjs v0.1.0 --dry-run أو node scripts/publish.mjs v0.1.0 (ج) مطلوبة من المستودع مباشرةً، حيث توجد أوراق اعتماد الدفع لـ (جيت) عاملة (على سبيل المثال وكيل وزارة الصحة)؛ Docker ولا يلزم الحصول على وثائق تفويض المركبات، ويتحقق النص من العلامة النائية بعد دفعها وطباعتها GitHub وصلة سير العمل عندما يستخدم جهاز التحكم عن بعد GitHub URL.
وإذا فشل دفعة أو تعذر التحقق من نتيجة ذلك، فإن العلامة المحلية يحتفظ بها لأن جهاز التحكم قد يكون قد قبلها بالفعل، فتفتيش جهاز التحكم عن بُعد والإجراءات أولاً، وإذا لم تكن العلامة عن بعد، استخدم قيادة إعادة التشغيل الوحيدة التي طبعها النص، ولا تحذف البطاقات أو قسائم القوة أبداً، ويدفع السيناريو خط الأنابيب الحالي، ولا يبلغ عن البناء أو النشر على نحو كامل لمجرد الدفع.
والنسخة المثالية هي: نشر نسخة مختارة في وقت واحد وتفحص الإجراءات قبل الإعلان عن مدى توافرها، والدفع بعلامة نسخة هي دليل النشر؛ وتدفق العمل يخلق GitHub أطلق سراح نفسه.
تسلسل سير العمل
- قيّم البطاقة وضبط مسار صورة جهاز تحديد المواقع من اسم المستودع
- استدعاء سير العمل العادي CI: شيك العائمة، اختبارات جو السباق/الفحص، الشيكات الأمامية/المبنية، اختبارات البيانات الوصفية والإطلاق Compose التصديق.
- البناء وفحص الدخان Docker (ب) الصور على الـ (لينكس) الأم 64 و (الرشاشات الذائبة - في مجال الحد من الفقر والإطلاقات، استخلاص ثنائي حقيقي من كل صورة تم اختبارها، وحزمها بملفات النشر وإشعارات الترخيص، ثم فك عبئتها وتنفيذها للتحقق من النسخة، كما أن الإصدار يحفظ الصورتين اللتين تم اختبارهما على أنهما عملان قصيراً.
- بعد مرور جميع الشيكات، أحضر التاريخ الموسّم بالكامل، تُولّد ملاحظات إطلاق مع
cliff.tomlوخلق أو استئناف مشروع GitHub الإصدار - تُعاد صياغة مشاريع المذكرات عند إعادة النظر؛ ولا يُلغى أبداً إصدار نشرة سابقة. - وضع ودفع تلك الصور التي تم اختبارها، ثم وضع علامة متعددة النماذج، ولا يحدث بناء ثانٍ للتطبيق أثناء النشر.
- محفوظات ثنائية تحميل، Compose (ب) نظام التحقق SHA-256 - تشجيع أحدث قناة مستقرة عند الاستحقاق، ثم نشر الإصدار المكتمل.
تُدرج بطاقات الإرسال/الموارد/التنقيح في الصورة sublane --version (ب) التقارير الواردة في النسخة المجزأة - لا تتضمن الملفات الجذرية سوى المرافق العامة لطلاب الآلبين، وشهادات وكالة الأنباء المركزية العامة، والإخطارات الثنائية ورخص الترخيص، ولا يشمل ذلك أي فرز للمصادر أو مجمع أو معالون من Node.js أو بيانات محلية، ويستبعد السياق البناء قواعد البيانات المحلية، ومفاتيح التشفير، والمساندة، والعمل.
حالات الفشل والاختزال
الاستخدام الوظائف التي أخفقت في إعادة التشغيل على نفس مسار العمل عندما تفشل شبكة أو بناء أو تسجيل، قبل الإكمال، تبقى القطع الأثرية في مشروع ويمكن استبدالها بنسخة، قد توجد صور للتركيب/التحول إذا فشلت خطوة لاحقة؛ وتكمل عملية إعادة التشغيل نفس الإصدار. GitHub الإفراج لا يمكن أن يكون صفقة ذرية واحدة، لذلك تحقق كلا الوجهين بعد الفشل.
يتم الاحتفاظ بالقطع الأثرية لمدة سبعة أيام، وبعد انتهاء الصلاحية، إعادة تشغيل جميع الوظائف لإعادة بنائها وإعادة اختبارها، وتحل عمليات إعادة التشغيل محل الأعمال الفنية ذات الاسم في تلك العملية؛ وقد نشرت بالفعل GitHub ولا تزال الإطلاقات محمية، فعندما يتم نشرها، تستخدم نسخة جديدة من التصويبات الرمزية أو التغليفية بدلا من الإفراط في كتابة ذلك، ولا يؤدي حذف أو نقل بطاقة إلى تراجع البيانات المحمّلة أو الصور المنشورة أو قواعد البيانات المنشورة.
GITHUB_TOKEN- عادة ما لا تؤدي البطاقات المضغوطة إلى تدفق آخر للعمل، وإذا ما أحدثت التشغيل الآلي علامة أخرى، تستخدم نطاقا مناسبا GitHub )٣( انظر: انظر: GitHub' سير العمل يحفز القواعد.
العبوة المحلية
make release VERSION=0.0.0-testهذا يبني واجهة مرة واحدة، تقاطع بيني لينكس ويكتب المحفوظات بالإضافة إلى SHA256SUMS تم تجاهلها dist/release/- المحفوظات الموجودة غير مكتوبة بشكل مفرط؛ وتستخدم نسخة اختبار جديدة أو تحركات سابقة متولدة قبل إعادة البناء، ولا تدفع هذه القيادة الصور أو تخلق إطلاقات؛ وتبقي عملية التثبيت المحلية منفصلة عن الأدلة المحلية على تشغيل الحاويات.
جيل التغيير
Install git-cliff 2-14-2 (النسخة المثبتة في سجل التنفيذ) وهي أداة إنمائية وليست تبعية للخواديم، مثلاً مع تركيب نظام الحكم، تستخدم cargo install git-cliff --locked --version 2.14.2يمكن اختيار منفذ محمول من خلال GIT_CLIFF=/path/to/git-cliff.
make changelog
make changelog-checkcliff.toml وتحتفظ الاستخدامات بعناوين التغيير: مضافة وتغييرات وتصفية وتجديدات ومثبتة وأمنية، وتتابع الصور والمصفوفات البيانات التقليدية؛ وتتغير البنايات والأداء والمراجعات، وتحصل على أقسام خاصة بها، وتُحذف النسخ والاختبارات والنمط والزمن، بينما تُحدث تغييرات وتُستثنى من ذلك.
يقرأ التوليد سجل Git المحلي مع تعطيل بيانات الشبكة الوصفية وأوامر القوالب الخارجية. ولا يستبدل CHANGELOG.md إلا بعد نجاح التوليد، ولا ينشئ وسومًا أو يغيّر الإصدارات أو ينشئ التزامات. أدرج الملف الناتج عبر طلب سحب عادي قبل تشغيل make publish، الذي ما زال يتطلب فرع main نظيفًا ومتزامنًا. يتضمن سجل المستودع أقسام الإصدارات التمهيدية، بينما تلخّص ملاحظات الإصدار المستقر الدورة كاملة منذ الوسم المستقر السابق، بما في ذلك التغييرات التي ظهرت أولًا في الإصدارات التمهيدية.
بالنسبة لبطاقة قائمة تم فحصها في "هاد"
make release-notes TAG=v0.1.0هذا مكتوب dist/release-notes.md باستخدام نفس النموذج، وتدفقات العمل المفرج عنها تُثبت المولد المعلق، وتُكمل المولدات تاريخها وتُنقل هذا الملف إلى GitHub- رُفضت بطاقة مفقودة أو غير مطابقة، وتُجري شركة CI اختبارات تكامل ذات تاريخ اصطناعي؛ make changelog-check محلياً للتمكين من إجراء تلك الاختبارات عندما يتم تركيب مشبك جيت. make check يبقيها اختيارية ما لم SUBLANE_TEST_CHANGELOG=1 تم تحديده، ولا أي من القيادة يغيّر النظام.