Temurin-build: توضيح مكان تحديد معلمات التكوين

تم إنشاؤها على ٨ أكتوبر ٢٠٢٠ · 6تعليقات · مصدر: adoptium/temurin-build

خرج من المناقشة في https://github.com/AdoptOpenJDK/openjdk-build/pull/2125#pullrequestreview -504661752

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

| الموقع | تأثير |
| --- | --- |
| ملفات groovy (حسب هذا PR) | فقط عندما تمر عبر خطوط أنابيب جنكينز الخاصة بنا |
| البرامج النصية للتكوينات الخاصة بالمنصة | أولئك الذين يستخدمون build-farm / make-adopt-build-farm.sh (inc. خطوط الأنابيب الخاصة بنا) - يجب أن يكونوا أشياء خاصة
| build.sh | أي شخص (بما في ذلك المستخدمين النهائيين) يقوم بتشغيل makejdk-any-platform.sh |

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

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

أود أن أقترح:

نصوص النظام الأساسي عندما تؤثر على متغيرات البيئة للمباني ، بما في ذلك معلمات التكوين لتجاوز استخدام الذاكرة لآلات البناء الخاصة بنا. لدينا حاليًا أشياء مثل تمكين CUDA و OpenSSL لـ OpenJ9 هناك - يمكن نقلها إلى build.sh هل نريد أن يكون لدينا خصائص VM هناك (وضعها في groovy سيؤدي إلى المزيد من التحرير إذا تغيروا).
تحتوي البرامج النصية الرائعة حاليًا على أشياء مثل dtrace وخيارات openJ9 الأخرى مثل JITserver هناك (لم أكن أبدًا معجبًا بوضعها هنا لأكون صادقًا) على الرغم من أن الحجة المؤيدة لها هي أنها طريقة نظيفة لإضافة أشياء محددة إلى نسخة جافا أو VM ، لكن التعريفات غير شفافة إلى حد ما إذا كنت لا تستخدم الجنكينز. ربما يجب أن نحتفظ بهذه الأشياء للأشياء الخاصة بـ jenkins مثل مجموعات الاختبار التي يتم تشغيلها افتراضيًا وربما الخيارات للتمييز بين عمليات إنشاء الكومة العادية والكبيرة واستبعاد كل شيء آخر؟
يحدد build.sh أشياء مثل معلومات البائع وما إلى ذلك ، مما يشير إلى من قام ببنائها ، وأين يبلغ عن الأخطاء بالإضافة إلى العلامات المنفصلة لبناء GA. لدينا أشياء مثل freetype alsa ومسارات تطوير X11 محددة هناك (ربما يجب أن تكون في البرامج النصية للنظام الأساسي). أود أن أقترح أنه لتحقيق أقصى قدر من التأثير إذا أردنا أن يتم بناء Openjdk باستمرار بطريقة معينة بحيث يمكن للمطورين تكرار معظم خيارات التكوين الافتراضية التي تؤثر على كيفية إنشاء OpenJDK ، يجب أن تكون هنا (أو أحد البرامج النصية التي تسمى Form it)

يعد فهم مكان إجراء تغييرات على البرامج النصية للبناء بشكل عام جزءًا من https://github.com/AdoptOpenJDK/openjdk-build/issues/957 ولكني أقوم بإنشاء هذا للحد من النطاق قليلاً لتوضيح هذه المشكلة المهمة

documentation enhancement help wanted

مصدر

sxa

👍1

ال 6 كومينتر

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

karianna في ٨ أكتوبر ٢٠٢٠

👍1

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

sxa في ٩ أكتوبر ٢٠٢٠

يجب دمج خيارات التكوين التي تم تعيينها في كل من البرامج النصية build.sh و groovy في البرامج النصية للنظام الأساسي ، وأعتقد أنه يجب نقل البرامج النصية بعد ذلك ضمن makejdk-any-platform.sh. يمكن أن يؤدي تمرير علامة واحدة (على سبيل المثال --use-default-config-args) إلى تشغيلها ، أو يؤدي حذف هذه العلامة إلى تعطيلها (لذا لا تستخدم البرامج النصية سوى وسائط التكوين الخاصة بالمستخدم).

هذه الأشياء فكرة جيدة للأسباب التالية:

