Auto: رسالة تنفيذ عثرة مخصصة

قد أفضّل عدم وجود ارتباطات (مثل semantic-release يفعل ذلك):

{
  "skipBumpCommit": true
}

مع تعطيل التزامات bump ، فإن أحدث إصدار NPM هو مصدر الحقيقة (أو ربما يعمل بالفعل بهذه الطريقة؟) ويمكن تعيين حقل "الإصدار" في package.json على 0.0.0-development أو ما شابه.

هل تخطي CI مختلف على ترافيس؟ بدون ذلك في رسائل الالتزام الخاصة بك ، يمكنك بسهولة الوقوع في حلقة

سيستخدم auto إلقاء نظرة على الإصدار المحلي والإصدار المنشور واختيار الإصدار الأعلى لتجنب أخطاء npm. هل هذا كاف؟

هل تخطي CI مختلف على ترافيس؟ بدون ذلك في رسائل الالتزام الخاصة بك ، يمكنك بسهولة الوقوع في حلقة

لست متأكدًا في الواقع. إذا كان ذلك مطلوبًا في رأس الالتزام ، فليكن. 😆

سيستخدم auto إلقاء نظرة على الإصدار المحلي والإصدار المنشور واختيار الإصدار الأعلى لتجنب أخطاء npm. هل هذا كاف؟

أوه حقا؟ لطيف - جيد. ليس هناك ارتباطات مطلقة تم إنشاؤها في هذه الحالة؟

لا ، في هذه الحالة ، نتفوق على الإصدار المنشور لأنه يمكنك النشر فوق إصدار قديم.

أواجه مشكلة في تصور كيفية عمل skipBumpCommit أو كيف ستبدو النتيجة النهائية. لتشغيل shipit لديك لتغيير الصيغة في بعض الطريق، لذلك لا استطيع ان ارى كيف يمكن الخروج من هذا الالتزام.

ما رأيك في shipit تخطي النتوء عندما يكون الإصدار الموجود في package.json شيئًا مثل 0.0.0-development ؟

1. تبدأ الحزمة في 0.0.0 تطوير

2. تقوم بتشغيل version تقوم بإرجاع النتوء بناءً على العلاقات العامة ، وتقوم بإرجاع أي شيء (تصحيح ، ثانوي ، كبير) - دعنا نقول أنه التصحيح

3. إنشاء سجل التغيير - (0.0.0-تطوير => 0.0.0). لكنك لا تريد أن يحدث ذلك؟ بدلاً من ذلك ، أضف تحت عنوان التغيير "0.0.0-development"؟

4. نشر وقت الخطافات - سيكون 0.0.0-development => 0.0.0 والنشر. لكنك تريد اكتشاف development وتخطي خطوة النشر معًا

5. إنشاء إصدار github - بدلاً من إنشاء إصدار جديد ، قم بتحديث الإصدار القديم بالالتزامات الجديدة

6. الحزمة تبقى في 0.0.0-التنمية حتى ؟؟؟ بينما تتراكم التغييرات

خياران إذا كان هذا هو ما تريده:

1. ببساطة لا تقم بتشغيل auto shipit حتى تريد البدء في الإصدار والنشر. لا تزال تضيف التسميات إلى العلاقات العامة الخاصة بك. عندما تكون جاهزًا ، أضف auto shipit إلى عملية CI الخاصة بك وستتضمن جميع التصنيفات PRs في إصدارك الأول.

2. اكتب ملحقًا. هذا السلوك فريد جدًا ولا يتوافق حقًا مع الطريقة التي يعمل بها npm في تعيين الإصدار. أعتقد أنه يمكنك إنشاء مكون إضافي لإنجاز هذه الأشياء. على الرغم من أنه من المحتمل أن أضطر إلى إضافة خطاف أو اثنين لتستخدمهما.

الحزمة ذات الإصدار 0.0.0-development تشير إلى ما يلي:

• تعتبر أحدث نسخة NPM المنشورة هي "الإصدار الحالي"
• لا يجب تغيير version في package.json أبدًا

عندما يجب نشر إصدار NPM جديد ، يجب أن يقوم Auto بزيادة "الإصدار الحالي" باستخدام npm version $(auto version) .

يستخدم سجل التغيير "الإصدار الحالي" من NPM (بدلاً من package.json ).

كما هو الحال دائمًا ، يتم إنشاء إصدار Github جديد لكل إصدار NPM.

