Auto: الإصلاحات - تصحيحات الدعم للقصر القديم والتصحيحات

تضمين التغريدة
هل لديك أي تفاصيل حول كيفية تنفيذ ذلك / كيف سيبدو عمليًا؟

أيضًا ، لست متأكدًا من أنني أفهم ما تعنيه merge into a tag ... هل من المحتمل أن توضح ذلك؟ كنت أفهم أنه يمكنك فقط إنشاء علاقات عامة مع وجود فرع كهدف.

لا ، لم أفكر حقًا بشأن المشكلة كثيرًا.

أيضًا ، لست متأكدًا من أنني أفهم معنى الدمج في العلامة

قادتني واجهة المستخدم إلى الاعتقاد بأنك قد تكون قادرًا على الدمج في علامة ، ولكن بعد إجراء مراجعة إضافية ، لا يبدو هذا ممكنًا. إذا استطعنا على الرغم من أن هذا سيجعل هذا ممكنًا.

أتذكر قليلاً رغم ذلك ، أعتقد أن هذا ما كنت أفكر فيه:

1. العلامة 1.2.3 موجودة ، الإصدار الحالي هو 2.0
2. تم تحويل PR إلى علامة 1.2.3 ، ينتج 1.2.3-0 (0 هو جزء البناء من semver)

حسنًا ، استخدام جزء البناء من semver أمر منطقي بالتأكيد. 👍

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

يمكن استخدام نهج مشابه للدعم الرئيسي القديم ( versionBranches ) حيث يمكن تحديد بادئة فرع في التكوين. يبدو أن هذه الميزة قد تكون موجهة بشكل أكبر نحو إصدارات نوع الإصلاح العاجل ، لذلك ربما يكون من المنطقي إبقاء التكوين منفصلاً عن الدعم الرئيسي القديم. ماذا تعتقد؟

قد يبدو تدفق المثال كما يلي:

• يحدد المستخدم في التكوين التلقائي للبناء باستخدام معرفات الإنشاء للفروع ذات البادئة hotfix-
• سجل الالتزام الحالي
  <ul> <li>(tag: v2.0.0) (master)<br /> |</li> <li>(tag: v1.2.0)<br /> |</li> <li>(tag: v1.1.0)<br /> |</li> <li>(tag: v1.0.0)<br />

يمكن استخدام نهج مماثل للدعم الرئيسي القديم (versionBranches) حيث يمكن تحديد بادئة فرع في التكوين.

تعجبني الفكرة ولكن من الناحية العملية لا أعتقد أنها ستكون ممتعة في الاستخدام. نظرًا لأن auto يصدر الكثير ، فقد ينتهي بك الأمر مع عدد مجنون من الفروع.

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

أوافق على أن هذا النوع من الإفراج خارج عن القاعدة. مما يجعل إنشاء الفروع الآلية أقل فائدة. ستحصل على الكثير من الضوضاء (المزيد من الفروع) دون استخدامها كثيرًا ، إن وجدت.

بالنسبة للتدفق المقترح أعلاه ، يبدو أنه يعمل بشكل جيد. من المؤسف أننا لا نستطيع تحويل العلاقات العامة إلى علامات رغم ذلك! سيجعل طريقة سير العمل هذه أسهل.

بالتفكير في هذا ، من المحتمل أن تحتاج هذه الميزة إلى بعض الأشياء في auto حتى يتم تجسيدها بالكامل:

1. الأمر الجديد auto hotfix : عند التشغيل سيطلق المشروع بإصدار جديد للإصلاح العاجل بناءً على أحدث علامة في الفرع
2. وظيفة جديدة لـ auto shipit : اكتشف ما إذا كنا في hotfixBranch وقمنا بتشغيل auto hotfix

بالنسبة لكيفية عمل auto hotfix ، فيمكن إما الانتقال:

1. طريقة next أو canary => أداة ربط جديدة تسمح للمكوِّن الإضافي بالتحكم في كيفية إصدار الإصلاح العاجل سواء كان مدعومًا على الإطلاق
2. إعادة استخدام الخطافات version و publish وجعلها قادرة على إطلاق semver build

من بين الخيارين ، أعتقد أنني أميل إلى 1 منذ استدعاء الخطافات version و pubish بطريقة جديدة يمكن اعتبارها تغييرًا جذريًا. العيب في ذلك هو أن بعض الخطافات لن يُطلق عليها afterVersion مما يجعل بعض الإضافات لا تعمل. هذه مشكلة حاليًا لكل من canary و next الرغم من ذلك. لأنهم لا يسمون هذا الخطاف أيضًا. لذلك شيء لا داعي للقلق بشأنه على الفور.

هل أنت مهتم بمحاولة إضافة هذا؟

تعجبني الفكرة ولكن من الناحية العملية لا أعتقد أنها ستكون ممتعة في الاستخدام. نظرًا لأن الإصدارات التلقائية كثيرة ، فقد ينتهي بك الأمر مع عدد مجنون من الفروع.

عفوًا ، يعني أنه كان مشابهًا للدعم الرئيسي القديم من حيث وجود تهيئة فرع البادئة. توافق بالتأكيد على أن إنشاء الفروع تلقائيًا من شأنه أن يخلق الكثير من الضوضاء ، خاصة مع الإصدار المتكرر ، 😆

بالتفكير في هذا ، من المحتمل أن تحتاج هذه الميزة إلى بعض الأشياء في تلقائي ليتم تجسيدها بالكامل:

1. الإصلاح التلقائي الجديد للأمر: عند التشغيل سيصدر المشروع بإصدار جديد للإصلاح العاجل استنادًا إلى أحدث علامة في الفرع
2. وظيفة جديدة لشحن السيارة: اكتشف ما إذا كنا في مجموعة إصلاحات عاجلة وقم بتشغيل الإصلاح العاجل التلقائي

نعم. أعتقد أن هذا سيغلف إلى حد كبير التغييرات المطلوبة.

بالنسبة لكيفية عمل الإصلاح العاجل التلقائي ، فيمكنه إما أن يذهب:

1. the way of next or canary => New hook الذي يسمح للمكوِّن الإضافي بالتحكم في كيفية إصدار الإصلاح العاجل سواء كان مدعومًا على الإطلاق
2. إعادة استخدام الإصدار ونشر الخطافات وجعلهم قادرين على إصدار semver للبناء

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

مستوى عالٍ ، أعتقد أن الرقم 1 منطقي أيضًا. سأحتاج إلى التتبع من خلال الكود للحصول على فهم أفضل للخطافات التي يتم استدعاؤها لأي أمر ، ولكن إذا كان next ، canary ، & hotfix تتبع جميعها أنماطًا متشابهة ، إذًا من المحتمل أن يكون من الأسهل حل أي نقاط ألم لاحقًا.

هل أنت مهتم بمحاولة إضافة هذا؟

بالتأكيد 👍 ، سأكون سعيدًا بذلك.
ربما لن أتمكن من إلقاء نظرة على التنفيذ لهذا الأمر حتى الأسبوع المقبل ، لكنني أعتقد أن هذا لا بأس به لأن هذه المشكلة لم يتم تحديثها منذ مارس.

مذهل! لا يوجد عمل مخطط على هذا ، لذا فهو كل ما عليك

FWIW - كنت سأحاول إنشاء هذا كمكوِّن إضافي من خلال القيام بالضبط بما تعتبره خيارًا أدنى - إنشاء فرع version-MAJOR-MINOR . لا يبدو أن هناك الكثير من الضجيج على عمليتنا الحالية ، TBH. لقد قمنا بالفعل بإنشاء فروع لكل سطر إصدار.

جزء كبير من versionBranches الآن هو هذا المكون الإضافي :

    this.hooks.beforeCommitChangelog.tapPromise(
      "Old Version Branches",
      async ({ bump }) => {
        if (bump === SEMVER.major && this.config?.versionBranches) {
          const branch = `${this.config.versionBranches}${major(
            await this.hooks.getPreviousVersion.promise()
          )}`;

          await execPromise("git", [
            "branch",
            await this.git?.getLatestTagInBranch(),
          ]);
          await execPromise("git", ["push", this.remote, branch]);
        }
      }
    );

يبدو من التافه إضافة دعم لـ SEMVER.minor ، لكنني أعترف أنني لا أعرف ما هي الأجزاء الأخرى من السيارة التي قد تحتاج إلى تغيير.

هذا جزء مما يحدث للإصدار القديم ولكن بعد ذلك يجب أيضًا اجتياز هذا التحقق في shipit

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1442

الذي ينتقل بعد ذلك إلى هنا ويؤدي بشكل أساسي إلى تجاوز المكان الذي يجب بدء حساب الإصدار منه

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1509

الاعتبار الوحيد الذي يتعين علينا مراعاته مع الإصدار الثانوي / التصحيح القديم وليس الرئيسي هو عدم تطابق الإصدار المحتمل. ومع ذلك ، ربما تكون المشكلة أقل مع القصر

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *  (tag: v1.1.2) <- Need to add logic to find an available tag 
| /
*  (tag: v1.1.0) (hotfix-feature)
|
*  (tag: v1.0.0)

لذلك ربما لا تكون هناك حاجة إلى الأمر hotfix . بدلاً من ذلك ، يمكنه فقط محاولة رقم الإصدار الفريد. يجب أن يكون هناك بعض التحقق من الصحة حول هذا بالرغم من ذلك.

القواعد :

1. لا يمكن تحرير الرئيسي في أي فرع إصدار ثانوي / تصحيح قديم (مطلوب)
2. لا يمكن تحرير الإصدار الثانوي على أي فرع إصدار تصحيح قديم (ربما غير ضروري؟)

تضمين التغريدة
هل تعرف ما هو السلوك الافتراضي الآن إذا كان لديك إعداد ci لإنشاء علامة قديمة ، حيث لا تتوفر العلامة التالية؟

تخميني ، هل سيكون هناك فشل ، على الرغم من أنني لست متأكدًا من مكان حدوث هذا الخطأ (ربما عند دفع العلامة؟).

بمعنى آخر:

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *   <- what is current behavior if I try to release this commit
| /
*  (tag: v1.1.0) 
|
*  (tag: v1.0.0)

خارج تطبيق القواعد المحددة hipstersmoothie ، أرى مشكلة / ارتباكًا محتملاً مع إستراتيجية / تنفيذ try to unique version number . على سبيل المثال ، أعطى hipstersmoothie مثالاً ، v1.1.2 من قبل الآخرين على أنه إصدار تصحيح من v1.1.1 ، ولكن نظرًا لأن التطوير لم يكن خطيًا ، فهذا غير مضمون. من المحتمل أن يكون هناك تغيير عكسي غير متوافق من v1.1.1 إلى v1.1.2 لأنه من المحتمل أن v1.1.2 لا يحتوي على التغييرات من v1.1.1 . قد يتفاقم هذا الأمر ويزداد إرباكًا إذا كان الإصدار الفريد التالي هو مسافة أكبر من v1.1.0 (على سبيل المثال: ماذا لو كان الإصدار الفريد التالي هو v1.1.100 ؟)

سيؤدي استخدام جزء بيانات تعريف الإنشاء من semver إلى الحد من هذا الالتباس لأنه وفقًا لمواصفات semver ، يتم تجاهله عند حساب أسبقية الإصدار. في حالة زيادة رقم البيانات الوصفية للبناء ، فربما يمكن استخدام sha الالتزام بدلاً من الرقم المتزايد.

