release please

الافراج من فضلك

الإصدار يرجى أتمتة إنشاء سجل التغيير، وإنشاء إصدارات GitHub، وتحسينات الإصدار لمشاريعك.

يقوم بذلك عن طريق تحليل سجل git الخاص بك، والبحث عن رسائل الالتزام التقليدية، وإنشاء علاقات عامة للإصدار.

ولا يتعامل مع النشر لمديري الحزم أو يتعامل مع إدارة الفروع المعقدة.

ما هو الإصدار للعلاقات العامة؟

بدلاً من تحرير ما تم وصوله إلى فرعك الافتراضي بشكل مستمر، يرجى الحفاظ على الإصدار - يرجى الحفاظ على العلاقات العامة للإصدار:

يتم تحديث تقارير العلاقات العامة للإصدار هذه عند دمج العمل الإضافي. عندما تكون جاهزًا لوضع علامة على الإصدار، ما عليك سوى دمج الإصدار PR. يعمل كل من التزام الدمج والاسكواش مع الإصدار PRs.

عند دمج الإصدار PR، يرجى اتخاذ الخطوات التالية:

1. يقوم بتحديث ملف سجل التغيير الخاص بك (على سبيل المثال CHANGELOG.md )، بالإضافة إلى ملفات أخرى خاصة باللغة (على سبيل المثال package.json ).

2. علامات الالتزام مع رقم الإصدار

3. ينشئ إصدار GitHub بناءً على العلامة

يمكنك معرفة مكان وجود الإصدار PR في دورة حياته من خلال تسمية الحالة الموجودة على PR نفسه:

• autorelease: pending هو الحالة الأولية للإصدار PR قبل دمجه

• autorelease: tagged تعني أنه تم دمج الإصدار PR وتم وضع علامة على الإصدار في GitHub

• autorelease: snapshot هي حالة خاصة لمطبات إصدار اللقطة

• autorelease: published يعني أنه تم نشر إصدار GitHub استنادًا إلى بيان الإصدار ( الإصدار - الرجاء لا يضيف هذه العلامة تلقائيًا، ولكننا نوصي بها كاتفاقية لأدوات النشر ).

كيف يجب أن أكتب التزاماتي؟

الإصدار من فضلك يفترض أنك تستخدم رسائل الالتزام التقليدية.

أهم البادئات التي يجب أن تضعها في اعتبارك هي:

• fix: الذي يمثل إصلاحات الأخطاء، ويرتبط بتصحيح SemVer.

• feat: الذي يمثل ميزة جديدة، ويرتبط بـ SemVer minor.

• feat!: ، أو fix!: ، refactor!: ، وما إلى ذلك، والتي تمثل تغييرًا جذريًا (يُشار إليه بواسطة ! ) وسيؤدي إلى SemVer Major.

سجل التزام git الخطي (استخدم دمج الاسكواش)

نوصي بشدة باستخدام دمج الاسكواش عند دمج طلبات السحب. يُسهل سجل git الخطي ما يلي:

• سجل المتابعة - يتم فرز الالتزامات حسب تاريخ الدمج ولا يتم خلطها بين طلبات السحب

• البحث عن الأخطاء وإعادتها - يعد git bisect مفيدًا لتتبع التغيير الذي أدى إلى ظهور خطأ

• التحكم في الإصدار - من فضلك سجل التغيير - عند دمج العلاقات العامة، قد يكون لديك رسائل التزام منطقية ضمن نطاق العلاقات العامة، ولكنها لا تكون منطقية عند دمجها في الفرع الرئيسي. على سبيل المثال، قد يكون لديك feat: introduce feature A ثم fix: some bugfix introduced in the first commit . إن التزام fix لا علاقة له في الواقع بملاحظات الإصدار حيث لم يكن هناك أي خطأ في الفرع الرئيسي.

• احتفظ بفرع رئيسي نظيف - إذا كنت تستخدم شيئًا مثل التطوير الأحمر/الأخضر (قم بإنشاء اختبار فاشل في الالتزام A، ثم أصلحه في الالتزام B) وقم بالدمج (أو إعادة الدمج)، فستكون هناك نقاط زمنية في فرعك الرئيسي حيث لا تمر الاختبارات.

ماذا لو كانت العلاقات العامة الخاصة بي تحتوي على إصلاحات أو ميزات متعددة؟

يتيح لك Release Please تمثيل تغييرات متعددة في التزام واحد، باستخدام التذييلات:

 الفذ: يضيف v4 UUID إلى التشفير

يؤدي هذا إلى إضافة دعم لمعرفات UUID v4 إلى المكتبة.

الإصلاح (utils): لم يعد Unicode يطرح استثناءً
  PipeOrigin-RevId: 345559154
  كسر التغيير: لم تعد طريقة التشفير تُطرح.
  رابط المصدر: googleapis/googleapis@5e0dcb2

الفذ (utils): تحديث التشفير لدعم Unicode
  PiperOrigin-RevId: 345559182
  رابط المصدر: googleapis/googleapis@e5eef86

