Temurin-build: Kejelasan di mana parameter config harus didefinisikan

Dibuat pada 8 Okt 2020 · 6Komentar · Sumber: adoptium/temurin-build

Keluar dari diskusi di https://github.com/AdoptOpenJDK/openjdk-build/pull/2125#pullrequestreview -504661752

Lokasi untuk perubahan parameter konfigurasi adalah sesuatu yang perlu kita berikan panduan. Saya menemukannya saat menyusun bagian FAQ ini karena semuanya saat ini berada di salah satu dari tiga tempat. Yang akan digunakan tergantung pada siapa yang kita ingin terpengaruh dan bagi saya pengetahuan kita telah menghindari kejelasan tentang di mana perubahan harus dilakukan yang telah menyebabkan kebingungan di masa lalu. Ringkasan cepat:

| Lokasi | Dampak |
| --- | --- |
| file keren (sesuai PR ini) | Hanya jika dijalankan melalui jaringan pipa jenkins kami |
| skrip konfigurasi khusus platform | Mereka yang menggunakan build-farm / make-adopt-build-farm.sh (termasuk pipeline kami) - harus merupakan barang khusus untuk mesin kami |
| build.sh | Siapa pun (termasuk pengguna akhir) yang menjalankan makejdk-any-platform.sh |

Jadi itu tergantung apa yang kita inginkan dari baris terakhir itu. Jika itu untuk memungkinkan pengguna untuk mereplikasi adopsi build dengan opsi konfigurasi yang sama sejauh mungkin, maka saya pikir itu harus dalam build.sh tetapi jika kita ingin menjadi opsional bagi pengguna yang membangunnya sendiri maka pipeline jenkins bukanlah pilihan yang buruk. Tetapi kami harus benar-benar menjelaskan kepada orang baru tentang proyek di mana perubahan harus dilakukan misalnya melalui pembaruan ke FAQ.

Kita harus membahas kapan harus menggunakan setiap jenis, mengutip contoh kapan hal-hal harus ditambahkan di masing-masing dari tiga tempat di atas.

Saya akan menyarankan:

Skrip platform ini memengaruhi variabel lingkungan untuk bulid, dan termasuk parameter config untuk mengganti penggunaan memori untuk mesin build khusus kami. Saat ini kami memiliki hal-hal seperti CUDA dan OpenSSL enablement untuk OpenJ9 di sana - mereka dapat dipindahkan ke build.sh adalah kami ingin memiliki spesifikasi VM di sana (Menempatkannya ke dalam groovy akan menghasilkan lebih banyak pengeditan jika diubah).
Skrip groovy saat ini memiliki hal-hal seperti dtrace dan opsi openJ9 lainnya seperti JITserver di sana (sejujurnya saya tidak pernah suka meletakkannya di sini) meskipun argumen yang mendukungnya adalah bahwa ini adalah cara yang bersih untuk menambahkan hal-hal spesifik ke versi java atau VM, namun definisinya agak buram jika Anda tidak menggunakan jenkins. Mungkin kita harus menyimpan ini untuk hal-hal khusus jenkins seperti suite pengujian mana yang akan dijalankan secara default dan mungkin opsi untuk membedakan heap build normal dan besar dan menghapus yang lainnya?
build.sh menetapkan hal-hal seperti informasi vendor kami, dll. yang menunjukkan siapa yang membuatnya, dan melaporkan bug serta tanda terpisah untuk build GA. Kami memiliki hal-hal seperti freetype alsa , dan jalur dev X11 ditentukan di sana (mungkin mereka harus ada di skrip platform). Saya akan menyarankan bahwa untuk dampak maksimum jika kita ingin adoptopenjdk secara konsisten dibangun dengan cara tertentu sehingga pengembang dapat mereplikasi sebagian besar opsi konfigurasi default kita yang memengaruhi bagaimana OpenJDK dibangun harus ada di sini (atau salah satu skrip yang disebut form it)

Memahami tempat untuk membuat perubahan pada skrip build secara keseluruhan juga merupakan bagian dari https://github.com/AdoptOpenJDK/openjdk-build/issues/957 tetapi saya membuat ini untuk sedikit membatasi ruang lingkup agar masalah penting ini diklarifikasi

documentation enhancement help wanted

Sumber

sxa

👍1

Semua 6 komentar

Kami juga memiliki masalah yang terbuka untuk membagi file kami di antara repo, saya pikir itu akan membantu ...

karianna pada 8 Okt 2020

👍1