بشكل عام ، تطوير البرامج ليس بالضرورة خطيًا ، لذا لست متأكدًا من وجود أفضل تطبيق.

إذا أردنا التعميم ، فربما يكون لدينا نوع من التكوين أو الخطاف لتحديد الإستراتيجية أعلاه بغض النظر عن الفرع (أو يمكن أن يكون الفرع معلمة لربطها).
بهذه الطريقة ، يمكن استخدام تطبيقات مختلفة عبر المكونات الإضافية.

هل تعرف ما هو السلوك الافتراضي الآن إذا كان لديك إعداد ci لإنشاء علامة قديمة ، حيث لا تتوفر العلامة التالية؟

عادةً لا يتم إنشاء العلامات لأن التنفيذ يحتوي على [skip ci] في الرسالة

قد يتفاقم هذا الأمر ويزداد إرباكًا إذا كان الإصدار الفريد التالي هو مسافة أكبر من الإصدار 1.1.0

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

إذا أردنا التعميم ، فربما يكون لدينا نوع من التكوين أو الخطاف لتحديد الإستراتيجية أعلاه بغض النظر عن الفرع (أو يمكن أن يكون الفرع معلمة لربطها).
بهذه الطريقة ، يمكن استخدام تطبيقات مختلفة عبر المكونات الإضافية.

لقد أقنعتني مشاركتك إلى حد كبير أن العثور على علامة فريدة يعد مخططًا محيرًا للانطلاق وربما لا ينبغي لنا ذلك.

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

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.2.0)
|
|  *  (tag: v1.1.5) <- Can merge patched into old minor branch, maybe error when PR has `minor`
| /
*  (tag: v1.1.4) <- branch: version-1.1
|
*  (tag: v1.0.0)

ثم نحتاج فقط إلى القيام بجزء البيانات الوصفية للبناء من أجل ترقيع التصحيحات.

مع دمج الخيارين from و useVerion ، هل هناك طريقة مضمنة لإجراء إصلاح عاجل؟ كان علي فقط أن أصنع واحدة اليوم واخترت القيام بذلك يدويًا بشكل مؤلم.

للسياق ، مشروعي هو 7.7. يقوم مستهلك رئيسي لمشروعنا حاليًا بإصدار إصدار 7.5 ، ووجد مشكلة وتطلب 7.5.1 ، لذلك لم يضطروا إلى إعادة تأكيد الجودة في كل شيء في منتصف الإصدار. ليس بالشكل الأمثل ، لكنه يحدث أحيانًا.

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

من الرائع سماع ذلك! شكرا 🙏

لقد طورنا (أنا و @ 10hendersonm) حلاً لهذا ولكنه تمامًا
متضمن. إنه يستخدم فقط السيارات والإضافات!

لقد أصلحنا 7.2.1 و 8.1.1 و 8.2.2 من مشروعنا باستخدام العلاقات العامة فقط
(حذر جدا).

يمكننا النظر في كيفية مشاركة هذا إذا كان الناس مهتمين؟

في الخميس ، 14 كانون الثاني (يناير) 2021 ، الساعة 7:27 مساءً ، كتب Matt Felten [email protected] :

من الرائع سماع ذلك! شكرا 🙏

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/intuit/auto/issues/1054#issuecomment-760583830 ، أو
إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AACI3Q6RKDONYJVH6UWUPFLSZ6KZNANCNFSM4LFJ4ULQ
.

انا سوف اكون مثارا للغايه!

اهلا جميعا! أنا مهتم بالمساهمة في هذا. اقتراحي هو كما يلي:

1. بشكل عام ، سيحاول auto احترام أي فرع من فروع version-* . على سبيل المثال ، سيؤدي دمج التصحيح من أي فرع إلى version-1.1.4 إلى إنشاء إصدار من الإصدار 1.1.5 . إذا تم إنشاء هذا الإصدار بالفعل ، فسيفشل إما إصدار NPM أو Git Tag ، ولكن هذه حالة خطأ عادية ومتوقعة
2. يمكننا تحديث versionBranches لقبول "major" | "minor" | "patch" ، والذي سينشئ فروع إصلاح عاجل محتملة بناءً على ما تحدده. يسمح لك هذا باختيار المفاضلة بين الحاجة يدويًا إلى إنشاء فرع version-* والانتهاء من وجود عدد كبير جدًا من الفروع للمحافظة عليه عندما لا تحتاج إلى إصلاحات

أفكار؟

لكن هذه حالة خطأ طبيعية ومتوقعة \

ما زلت أتوقع أن ينشئ هذا نوعًا من الإصدار. لقد مررت مؤخرًا بحالة أردت فيها إصدار إصلاح عاجل من التزام محدد بعدم سحب أي شيء آخر. أعتقد أنه في هذه الحالة يمكننا استخدام جزء البناء من semver من المحادثة أعلاه.

يمكننا تحديث versionBranches لقبول "الكبرى" | "طفيفة" | "رقعة قماشية"

يمكن أن يكون التكوين الحالي إما true أو سلسلة لبادئة الفروع الرئيسية. أعتقد أن التكوين الجديد يجب أن يبدو مثل

{
  "versionBranches": {
      "branchPrefix": "version-",
      "types": ["major", "minor"] // defaults to just major   
   }
}

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

lshadler نحتاج كثيرًا إلى الاقتران بهذا الأمر لبعض الوقت للعثور على أفضل نهج.

bmuenzenmeyer هل يمكنك إعطاء نظرة عامة على

كلما فكرت في التنفيذ ، أعتقد أن هذا سيتطلب الإصدار 11 والمزيد من السياق المضاف إلى الإصدار ونشر الأوامر.

بالنسبة للإصدارات القديمة ، نحتاج إلى أحدث خط أنابيب لتشغيله باستخدام سجل التغيير ، و afterVersion ، وكلها أو خطاطيفها التي تم استدعاؤها أثناء الإصدار الأخير.

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

يمكن أن يظل سير عمل Canary كما هو نظرًا لأنه لا يتم الالتزام بأي شيء لكناري ويمكنك بالفعل النقر فقط على خطاف الكناري للقيام بمزيد من الأشياء.

مرحباً بالجميع ، مع جنون هذا العام الماضي ، للأسف هذه المشكلة قد ابتعدت عني.

فيما يتعلق بالمناهج المختلفة ، أعتقد أنه قد يساعد في النظر في حالات الاستخدام المختلفة التي تم حلها من أجل هذه الميزات. في رأيي ، يمكنني رؤية حالتين من حالات الاستخدام:

• (1) دعم طويل الأجل لفرع قديم (على سبيل المثال: إصدار رئيسي قديم)
• (2) دعم قصير المدى لإصدار معين (مثل: الإصلاح العاجل)

بناءً على هذه المحادثة ، أعتقد أنه من المنطقي أن يكون لديك مناهج مميزة لكل حالة من حالات الاستخدام هذه.

(1) للحصول على دعم طويل الأجل لفرع / مسار تحرير ، أعتقد أن versionBranches يجب أن يكون قادرًا على حل المشكلة. إذا كانت هناك رغبة في توسيع نطاق هذا السلوك ليشمل الإصدارات الثانوية (كما ذكر البعض أعلاه) ، فقد يكون ذلك تحسينًا لهذه الوظيفة.

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

تحرير _ (لحالة الاستخدام قصيرة المدى ، من المحتمل أن يتم تمديد versionBranches config للسماح بمعامل / تبديل / علامة تشير إلى ما إذا كان سيتم احترام تسميات semver لفروع version- أو استخدامها دائمًا جزء البناء من semver وتجاهل أي تسميات لتلك الفروع) _