سيكون هناك موقع واحد فقط حيث يتم تعيين وسيطات التكوين ، مما يسهل العثور عليها وتغييرها.
نقل نصوص النظام الأساسي تحت makejdk-any-platform.sh يعني أن بناء عامل ميناء باستخدام صور عامل الإرساء يجب أن يقوم فقط باستنساخ الريبو الواحد (بعد أن ننتهي من تقسيم إعادة البناء).
يمكن للمستخدم تشغيل makejdk-any-platform.sh دون الحاجة إلى تعيين أي وسيطات تكوين ، وتأكد من أن تكوين البنية سيحتوي على جميع الخيارات التي يحتاجها ، بافتراض أنه يستخدم أحد ملفات عامل الإرساء لدينا للبناء فيه.
يمكننا تعيين "نطاقات" الإصدار لكل وسيطة تكوين ، بدلاً من نسخ ملفات التكوين نفسها لكل إصدار. هذا يعني عددًا أقل من الملفات ، وتكرارًا أقل للكود ، كما يقلل من عدد الأشياء التي يمكن أن تسوء عندما نستعد لإصدارات OpenJDK الجديدة.

adamfarley في ٤ ديسمبر ٢٠٢٠

عندما حاولت تنفيذ إجراء build-jdk ، بدأت من الملف التمهيدي واستخدمت makejdk-any-platform.sh لبناء jdk ، مما يعني أن التكوينات الخاصة بالنظام الأساسي غير مرئية.

تساءلت عما إذا كان بإمكاننا نقل الملفات ضمن تكوينات خاصة بالنظام الأساسي لتكون بنفس مستوى build.sh ، لذا يمكن أيضًا استخدام jenkins ، وإجراءات git-hub ، والمستخدمين لإنشاء jdk محليًا ، وما إلى ذلك ، بغض النظر عن بيئات نظام البناء ، هو - هي؟ هذه التكوينات الخاصة بالمنصة هي منصة خاصة ، وليست خاصة بـ jenkins ، على ما أعتقد.

نصوص Groovy هي نصوص بناء مخصصة لـ jenkins ، والتي سيتم تقسيمها إلى الريبو المنفصل https://github.com/AdoptOpenJDK/openjdk-build/issues/1108؟

sophia-guo في ٧ ديسمبر ٢٠٢٠

👍1

تم توضيح معلمات Groovy jenkins في README.md الخاص بـ jenkins repo عبر https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/67. يجب أن يتمتع المستخدمون الآن بإدراك جيد للنطاق فيما يتعلق بالمعلمات المتاحة وأين يجب إنشاء معلمات جديدة. # 2506 يعدل التعليمات في هذا الجانب من المشروع.

أعتزم الآن تعديل الأسئلة الشائعة لهذا الريبو (openjdk-build) لتوضيح أن معلمات jenkins المحددة يجب أن تتم على https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/67 حيث المعلمات القائمة على الآلة والمعلمات العامة يجب أن تتم في ملفات النظام الأساسي و build.sh على التوالي

M-Davies في ٣ مارس ٢٠٢١

تم دمج https://github.com/AdoptOpenJDK/openjdk-build/pull/2518 ، وإكمال تغييرات المستند. يجب أن يتعامل هذا مع أي شخص يريد إضافة معلمات جديدة إلى المشروع. سيكون الجزء الأخير من هذه المشكلة هو النظر في المعلمات والمواقع الموجودة لدينا ، وتقييم كل واحدة من حيث ملاءمتها في موقعها الحالي ، وبناءً على هذا التقييم ، ما إذا كانت بحاجة إلى نقلها إلى موقع آخر. سيكون هذا كثيرًا من العمل ولكن من غير المحتمل أن يكون لدي الوقت لإكمال هذه المهمة في فترة زمنية معقولة بالنظر إلى العديد من المهام ذات الأولوية الأعلى التي أتعامل معها في الوقت الحالي.

على هذا النحو ، سأزيل مهمتي وأرجئ لشخص آخر لإعادة تقييم المعلمات الحالية.

M-Davies في ١٠ مارس ٢٠٢١

👍1

هل كانت هذه الصفحة مفيدة؟

0 / 5 - 0 التقييمات