هل أنا واضح بما فيه الكفاية؟

لا يجب تغيير الإصدار الموجود في package.json أبدًا

لنشر إصدارات جديدة إلى NPM ، يجب عليك تغيير هذا. الطريقة الوحيدة لزيادة "الإصدار الحالي" وعدم تغيير الإصدار المحلي أبدًا هي:

• قم بتغييره إلى الإصدار الحالي (NPM)
• تفعل النتوء
• قم بتغييره مرة أخرى
• ولكن بما أن العلامة ستكون النسخة الحالية من النتوء ؟؟؟

أنا متأكد من أنني أفهم حالة الاستخدام الخاصة بك.

أ. لا تريد نشر مجموعة من الإصدارات أثناء قيامك بتطوير ميزة عبر PRS متعددة
ب. بمجرد نشر إصدار جديد ، فأنت تريد تضمين جميع التغييرات

في نظري ، نقدم لك طريقتين للقيام بذلك:

1. استخدم onlyPublishWithReleaseLabel . لا يتم إنشاء إصدارات جديدة حتى تقوم بإضافة هذا التصنيف. لذا يمكنك إلقاء نظرة على أي رمز PR / بدون التسمية مثل VERSION-development

2. أثناء دمج PRs للميزة الكبيرة ، استخدم skip-release حتى تكون جاهزًا للحصول على إصدار ، ثم قم بدمج PR. يحتوي الإصدار الجديد على جميع العلاقات العامة التي تم تخطيها. في هذه الحالة ، يمكنك النظر إلى إضافة التصنيف skip-release للدلالة على أن إصدارك هو VERSION-development

كيف يختلف هذا عن السلوك الذي تريده؟

يبدو لي أنه يتلخص في: تريد إضافة -development إلى نسختك لبدء تخطي الإصدارات وإزالتها عندما تكون جاهزًا لإصدار جميع التغييرات مرة واحدة.

لإنجاز جملتي الأخيرة ، ربما يمكنك إنشاء مكون إضافي يستخدم beforeShipit للتحقق من وجود -development في الإصدار ويلقي خطأ إذا كان موجودًا. سيمنع هذا shipit من المضي قدمًا حتى تزيل -development .

المشكلة الوحيدة التي أراها مع هذا هي أنه سيفشل أيضًا في وظيفة CI.

تفسير مثير للاهتمام ، لكن ليس تمامًا ما قصدته. 😅

أنا أصف بشكل أساسي كيفية عمل semantic-release .

لقد قلت _should_ "تم تغيير الإصدار الموجود في package.json مؤقتًا فقط لكي ينجح npm publish " (بدلاً من "يجب عدم تغيير الإصدار الموجود في package.json أبدًا"). كل ما أحاول فعله حقًا هو تجنب الالتزام بالنتوء تمامًا. :)

حسنًا ، فالحالة التي ستنتهي بها هي:

الريبو: فقط لديه الإصدار 0.0.0-dev

npm: لديه الإصدار الحقيقي طوال الوقت (هذا ما يستخدم لأي شيء)

صيح؟

كيندا مثل

        if (auto.options.skipBumpCommit) {
          // get published version
          // change local version to publish
        } else {
          await execPromise('npm', [
            'version',
            latestBump || version,
            '-m',
            '"Bump version to: %s [skip ci]"'
          ]);
        }

        await setTokenOnCI();

        await execPromise(
          'npm',
          !isPrivate && isScopedPackage
            ? ['publish', '--access', 'public']
            : ['publish']
        );

        if (auto.options.skipBumpCommit) {
          // change local version back to DEV
        } 

        await execPromise('git', [
          'push',
          '--follow-tags',
          '--set-upstream',
          'origin',
          '$branch'
        ]);
      }

نعم ، تبدو جيدة!

auto v4.0.0 هنا نأتي لول. يبدو أنني سأضطر إلى تقسيم الخطاف publish . سيكون هذا مكونًا إضافيًا آخر

إذا كنت تريد ، يمكنك خبز هذه الميزة في Auto في الوقت الحالي ، وانتظر لتقسيم الخطاف publish حتى يحتاجه مكون إضافي آخر أيضًا. 😛

يجب أن يكون هذا ممكنًا عبر البرنامج المساعد الآن مع # 247 (قدرة semver). تتطلب رسالة الالتزام بعض التغييرات في التكوين ولا تحصل على الكثير حقًا. إغلاق ولكن مفتوح للعلاقات العامة!