Saya tidak terlalu yakin dengan memecah-belah seperti itu, tetapi terlepas dari itu kita perlu memutuskan di mana seharusnya berada, dan mendokumentasikannya akan menjadi langkah pertama yang sepele (Yah, memutuskan akan menjadi langkah pertama yang baik, kemudian kita dapat mendokumentasikannya)

sxa pada 9 Okt 2020

Opsi konfigurasi yang ditetapkan di skrip build.sh dan groovy harus digabungkan ke dalam skrip platform, dan menurut saya skrip tersebut harus dipindahkan ke bawah makejdk-any-platform.sh. Meneruskan satu flag (misalnya --use-default-config-args) dapat memicunya, atau menghilangkan flag itu akan menonaktifkannya (jadi skrip hanya menggunakan argumen konfigurasi pengguna).

Hal-hal ini merupakan ide yang bagus karena:

Hanya akan ada satu lokasi di mana argumen config diatur, membuatnya lebih mudah untuk menemukan dan mengubahnya.
Memindahkan skrip platform di bawah makejdk-any-platform.sh berarti bahwa build buruh pelabuhan yang menggunakan gambar buruh pelabuhan hanya perlu mengkloning satu repo (setelah kita selesai membagi repo build).
Pengguna dapat meluncurkan makejdk-any-platform.sh tanpa harus menyetel argumen konfigurasi apa pun, dan yakinlah bahwa konfigurasi build akan memiliki semua opsi yang diperlukan, dengan asumsi mereka menggunakan salah satu file buruh pelabuhan kami untuk membangunnya.
Kita dapat menyetel versi "rentang" untuk setiap argumen konfigurasi, daripada menyalin file konfigurasi yang sama untuk setiap rilis. Ini berarti lebih sedikit file, lebih sedikit duplikasi kode, dan juga mengurangi jumlah kesalahan saat kita mempersiapkan versi OpenJDK yang baru.

adamfarley pada 4 Des 2020

Ketika saya mencoba mengimplementasikan tindakan build-jdk, saya mulai dari readme dan menggunakan makejdk-any-platform.sh untuk membangun jdk, yang berarti konfigurasi-platform-spesifik tidak terlihat.

Saya bertanya-tanya apakah kita dapat memindahkan file di bawah konfigurasi-platform-spesifik ke tingkat yang sama dari build.sh jadi jenkins, tindakan git-hub, pengguna untuk membangun jdk secara asli, dll., Apa pun lingkungan sistem build itu, juga dapat menggunakan saya t? Konfigurasi khusus platform tersebut adalah khusus platform, bukan khusus jenkins, saya kira.

Skrip Groovy adalah skrip build khusus jenkins, yang akan dibagi menjadi repo terpisah https://github.com/AdoptOpenJDK/openjdk-build/issues/1108?

sophia-guo pada 7 Des 2020

👍1

Parameter Groovy jenkins telah diklarifikasi di README.md dari repo jenkins melalui https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/67. Pengguna sekarang harus memiliki pemahaman yang baik tentang parameter apa yang tersedia dan di mana yang baru harus dibuat. # 2506 menyesuaikan FAQ di sisi proyek ini.

Sekarang saya bermaksud menyesuaikan FAQ repo ini (openjdk-build) untuk mengklarifikasi bahwa parameter spesifik jenkins harus diselesaikan di https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/67 di mana parameter berbasis mesin dan parameter global harus dilakukan di file platform dan build.sh masing-masing

M-Davies pada 3 Mar 2021

https://github.com/AdoptOpenJDK/openjdk-build/pull/2518 telah digabungkan, menyelesaikan perubahan dokumen. Ini harus menangani siapa saja yang ingin menambahkan parameter baru ke proyek. Bagian terakhir dari masalah ini adalah melihat parameter dan lokasi yang ada, mengevaluasi masing-masing untuk kesesuaiannya di lokasinya saat ini dan, berdasarkan evaluasi ini, jika perlu dipindahkan ke lokasi lain. Namun ini akan menjadi banyak pekerjaan dan saya tidak mungkin memiliki waktu untuk menyelesaikan tugas ini dalam jangka waktu yang wajar mengingat beberapa tugas dengan prioritas lebih tinggi yang saya tangani saat ini.

Karena itu, saya akan menghapus tugas saya dan menyerahkan kepada orang lain untuk mengevaluasi kembali parameter yang ada.

M-Davies pada 10 Mar 2021

👍1

Apakah halaman ini membantu?

0 / 5 - 0 peringkat