ستحتوي رسالة الالتزام أعلاه على:

1. إدخال لميزة "يضيف v4 UUID إلى التشفير" .

2. إدخال للإصلاح "لم يعد Unicode يطرح استثناءً" ، بالإضافة إلى ملاحظة مفادها أن هذا تغيير جذري.

3. إدخال لميزة "تحديث التشفير لدعم Unicode" .

️ هام: يجب إضافة الرسائل الإضافية إلى أسفل الالتزام.

كيف يمكنني تغيير رقم الإصدار؟

عندما يكون الالتزام بالفرع الرئيسي يحتوي على Release-As: xxx (غير حساس لحالة الأحرف) في نص الالتزام ، فإن Release Please سيفتح طلب سحب جديدًا للإصدار المحدد.

مثال التزام فارغ:

git commit --allow-empty -m "chore: release 2.0.0" -m "Release-As: 2.0.0" يؤدي إلى رسالة الالتزام التالية:

 العمل الرتيب: الإصدار 2.0.0

الإصدار باسم: 2.0.0

كيف يمكنني إصلاح ملاحظات الإصدار؟

إذا قمت بدمج طلب سحب وترغب في تعديل رسالة الالتزام المستخدمة لإنشاء ملاحظات الإصدار لهذا الالتزام، فيمكنك تحرير نص طلبات السحب المدمجة وإضافة قسم مثل:

BEGIN_COMMIT_OVERRIDE
feat: add ability to override merged commit message

fix: another message
chore: a third message
END_COMMIT_OVERRIDE

في المرة التالية التي يتم فيها تشغيل Release Please، سيستخدم قسم التجاوز هذا كرسالة التزام بدلاً من رسالة الالتزام المدمجة.

️ هام: لن تعمل هذه الميزة مع عمليات الدمج البسيطة لأن الإصدار-الرجاء عدم معرفة الالتزام (الالتزامات) الذي سيتم تطبيق التجاوز عليه. نوصي باستخدام دمج الاسكواش بدلاً من ذلك.

الإصدار من فضلك لا يقوم الروبوت بإنشاء إصدار PR. لماذا؟

الخطوة 1: التأكد من دمج الوحدات القابلة للإصدار

الإصدار يرجى إنشاء طلب سحب الإصدار بعد أن لاحظ أن الفرع الافتراضي يحتوي على "وحدات قابلة للإصدار" منذ الإصدار الأخير. الوحدة القابلة للنشر هي التزام بالفرع باستخدام إحدى البادئات التالية: "feat"، و"fix"، و"deps". (لا يعد الالتزام "العمل الرتيب" أو "الإنشاء" وحدة قابلة للنشر.)

تحتوي بعض اللغات على تكوين خاص للوحدة القابلة للنشر. على سبيل المثال، "docs" هي بادئة للوحدات القابلة للإصدار في Java وPython.

الخطوة 2: التأكد من عدم وجود autorelease: pending أو autorelease: triggered في PR قديم

تحقق من طلبات السحب الموجودة التي تحمل autorelease: pending أو autorelease: triggered . نظرًا لفشل واجهة برمجة تطبيقات GitHub، فمن المحتمل أنه لم تتم إزالة العلامة بشكل صحيح عند إصدار سابق ويعتقد الإصدار من فضلك أن الإصدار السابق لا يزال معلقًا. إذا كنت متأكدًا من عدم وجود إصدار معلق، فقم بإزالة تسمية الإصدار autorelease: pending أو autorelease: triggered .

بالنسبة لمستخدمي تطبيق GitHub، لن يقوم الإصدار من فضلك بإنشاء طلب سحب جديد إذا كان هناك طلب سحب موجود يحمل علامة autorelease: pending . لتأكيد هذه الحالة، ابحث عن طلب سحب مع التسمية. (من المحتمل جدًا أن يكون هذا هو أحدث طلب سحب للإصدار.) إذا وجدت طلب سحب للإصدار مع التسمية ولن يتم إصداره (أو تم إصداره بالفعل)، فقم بإزالة الإصدار autorelease: pending وأعد تشغيل الإصدار من فضلك.

الخطوة 3: أعد تشغيل الإصدار من فضلك

إذا كنت تعتقد أن الإصدار الرجاء قد فاتك إنشاء بيان صحفي للإصدار بعد دمج طلب السحب بوحدة قابلة للإصدار، فيرجى إعادة تشغيل release-please . إذا كنت تستخدم تطبيق GitHub، فأضف تسمية release-please:force-run إلى طلب السحب المدمج. إذا كنت تستخدم الإجراء، فابحث عن الاستدعاء الفاشل وأعد محاولة تشغيل سير العمل. سوف يقوم الإصدار الرجاء بمعالجة طلب السحب على الفور للعثور على الوحدات القابلة للإصدار.

أنواع الإستراتيجية (اللغة) المدعومة

الإصدار الرجاء أتمتة الإصدارات للأنواع التالية من المستودعات:

نوع الإصدار	وصف
bazel	وحدة Bazel، مع MODULE.bazel وCHANGELOG.md
dart	مستودع يحتوي على pubspec.yaml وCHANGELOG.md
elixir	مستودع يحتوي على mix.exs وCHANGELOG.md
go	مستودع يحتوي على CHANGELOG.md
helm	مستودع يحتوي على Chart.yaml وCHANGELOG.md
java	إستراتيجية تقوم بإنشاء إصدار SNAPSHOT بعد كل إصدار
krm-blueprint	حزمة kpt، تحتوي على ملف KRM واحد أو أكثر وCHANGELOG.md
maven	تقوم إستراتيجية مشاريع Maven بإنشاء إصدار SNAPSHOT بعد كل إصدار وتحديث pom.xml تلقائيًا
node	مستودع Node.js، مع package.json وCHANGELOG.md
expo	مستودع React Native قائم على Expo، مع package.json وapp.json وCHANGELOG.md
ocaml	مستودع OCaml، يحتوي على ملف واحد أو أكثر من ملفات opam أو esy وCHANGELOG.md
php	مستودع يحتوي على الملحن.json وCHANGELOG.md
python	مستودع Python، مع setup.py وsetup.cfg وCHANGELOG.md واختياريًا pyproject.toml و<project>/__init__.py
ruby	مستودع يحتوي على version.rb وCHANGELOG.md
rust	مستودع الصدأ، مع Cargo.toml (إما كصندوق أو مساحة عمل، على الرغم من ملاحظة أن مساحات العمل تتطلب إصدارًا قائمًا على البيان والمكون الإضافي "cargo-workspace") وCHANGELOG.md
sfdx	مستودع يحتوي على sfdx-project.json وCHANGELOG.md
simple	مستودع يحتوي على version.txt وCHANGELOG.md
terraform-module	وحدة Terraform، مع إصدار في README.md، وCHANGELOG.md

إعداد الإصدار من فضلك

هناك مجموعة متنوعة من الطرق التي يمكنك من خلالها نشر الإصدار، من فضلك:

إجراء GitHub (مستحسن)

أسهل طريقة لتشغيل Release Please هي كإجراء GitHub. يرجى الاطلاع على googleapis/release-please-action للحصول على تعليمات التثبيت والتكوين.

يعمل كـ CLI

يرجى الاطلاع على إصدار التشغيل-يرجى واجهة سطر الأوامر (CLI) للتعرف على كافة خيارات التكوين.

قم بتثبيت تطبيق جيثب

يتوفر تطبيق روبوت، والذي يسمح لك بنشر Release Please كتطبيق GitHub. يرجى الاطلاع على github.com/googleapis/repo-automation-bots للحصول على تعليمات التثبيت والتكوين.

تمهيد المستودع الخاص بك

الإصدار يرجى إلقاء نظرة على الالتزامات منذ علامة الإصدار الأخير. قد يكون أو لا يتمكن من العثور على إصداراتك السابقة. أسهل طريقة لضم المستودع الخاص بك هي التمهيد لتكوين البيان.

تخصيص الإصدار من فضلك

الإصدار يرجى توفير العديد من خيارات التكوين للسماح بتخصيص عملية الإصدار الخاصة بك. يرجى الاطلاع على customizing.md لمزيد من التفاصيل.

دعم Monorepos عبر تكوين البيان

يدعم الإصدار من فضلك أيضًا إصدار العديد من القطع الأثرية من نفس المستودع. رؤية المزيد في البيان-releaser.md.

إصدارات Node.js المدعومة

تتبع مكتبات عملائنا الجدول الزمني لإصدار Node.js. المكتبات متوافقة مع جميع الإصدارات النشطة وإصدارات الصيانة الحالية من Node.js.

تتوفر مكتبات العملاء التي تستهدف بعض إصدارات Node.js المنتهية، ويمكن تثبيتها عبر علامات التوزيع npm. تتبع علامات التوزيع اصطلاح التسمية legacy-(version) .

يتم دعم إصدارات Node.js القديمة كأفضل جهد:

• لن يتم اختبار الإصدارات القديمة في التكامل المستمر.

• قد لا يكون من الممكن نقل بعض تصحيحات الأمان إلى الخلف.

• لن يتم تحديث التبعيات، ولن يتم نقل الميزات إلى الخلف.

العلامات القديمة المتاحة

• legacy-8 : قم بتثبيت مكتبات العميل من علامة التوزيع هذه للإصدارات المتوافقة مع Node.js 8.

الإصدار

تتبع هذه المكتبة الإصدار الدلالي.

المساهمة

المساهمات موضع ترحيب! راجع دليل المساهمة.

لمزيد من المعلومات حول تصميم المكتبة، انظر التصميم.

استكشاف الأخطاء وإصلاحها

للتعرف على المشكلات الشائعة والمساعدة في استكشاف أخطاء التكوين وإصلاحها، راجع استكشاف الأخطاء وإصلاحها.

رخصة

أباتشي الإصدار 2.0

انظر الترخيص

تنصل

هذا ليس أحد منتجات Google الرسمية.