هل هناك حالات استخدام أخرى غير هاتين 2 يجب أخذها في الاعتبار؟

هل ينبغي النظر في مناهج مختلفة لحالات الاستخدام المختلفة؟

(أيضًا ، لا يزال بإمكاني المساعدة في بعض هذه التغييرات ، لكن بالتأكيد لا أرغب في منع أي شخص آخر من إجراء التغييرات لهذا الغرض)

أيضًا ، فكرة عرضية للأنماط المتفرعة:

سيقوم auto بإنشاء علامة git (إصدار) للإصدارات. هذا يعني أنه تم دفع git ref الصالحة إلى github. بالنسبة لحالة استخدام الدعم قصير المدى (على سبيل المثال: فرع قصير الأجل / فرع الإصلاح العاجل) ، فهذا يعني أنه يمكن للمستخدم حذف الفرع قصير الأجل بعد دفع علامة التحرير / git.

• إعطاء فرع رئيسي بالعلامات التالية
  <ul> <li>(tag: v1.3.0) (master)<br /> | </li> <li>(tag: v1.2.3)<br />

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

كنت ألعب مؤخرًا مع الكود للاستفادة من جزء البناء من semver لإنشاء البنيات. أثناء قيامي بذلك ، صادفت حالة الاستخدام حيث لم يكن أحدث إصدار من github بالضرورة هو أحدث / أعلى إصدار دلالي.

على سبيل المثال ، في المثال المذكور هنا: https://github.com/intuit/auto/issues/1054#issuecomment -780286683 ، سيظهر أحدث إصدار من github كـ v1.2.3+1 نظرًا لأنه تم إنشاؤه مؤقتًا بعد أعلى الإصدار الدلالي للإصدار: v1.3.0 .

نظرًا لوجود عدد غير قليل من الأماكن في الكود المرجعي getLatestRelease ، فقد يؤدي ذلك إلى سلوكيات متنوعة إذا لم يقم خط الأنابيب بتعيين المعلمة from بشكل صريح. بمعنى آخر:

• ما هو مدرج في ملاحظات الإصدار
• ما تم حساب الإصدار السابق عليه
• من المحتمل أن تتعطل الوظائف إذا كان أحدث إصدار من github لا يمكن الوصول إليه من HEAD الالتزام

لم أختبر ، لكنني أعتقد أن هذه الأنواع من السيناريوهات يمكن أيضًا الوصول إليها من خلال السلوك الحالي versionBranches . أعتقد أن هذا مرتبط بالتعليق المتعلق بالتدفقات التي يجب أن تنشئ علامات git / إصدارات github:

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

من حيث الحل ، يمكن حل هذه المشكلة على الأرجح بشكل مستقل عن إعادة بناء الخطاف عن طريق استبدال getLatestRelease logic بأيٍّ من:

• (1) قم بإحضار إصدارات جيثب باستخدام listReleases ثم قم بالفرز للعثور على إصدار الإصدار الأعلى (لا يوجد إصدار أولي أو أجزاء بناء) يمكن الوصول إليه
• (2) أو جلب علامات git ثم الفرز للعثور على الإصدار الأعلى من الإصدار (لا يوجد إصدار أولي أو أجزاء بناء) يمكن الوصول إليها

سيكون الاختلاف هنا هو ما إذا كان auto إصدارات Github أو علامات git كمصدر للحقيقة ، وهو مرتبط بالمناقشة https://github.com/intuit/auto/discussions/1867#discussioncomment -684192.

كنت أميل في البداية نحو (2) ، مثل

• (أ) نحن في النهاية بعد git ref (tag) وليس العناصر الأخرى لإصدار github
• (ب) سيقلل من عدد مكالمات الشبكة

hipstersmoothie،
إذا احتجنا إلى تعديل منطق getLatestRelease ، فما هي أفكارك حول (1) استخدام إصدارات github مقابل (2) استخدام علامات git مقابل (3) شيء آخر؟

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