RMT
1.0.0
RMT هي أداة مفيدة للمساعدة في إصدار إصدارات جديدة من برنامجك. يمكنك تحديد نوع مولد الإصدار الذي تريد استخدامه (مثل الإصدار الدلالي) ، حيث تريد تخزين الإصدار (على سبيل المثال في ملف changelog أو كعلامة VCS) وقائمة من الإجراءات التي يجب تنفيذها قبل أو بعد إصدار نسخة جديدة.
من أجل استخدام RMT في مشروعك ، يجب عليك استخدام الملحن لتثبيته باعتباره الاعتماد. فقط انتقل إلى دليل الجذر لمشروعك وتنفيذ:
composer require --dev liip/rmt
ثم يجب عليك تهيئة RMT عن طريق تشغيل الأمر التالي:
php vendor/liip/rmt/command.php init
سيقوم هذا الأمر بإنشاء ملف تكوين .rmt.yml ونصي RMT قابل للتنفيذ في مجلد جذر مشروعك. يمكنك الآن البدء في استخدام RMT من خلال التنفيذ:
./RMT
بمجرد وجودك ، يكون أفضل خيارك هو اختيار أحد أمثلة التكوين أدناه وتكييفه مع احتياجاتك.
إذا كنت تستخدم أداة الإصدار ، فإننا نوصي بإضافة كل من ملفات الملحن ( composer.json و composer.lock ) ، وملف تكوين RMT ( .rmt.yml ) والبرنامج النصي القابل للتنفيذ RMT . يجب تجاهل دليل vendor لأنه يتم ملؤه عند تشغيل composer install .
يمكنك إضافة RMT إلى Composer.json العالمي الخاص بك وتوفيرها على مستوى العالم لجميع مشاريعك. لذلك فقط قم بتشغيل الأمر التالي:
composer global require liip/rmt
تأكد من أن لديك ~/.composer/vendor/bin/ في مسار $ الخاص بك.
يمكن تثبيت RMT من خلال مركبة الفار ، والتي يجب تثبيتها عليها. تتيح لك هذه الأداة المفيدة إنشاء ملفات Phar Runnable من حزم الملحن.
إذا قمت بتثبيت Phar-composer ، فيمكنك تشغيل:
sudo phar-composer install liip/RMT
وقم بإنشاء ملف Phar-composer وتثبيته على مسار $ الخاص بك ، والذي يسمح لك بعد ذلك بتشغيله ببساطة كـ rmt من سطر الأوامر أو يمكنك تشغيله
phar-composer build liip/RMT
ونسخ ملف PHAR الناتج يدويًا إلى المكان الذي تحتاج إليه (إما اجعل ملف PHAR php rmt.phar للتنفيذ عبر chmod +x rmt.phar ./rmt.phar بتنفيذه مباشرة.
للحصول على بديل RMT مع أي متغير قررت استخدامه.
إذا كنت تستخدم https://github.com/liip/drifter لمشروعك ، فأنت بحاجة فقط إلى ثلاث خطوات
تنشيط دور rmt
أعد تشغيل vagrant provision
init rmt لمشروعك php /home/vagrant/.config/composer/vendor/liip/rmt/RMT liip/rmt/rmt
استخدام RMT واضح للغاية ، ما عليك سوى تشغيل الأمر:
./RMT release
تقوم RMT بعد ذلك بتنفيذ المهام التالية:
تنفيذ الشيكات المتطلبات
اطلب من المستخدم أن يجيب على أسئلة الإمكانات
تنفيذ إجراءات ما قبل الإصدار
يطلق
إنشاء رقم إصدار جديد
استمر في رقم الإصدار الجديد
تنفيذ إجراءات ما بعد الإصدار
هنا مثال على الإخراج:
يوفر أمر release السلوك الرئيسي للأداة ، وتتوفر بعض الأوامر الإضافية:
سيعرض current رقم الإصدار الحالي للمشروع (إصدار الاسم المستعار)
تعرض changes التغييرات التي سيتم دمجها في الإصدار التالي
تعرض config التكوين الحالي (تم دمجه بالفعل)
init إنشاء (أو إعادة تعيين) ملف .rmt.yml التكوين
جميع تكوينات RMT يجب أن يتم في .rmt.yml . يتم تقسيم الملف إلى ستة عناصر الجذر:
vcs : نوع VCs الذي تستخدمه ، يمكن أن يكون git أو svn أو none
بالنسبة لـ git VCS ، يمكنك استخدام خيارتي sign-tag sign-commit التالية إذا كنت ترغب في توقيع GPG لإصدارك
prerequisites : قائمة [] من المتطلبات الأساسية التي يجب مطابقتها قبل بدء عملية الإصدار
pre-release-actions : قائمة [] الإجراءات التي سيتم تنفيذها قبل عملية الإصدار
version-generator : المولد لاستخدامه لإنشاء إصدار جديد (إلزامي)
version-persister : Persister لاستخدامه لتخزين الإصدارات (إلزامية)
post-release-actions : قائمة [] الإجراءات التي سيتم تنفيذها بعد الإصدار
جميع إدخالات هذا التكوين تعمل بنفس الشيء. يجب عليك تحديد الفصل الذي تريد التعامل معه. مثال:
version-generator: "simple"` version-persister: vcs-tag: tag-prefix: "v_"
تدعم RMT أيضًا تكوينات JSON ، لكننا نوصي باستخدام YAML.
في بعض الأحيان ، تريد استخدام استراتيجية إصدار مختلفة وفقًا لفرع VCS ، على سبيل المثال ، تريد إضافة إدخالات Changelog فقط في الفرع master . للقيام بذلك ، يجب عليك وضع التكوين الافتراضي الخاص بك في عنصر جذر يسمى _default ، ثم يمكنك تجاوز أجزاء من هذا التهيئة الافتراضية master الفرع. مثال:
_default: version-generator: "simple" version-persister: "vcs-tag" master: pre-release-actions: [changelog-update]
يمكنك استخدام Command RMT config لمعرفة نتيجة الدمج بين _default وفرعك الحالي.
استراتيجيات توليد رقم الإصدار.
بسيط: يقوم هذا المولد بزيادة بسيطة (1،2،3 ...)
الدلالي: أحد المولد الذي ينفذ النسخة الدلالية
قد يكون الخيار القسريان مفيدين للغاية إذا قررت أن هناك فرعًا معينًا مخصصًا للنسخة التجريبية التالية لإصدار معين. لذا ، فكل ما عليك سوى إجبار العلامة على الإصدار التجريبي وكل الإصدار ستكون زيادات تجريبية.
الخيار allow-label (منطقي): للسماح بإضافة ملصق على إصدار (مثل -beta ، -rcxx) (افتراضي: خطأ )
type الخيار: لفرض نوع الإصدار
label الخيار: لفرض الملصق
فئة مسؤولة عن حفظ/استرداد رقم الإصدار.
VCS-TAG: احفظ الإصدار كعلامة VCS
خيار tag-pattern : اسمح بتوفير إعادة تدوين أن كل العلامة يجب أن تتطابق. هذا يسمح على سبيل المثال بإصدار الإصدار 1.xx في فرع معين وإصدار 2.xx في فرع منفصل
خيار tag-prefix : السماح ببادئة جميع علامة VCS مع سلسلة. يمكنك الحصول على إصدار رقمي ولكن علامات توليد مثل v_2.3.4 . كمكافأة ، يمكنك استخدام عنصر نائب محدد: {branch-name} الذي سيحقق اسم الفرع الحالي تلقائيًا في العلامة. لذا استخدم ، توليد بسيط tag-prefix: "{branch-name}_" وسيقوم بإنشاء علامة مثل featureXY_1 ، featureXY_2 ، إلخ ...
Changelog: احفظ الإصدار في ملف Changelog
الخيار location : اسم ملف Changelog موقع (افتراضي: Changelog )
يتم تنفيذ إجراءات المتطلب السابق قبل الجزء التفاعلي.
working-copy-check : تحقق من أنه ليس لديك أي تغييرات محلية VCS
الخيار allow-ignore : اسمح للمستخدم بتخطي الشيك عند إجراء إصدار مع- --ignore-check
display-last-changes : عرض التغييرات الأخيرة الخاصة بك
tests-check : قم بتشغيل مجموعة اختبار المشروع
command الخيار: الأمر لتشغيله (افتراضي: phpunit )
timeout الخيار: عدد الثواني التي وبعدها أوقات الأمر (افتراضي: 60.0 )
الخيار expected_exit_code : رمز الإرجاع المتوقع (افتراضي: 0 )
composer-json-check : قم بتشغيل التحقق من صحة على composer.json
composer الخيار: كيفية تشغيل الملحن (افتراضي: php composer.phar )
composer-stability-check : سوف تحقق ما إذا كان composer.json قد تم ضبطه على الحد الأدنى من الاستقرار الصحيح
stability الخيار: الاستقرار الذي يجب تعيينه في حقل الاستقرار الدنيا (افتراضي: مستقر )
composer-security-check : قم بتشغيل الملحن.
يجب تثبيت ثنائية الأمن المحلية-PHP-Security Binary على مستوى العالم.
composer-dependency-stability-check : الاختبار إذا كانت التبعيات المسموح بها فقط تستخدم إصدارات التطوير
الخيار ignore-require ignore-require-dev : لا تتحقق من التبعيات في قسم require أو require-dev
خيار whitelist : السماح تبعيات محددة باستخدام إصدار التطوير
command : تنفيذ أمر النظام
الخيار cmd الأمر الذي يجب تنفيذه
خيار live_output boolean ، هل نعرض إخراج الأوامر؟ (افتراضي: صحيح )
خيار timeout عدد صحيح ، يحد من وقت الأمر. (افتراضي: 600 )
خيار stop_on_error boolean ، هل نقوم باكتساب عملية الإصدار على الخطأ؟ (افتراضي: صحيح )
يمكن استخدام الإجراءات لأجزاء ما قبل أو ما بعد الإصدار.
changelog-update : قم بتحديث ملف changelog. تم تكوين هذا الإجراء بشكل أكبر لاستخدام تنسيق محدد.
format الخيار: بسيط ، دلالي ، تخفيض أو AddTop (افتراضي: بسيط )
file الخيار: المسار من .rmt.yml إلى ملف Changelog (افتراضي: Changelog )
خيار dump-commits : اكتب جميع رسائل الالتزام منذ الإصدار الأخير في ملف Changelog (افتراضي: خطأ )
insert-at : فقط من أجل addtop formatter: عدد الخطوط للتخطي من أعلى ملف changelog قبل إضافة رقم الإصدار (الافتراضي: 0 )
الخيار exclude-merge-commits : استبعاد الاندماج يربط من changelog (افتراضي: خطأ )
vcs-commit : ارتكب جميع ملفات نسخة العمل (استخدمها فقط مع المتطلب السابق working-copy-check )
خيار commit-message : حدد رسالة التزام مخصص. سيتم استبدال ٪ الإصدار ٪ بسلاسل الإصدار الحالية / التالية.
vcs-tag : علامة الالتزام الأخير
vcs-publish : نشر التغييرات (الالتزام والعلامات)
composer-update : قم بتحديث رقم الإصدار في ملف الملحن (لاحظ أنه عند استخدام packagist.org ، يوصى بعدم وجود علامة في composer.json لأن الإصدار هو التعامل مع علامات التحكم في الإصدار)
files-update : قم بتحديث الإصدار في ملف واحد أو عدة ملفات. لكي يتم تحديث كل ملف ، يرجى تقديم مجموعة مع
file الخيار: مسار إلى الملف للتحديث
pattern الخيار: اختياري ، استخدم لتحديد نمط استبدال السلسلة في ملفك. على سبيل المثال: const VERSION = '%version%';
build-phar-package : يبني حزمة Phar من المشروع الحالي الذي يعتمد اسم ملفه على خيار "Name-Name" والإصدار المنشور: [Package-Name]-[الإصدار]. Phar
package-name الخيار: اسم حزمة إنشاء
خيار destination : دليل الوجهة لإنشاء الحزمة. إذا كانت مسبوقة مع مائل ، تعتبر مطلقة ، وإلا نسبة إلى جذر المشروع.
الخيار excluded-paths : إعادة صياغة من المسارات المستبعدة ، تم تمريرها مباشرة إلى طريقة Phar :: BuildFromDirectory. على سبيل المثال: /^(?!.*cookbooks|.*.vagrant|.*.idea).*$/im
خيار metadata : مجموعة من البيانات الوصفية التي تصف الحزمة. المؤلف السابق ، المشروع. ملاحظة: تتم إضافة إصدار الإصدار افتراضيًا ولكن يمكن تجاوزه هنا.
الخيار default-stub-cli : الكعب الافتراضي لاستخدام CLI للحزمة.
الخيار default-stub-web : الكعب الافتراضي لاستخدام تطبيق الويب للحزمة.
command : تنفيذ أمر النظام
الخيار cmd الأمر الذي يجب تنفيذه
خيار live_output boolean ، هل نعرض إخراج الأوامر؟ (افتراضي: صحيح )
خيار timeout عدد صحيح ، يحد من وقت الأمر. (افتراضي: 600 )
خيار stop_on_error boolean ، هل نقوم باكتساب عملية الإصدار على الخطأ؟ (افتراضي: صحيح )
update-version-class : قم بتحديث الإصدار الثابت في ملف الفئة. تم إهماله ، استخدم files-update بدلاً من ذلك
class الخيار: مسار إلى الفصل ليتم تحديثه ، أو اسم الفئة المؤهلة بالكامل للفئة التي تحتوي على ثابت الإصدار
pattern الخيار: اختياري ، استخدم لتحديد نمط استبدال السلسلة في فئة الإصدار. سيتم استبدال ٪ الإصدار ٪ بسلاسل الإصدار الحالية / التالية. على سبيل المثال ، يمكنك استخدام const VERSION = '%version%'; . إذا لم تحدد هذا الخيار ، فسيتم استبدال كل حدوث سلسلة الإصدار في الملف.
تقوم RMT بتوفير بعض الإجراءات الحالية والمولدات والرسوم. إذا لزم الأمر ، يمكنك إضافة ملفك الخاص عن طريق إنشاء برنامج نصي PHP في مشروعك ، والرجوع إليه في التكوين عبر المسار النسبي:
version-generator: "bin/myOwnGenerator.php"
مثال مع المعلمات المحقونة:
version-persister: name: "bin/myOwnGenerator.php" parameter1: value1
على سبيل المثال ، يمكنك إلقاء نظرة على البرنامج النصي /bin/updateApplicationversionCurrentVersion.php الذي تم تكوينه هنا.
تحذير: حيث يتم استخدام name الرئيسي لتحديد اسم الكائن ، لا يمكن أن يكون لديك معلمة name .
في معظم الأوقات ، سيكون من الأسهل عليك التقاط مثال أدناه والتكيف مع احتياجاتك.
version-generator: semantic version-persister: changelog
vcs: git version-generator: simple version-persister: vcs-tag prerequisites: [working-copy-check, display-last-changes]
vcs: git version-generator: simple version-persister: vcs-tag prerequisites: - composer-json-check - composer-stability-check: stability: beta - composer-dependency-stability-check: whitelist: - [symfony/console] - [phpunit/phpunit, require-dev]
vcs: name: git sign-tag: true sign-commit: true version-generator: simple version-persister: vcs-tag prerequisites: [working-copy-check, display-last-changes]
vcs: git version-generator: semantic version-persister: name: vcs-tag tag-prefix : "v_" pre-release-actions: files-update: - [config.yml] - [app.ini, 'dynamic-version: %version%'] post-release-actions: [vcs-publish]
_default:
vcs: git
prerequisites: [working-copy-check]
version-generator: simple
version-persister:
name: vcs-tag
tag-prefix: "{branch-name}_"
post-release-actions: [vcs-publish]
# This entry allow to override some parameters for the master branch
master:
prerequisites: [working-copy-check, display-last-changes]
pre-release-actions:
changelog-update:
format: markdown
file: CHANGELOG.md
dump-commits: true
update-version-class:
class: DoctrineODMPHPCRVersion
pattern: const VERSION = '%version%';
vcs-commit: ~
version-generator: semantic
version-persister: vcs-tagإذا كنت ترغب في المساعدة ، من خلال تقديم أحد البرامج النصية أو المولدات أو المولدات. أو فقط عن طريق الإبلاغ عن خطأ ، ما عليك سوى الانتقال إلى صفحة المشروع https://github.com/liip/rmt.
إذا قمت بتقديم العلاقات العامة ، فحاول ربطها ببعض الاختبارات الوظيفية. انظر القسم التالي
لتكون قادرًا على إجراء الاختبارات محليًا ، تحتاج إلى:
phpunit
غيت
زئبقي
يمكنك تثبيت كل منهم مع المشروب:
> brew install phpunit git hg
تختبر الاختبارات أيضًا إنشاء RMT Phar. لذلك عليك أن تسمح بذلك في php.ini ، عن طريق إلغاء هذا الخط:
phar.readonly = Off
أخيرًا ، لتشغيل الاختبارات ، ما عليك سوى إطلاق phpunit
> phpunit
الاختبارات الوظيفية هي إعداد RMT المؤقتة بالكامل. في كل مرة تقوم فيها بإجراء اختبار وظيفي ، فإنه ينشئ مجلد مؤقت مع مشروع RMT. ثم يقوم مجموعة الاختبار بتشغيل أوامر RMT عليه ، وتحقق من النتائج. لهذا السبب تحتاج إلى تثبيت Git و Mercurial.
لتصحيح الاختبارات الوظيفية RMT ، الأفضل هو الذهاب إلى هذا المجلد المؤقت واستكشاف المشروع يدويًا. للقيام بذلك ، فقط إضافة $this->manualDebug(); في جناح الاختبار. سيؤدي هذا إلى كسر الاختبار مع الإخراج التالي:
MANUAL DEBUG Go to: > cd /private/var/folders/hl/gnj5dcj55gbc93pcgrjxbb0w0000gn/T/ceN2Mf
ثم عليك فقط الذهاب إلى المجلد المذكور وبدء تصحيح الأخطاء
جوناثان ماشريت ، ليب سا
ديفيد Jeanmonod Liip SA
وغيرهم من المساهمين
RMT مرخصة بموجب ترخيص معهد ماساتشوستس للتكنولوجيا. انظر ملف الترخيص للحصول على التفاصيل.
