Auto: إزالة متطلبات البرنامج المساعد maven-release

أنا أتفق تماما!

ربما تكون معظم نقاطك بالمعلومات التي أحصل عليها من pom.xml مرتبطة بسوء فهمي لهذه الحقول. أي تغييرات هنا هي أكثر من موضع ترحيب.

أنا جميعًا مع أي تغييرات عاجلة يتعين علينا القيام بها. يمكننا على الأرجح إجراء بعض تغييرات التكسير الأصغر المفصلة في # 1156

يبدو أن نقطتي حول <scm/> و <developers/> غير صحيحة. يسحب المكون الإضافي npm تلك من package.json . هل هذا يعني أنهم _يجب_ أن يكونوا موجودين في pom.xml ؟

إذا كانت هذه هي الحقول المكافئة pom للحقول npm repository و author إذن نعم.

تم تعيين المؤلف عبر قسم من pom.xml ، مما يعني أن الشخص الذي يقوم بتنفيذ الالتزام قد لا يكون هو نفسه المؤلف المحدد. لا توجد محاولة لربط مؤلف git الالتزام بامتداد معلومة.

هذا صحيح بالنسبة للمكوِّن الإضافي npm أيضًا. لن يتجاوز auto محليا تكوين git الخاص بك ، ولكن في بيئة CI ، قد يتعين عليك تعيين author للالتزام`.

يتم تعيين معلومات المالك وإعادة الشراء عبر ملف ، والذي قد يكون مختلفًا عن المستودع الفعلي ومالك النسخة الحالية.

هل سيكون هذا مختلفا؟ في عالم npm ، يشير الحقل repository عادةً إلى رمز الحزمة. من الناحية العملية ، لا يقوم المرء عادةً بتشغيل auto على fork ، وإذا كان الأمر كذلك ، فآمل أن يقوموا بتحديث الحقل repository إلى مفترقهم

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

حاليًا ، سيخطئ المكون الإضافي إذا لم يعثر على القسمين <scm/> و <developers/> في pom.xml .

آه نعم هذا بالتأكيد خطأ. لا ينبغي أن تلقي أخطاء https://github.com/intuit/auto/blob/master/plugins/npm/src/index.ts#L504

هل هناك طريقة للحصول على الإصدار NUMBER من auto بطريقة يمكن قراءتها آليًا؟ لقد فوجئت بأن الأمر auto version يُنتج TYPE لنتوء الإصدار ، وليس الرقم.

يمكنك استخدام --quiet وسيطبع الإصدار الذي أنتجه الأمر فقط. أو قم بإقرانه بـ --dry-run ويمكنك معرفة الإصدار الذي سيتم نشره بعد ذلك.

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

أستطيع أن أرى ذلك. من الأفضل ترك ذلك للمتصل لمعرفة الإصدار الذي يبحث عنه.

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

لقد وجدت طريقتين لاستخدام المكون الإضافي maven-release-release اللذان يمكن استخدامهما لمنع المكون الإضافي المخضرم من تعديل المستودع خلال release:prepare ، وسوف نقوم باختبارهما في وقت لاحق اليوم.

hipstersmoothie لدي سؤال حول سلوك الخطافات getAuthor ، getRepo ، إلخ. - RE: التعليق حول https://github.com/intuit/auto/issues/1260#issuecomment - 634280655 ، أنا أنظر إلى الاختبارات ويبدو أنها تتعارض مع ذلك.

مثال:
https://github.com/intuit/auto/blob/47d3b54ef1a7af990fe0ca898e747dd833fde3b1/plugins/maven/__tests__/maven.test.ts#L95

لذلك ، عندما أعيد undefined AuthorInformation لا يظهر أي خطأ.

أي اقتراحات حول ما قد أفعله خطأ ، أو ما إذا كان يجب علي إعادة تقديم throw للتعامل مع الخطاف الخاص بي؟

هذا خطأ بالتأكيد بالنظر إلى كيفية عمل جميع المكونات الإضافية الأخرى. العودة غير المحددة هي الطريقة الصحيحة. بهذه الطريقة ، يمكن أن يعود core إلى المستخدم الذي تمت تهيئته محليًا git إذا لزم الأمر

مسكتك - هذا ما كنت أحسبه ، لذلك قمت بتعديل الاختبارات للتأكد من أن الخطافات الفاشلة ترجع undefined .

يبدو أن كلاً من المكوّنات الإضافية gradle و cocoapods تتسبب في أخطاء إذا لم يتمكنوا من العثور على إصدار. لقد قمت بإنشاء خطأ للمكون الإضافي gradle - هل تريد آخر لـ cocoapods؟

فقط اترك ليس في هذه القضية. شكرا للقبض!

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

    test("should get author from pom.xml", async () => {
      mockRead(`
        <project
          xmlns="http://maven.apache.org/POM/4.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
          <developers>
            <developer>
              <name>Andrew Lisowski</name>
              <email>[email protected]</email>
            </developer>
          </developers>
        </project>
      `);

      await hooks.beforeRun.promise({} as any);

      expect(await hooks.getAuthor.promise()).toStrictEqual(
        expect.objectContaining({
          email: "[email protected]",
          name: "Andrew Lisowski",
        })
      );
    });

ما يحدث هو أن الاختبار يتم الوصول إلى الخطاف getAuthor قبل تشغيل الخطاف beforeRun . لقد بحثت في كود آخر يختبر هذا (gradle ، s3) ، ولم يحالفني الحظ.

في الأساس ، أحتاج إلى طريقة لتنفيذ الخطاف beforeRun بشكل حاسم ولا يمكنني معرفة كيفية القيام بذلك.

دفع فرع ويمكنني التحقق من ذلك

hipstersmoothie ها هو الفرع: https://github.com/terradatum/auto/tree/remove-maven-release-plugin-requirement

لقد علقت على الكود الذي من شأنه أن يدفع تغييراتي إلى الريبو المركزي حتى أتمكن من اختبار الكود في مشروع حقيقي دون تلويث السجل البعيد.

أي مساعدة يمكن أن تقدمها لي في هذا موضع تقدير كبير - أود أن أكون قادرًا على استخدام الاختبارات للتحقق من مدى قدرتي على تعديل ملفات pom.xml ، بدلاً من اللجوء إلى طريقة المدرسة القديمة المتمثلة في "تشغيل الكود مقابل الملفات الحقيقية ، تحقق من الملفات الحقيقية ، قم بتشغيل git reset --hard HEAD~1 للتخلص من التغييرات ، اشطفها وكررها. "

أيضًا ، اضطررت إلى إجراء بعض التغييرات على package.json المحلي التي كانت غير متوافقة مع الجذر package.json أجل تشغيل اختبارات الدعابة في IntelliJ - هل هناك أي إرشادات يمكنك إعطائي إياها بشأن ذلك ، أم يجب أن "تعمل فقط" خارج منطقة الجزاء؟

على وجه التحديد ، عندما تكون في دليل البرنامج المساعد maven وتشغيل npm test - ينتهي الأمر بتشغيل جميع الاختبارات لأن "test": "jest --maxWorkers=2 --config ../../package.json" .

وإذا حاولت استخدام IntelliJ Test Runner من المحرر ، فسأحصل على:

  ● Test suite failed to run

    SyntaxError: /home/rbellamy/Development/Terradatum/auto/plugins/maven/__tests__/maven.test.ts: Unexpected token, expected "," (15:24)

      13 | }));
      14 | 
    > 15 | const mockRead = (result: string) =>
         |                         ^
      16 |   jest
      17 |     .spyOn(fs, "readFile")
      18 |     // @ts-ignore

      at Parser._raise (../../node_modules/@babel/parser/src/parser/location.js:241:45)
      at Parser._raise [as raiseWithData] (../../node_modules/@babel/parser/src/parser/location.js:236:17)
      at Parser.raiseWithData [as raise] (../../node_modules/@babel/parser/src/parser/location.js:220:17)
      at Parser.raise [as unexpected] (../../node_modules/@babel/parser/src/parser/util.js:149:16)
      at Parser.unexpected [as expect] (../../node_modules/@babel/parser/src/parser/util.js:129:28)
      at Parser.expect [as parseParenAndDistinguishExpression] (../../node_modules/@babel/parser/src/parser/expression.js:1293:14)
      at Parser.parseParenAndDistinguishExpression [as parseExprAtom] (../../node_modules/@babel/parser/src/parser/expression.js:1029:21)
      at Parser.parseExprAtom [as parseExprSubscripts] (../../node_modules/@babel/parser/src/parser/expression.js:539:23)
      at Parser.parseExprSubscripts [as parseMaybeUnary] (../../node_modules/@babel/parser/src/parser/expression.js:519:21)
      at Parser.parseMaybeUnary [as parseExprOps] (../../node_modules/@babel/parser/src/parser/expression.js:311:23)

يمكنني حل مشكلتي مع IntelliJ عن طريق إضافة ملف jest.config.ts :

module.exports = {
  clearMocks: true,
  moduleFileExtensions: ['js', 'ts'],
  testEnvironment: 'node',
  testMatch: ['**/*.test.ts'],
  testRunner: 'jest-circus/runner',
  transform: {
    '^.+\\.ts$': 'ts-jest'
  },
  verbose: true
}

ثم إضافة jest-circus إلى ملفات الجذر أو الملف المخضرم package.json .

لاحظت للتو أن xml2js لن يقوم بالمهمة لأنه سيزيل بصمت جميع تعليقات XML أثناء XML => JSON => ترجمة XML. كنت أحاول أن أجعله يعمل ، وهو مثل قلع الأسنان. ليس هناك ما يضمن أن XML سيبدو أي شيء مثل الأصل عند الانتقال عبر تحويلات xml2js ، وهذا أمر يكسر الصفقات.

لإجراء اختبارات لمكوِّن إضافي واحد فقط ، أقوم بتشغيله من الجذر.

yarn test plugins/maven

ثم يطرح هذا السؤال عما إذا كان يمكنك بسهولة عرض جميع التغييرات التي ستجريها أو القطع الأثرية التي ستبنيها دون إجراء بعض التغييرات أم لا.

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

بالنسبة للمكونات الإضافية التي لا تحتوي على محلل لملف التكوين (على سبيل المثال: ruby) ، يستخدم auto الغالب regex لتحديث الملف.

هل حصلت على فرصة للنظر في مشكلة beforeRun ؟ لدي حل بديل ، لكنه يبدو حقًا متسللًا ...

لا أحب حقًا فكرة استخدام regex مع XML - فهي عرضة للخطأ وهشة. ومع ذلك ، يبدو أيضًا أنه معقد للغاية محاولة استخدام DOMParser أو XMLSerializer فقط لتعديل الإصدار ، وهذا هو السبب في أنني كنت أحاول العمل مع xml2js في المقام الأول.

أنظر إلى هذا الآن!

https://github.com/terradatum/auto/blob/remove-maven-release-plugin-requirement/plugins/maven/src/index.ts#L127

المشكلة هي أنك تقوم بنقرة "متزامنة" وتقوم بعمل غير متزامن بداخلها

غير هذا

auto.hooks.beforeRun.tap(this.name, async () => {

الى هذا

auto.hooks.beforeRun.tapPromise(this.name, async () => {

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

من فضلك افعل ... دعني اجعلك مساهما.

تفضل!

فقط دفعت. قم بإجراء الاختبارات وفشل اثنان فقط الآن. الخطاف beforeRun يعمل كما هو متوقع.

hipstersmoothie لا أرى الالتزام بـ terradatum / auto repo؟

الآن لقد دفعت بالفعل

هل سيتسبب ذلك في حدوث تغيير مفاجئ لأي مكون إضافي يستخدم حاليًا النقر المتزامن؟

لا. يجب أن تعمل صنابير المزامنة بنفس الطريقة. هذا يضيف فقط القدرة على النقر على الوعد

لقد نجحت في عمل هذا باستخدام regex هش / عرضة للخطأ. ما يقلقني هو أن العنصر <version/> يُستخدم في كل مكان في ملف pom.xml - للنسخة المصطنعة وللتوابعيات والمكونات الإضافية. بعبارة أخرى ، من المرجح جدًا أن يغير regex إصدارًا لا يُفترض به تغييره عن غير قصد.

في محاولة للعمل مع XML DOM (عبر xmldom و xmldom-ts و xml2js و xml2json وما إلى ذلك) ، وجدت نفسي عالقًا في مستنقع ذي أبعاد ملحمية. أنا لا أعتبر نفسي بأي حال من الأحوال خبيرًا في الكتابة أو جافا سكريبت ، لذلك ربما كان هذا هو المكان الذي أقع فيه.

شيئان يركلان مؤخرتي:

1. لا يمكنني معرفة كيفية جعل IntelliJ يدير الاختبارات المخضرمة (واختبارات المخضرم فقط) في وضع التصحيح. في بعض الأحيان يعمل ، وأحيانًا لا يعمل.
2. تحميل ملف pom.xml إلى Document ثم استخدام xpath لتحديد العقد "/ project / version" و "/ project / parent / version".

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

أنا أميل إلى العودة إلى استخدام البرنامج المساعد maven-release-release لسبب بسيط يبعث على السخرية وهو أنه يعالج تحديث ملفات pom.xml بالنسبة لي.

لا يمكنني معرفة كيفية جعل IntelliJ يدير الاختبارات المخضرمة (واختبارات المخضرم فقط) في وضع التصحيح. في بعض الأحيان يعمل ، وأحيانًا لا يعمل.

أنا آسف لأنني لست أكثر من مساعدة هنا. أستخدم VSCode ونادراً ما أقوم بتصحيح الاختبارات. هل يمكنك الجري من الجذر باستخدام yarn test plugins/maven ؟

تحميل pom.xml في مستند ثم استخدام xpath لتحديد العقد "/ project / version" و "/ project / parent / version".

هذا يبدو وكأنه طريقة جيدة. إذا كان هذا يمكن أن يعمل فهذا يبدو جيدًا.

أنا أميل إلى العودة إلى استخدام البرنامج المساعد maven-release-release لسبب بسيط يبعث على السخرية وهو أنه يعالج تحديث ملفات pom.xml بالنسبة لي.

هل هناك أشياء تستند إلى المكونات الإضافية فقط مثل https://stackoverflow.com/questions/5726291/updating-version-numbers-of-modules-in-a-multi-module-maven-project المتاحة لـ maven؟ سيكون الشيء الذي يعتمد على mvn منخفض المستوى مثاليًا.

راجع للشغل شكرا لقضاء الكثير من الوقت على هذا!

شكرا لردود الفعل والدعم. آسف للتشدق (العش) التعليق السابق.

نقطة رائعة حول الإصدارات-maven-plugin - لم أعمل معها من قبل ولم يكن لدي أي فكرة عن وجودها. هذا بالتأكيد سيجعل الأمور أسهل بالنسبة لي ... إنه حل وسط مثالي بين المكون الإضافي maven-release-release ومحاولة إدارة ملفات pom.xml عبر المكون الإضافي التلقائي.

يمكنني الحصول على yarn test plugins/maven للعمل. أنا أيضًا من أشد المعجبين باستخدام مصحح الأخطاء لفحص الأشياء ، بدلاً من console.log الأكثر تقليدية ، لذلك من المحتمل أن أتسبب في حرقة في المعدة أكثر مما أحتاج ...

بعد رحلة طويلة وشاقة ، لدي تقريبًا ما أعتبره حلاً كاملاً ، والذي من شأنه إما تعديل ملفات pom.xml مباشرةً أو استخدام versions-maven-plugin لتعيين الإصدارات.

هناك بعض المحاذير. الكود المستخدم لتعديل pom.xml يعمل مع DOM ، والذي له العواقب التالية:

1. هناك خطأ في معالجة tsconfig.json يتطلب أن يكون "dom" lib قبل "es2017" في "compilerOptions" :

يعمل:

"compilerOptions": [ "dom", "es2017" ]

لا يعمل:

"compilerOptions": [ "es2017", "dom" ]

بدون "الإصلاح" ، يحدث ما يلي:

$ tsc -b tsconfig.dev.json
node_modules/@types/jsdom/index.d.ts:28:40 - error TS2304: Cannot find name 'DocumentFragment'.

28         static fragment(html: string): DocumentFragment;
                                          ~~~~~~~~~~~~~~~~

node_modules/@types/jsdom/index.d.ts:45:28 - error TS2304: Cannot find name 'Node'.

45         nodeLocation(node: Node): ElementLocation | null;
                              ~~~~

node_modules/@types/jsdom/index.d.ts:188:19 - error TS2304: Cannot find name 'HTMLScriptElement'.

188         element?: HTMLScriptElement | HTMLLinkElement | HTMLIFrameElement | HTMLImageElement;
                      ~~~~~~~~~~~~~~~~~

node_modules/@types/jsdom/index.d.ts:188:39 - error TS2304: Cannot find name 'HTMLLinkElement'.

188         element?: HTMLScriptElement | HTMLLinkElement | HTMLIFrameElement | HTMLImageElement;
                                          ~~~~~~~~~~~~~~~
<snip - numerous other errors>

1. تتطلب اختبارات jest testEnvironment: 'jsdom' مقابل 'node' .

بدون "الإصلاح" ، يحدث ما يلي:

$ jest --runInBand plugins/maven
 FAIL  plugins/maven/__tests__/maven.test.ts
  maven
    updatePomVersion
      ✕ should replace the previousVersion with the newVersion (39ms)

  ● maven › updatePomVersion › should replace the previousVersion with the newVersion

    ReferenceError: XPathEvaluator is not defined

      51 | ) => {
      52 |   const pomDom = new jsdom.JSDOM(content, {contentType: "text/xml"}).window.document;
    > 53 |   const evaluator = new XPathEvaluator();
         |                     ^
      54 |   const resolver = evaluator.createNSResolver(pomDom.documentElement);
      55 |   const expression = evaluator.createExpression("/project/version", resolver);
      56 |   const versionNode = expression.evaluate(pomDom.documentElement, XPathResult.FIRST_ORDERED_NODE_TYPE);

      at Object.exports.updatePomVersion (plugins/maven/src/index.ts:53:21)
      at Object.test (plugins/maven/__tests__/maven.test.ts:53:26)

لا يعمل أي من "الإصلاحات" أعلاه عند تعيينها في تكوينات الجذر للمكون الإضافي ، على سبيل المثال لا plugins/maven/tsconfig.json ولا jest config في plugins/maven/package.json . لا يبدو أن إجراء التغييرات على ملفات تكوين الجذر يؤثر سلبًا على الاختبارات أو الوظائف.

هل هذا في فرعك؟ ربما يمكنني إصلاح هذا

ليس بعد ... أتأكد من أن جميع الاختبارات (والجديدة) تمر قبل الدفع. سأتواصل معك عندما يكونون مستعدين لك للمراجعة.

لقد قمت للتو بإعادة تأسيس Master إلى الفرع الخاص بي ، والآن أتلقى العديد من أخطاء الإنشاء.

أولاً ، تم فتح ملف yarn.lock بسبب تعارض الدمج ، لذلك اضطررت إلى حذفه وإعادة بنائه:

error Incorrect integrity when fetching from the cache for "babel-plugin-jest-hoist". Cache has "sha512-u+/W+WAjMlvoocYGTwthAiQSxDcJAyHpQ6oWlHdFZaaN+Rlk8Q7iiwDPg2lN/FyJtAYnKjFxbn7xus4HCFkg5g== sha1-EpyAulx/x1uvOkW5Pi43LVfKJnc=" and remote has "sha512-+AuoehOrjt9irZL7DOt2+4ZaTM6dlu1s5TTS46JBa0/qem4dy7VNW3tMb96qeEqcIh20LD73TVNtmVEeymTG7w==". Run `yarn cache clean` to fix the problem

بمجرد القيام بذلك ، تظهر لي الآن أخطاء @octokit/graphql :

$ tsc -b tsconfig.dev.json
packages/core/src/auto.ts:2018:13 - error TS2571: Object is of type 'unknown'.

2018         if (result?.[`hash_${commit}`]) {
                 ~~~~~~

packages/core/src/auto.ts:2019:27 - error TS2571: Object is of type 'unknown'.

2019           const number = (result[`hash_${commit}`] as ISearchResult).edges[0]
                               ~~~~~~

packages/core/src/release.ts:286:52 - error TS2769: No overload matches this call.
  Overload 1 of 2, '(o: ArrayLike<unknown> | { [s: string]: unknown; }): [string, unknown][]', gave the following error.
    Argument of type 'unknown' is not assignable to parameter of type 'ArrayLike<unknown> | { [s: string]: unknown; }'.
      Type 'unknown' is not assignable to type '{ [s: string]: unknown; }'.
  Overload 2 of 2, '(o: {}): [string, any][]', gave the following error.
    Argument of type 'unknown' is not assignable to parameter of type '{}'.

286       (acc, result) => [...acc, ...(Object.entries(result) as QueryEntry[])],
                                                       ~~~~~~


packages/core/src/__tests__/git.test.ts:209:12 - error TS2571: Object is of type 'unknown'.

209     expect(result!.data).not.toBeUndefined();
               ~~~~~~~


Found 4 errors.

error Command failed with exit code 2.

كنت متفائلًا للغاية أن أتمكن من إنشاء علاقات عامة لهذا - لكنني قلق من أنها ليست جاهزة بعد.

حسنًا ، لقد توصلت إلى ما أحتاج إلى القيام به - لقد قمت للتو بفحص ملف yarn.lock من master ثم أعدت تشغيل yarn clean && yarn install && yarn build && yarn test plugins/maven وأعتقد أنني سأفعل -يذهب.

مذهل! سأراجع هذا اليوم. آسف لم أرد خلال عطلة نهاية الأسبوع!

: صاروخ: تم إصدار الإصدار في v9.40.0 : صاروخ: