permintaan terkait: #2566

Saya sudah mulai mengerjakan ini.
Mempertimbangkan komentar pada #2566, apakah kita mencari --values ​​atau --set (atau keduanya?)

Kasus penggunaan yang bagus dijelaskan dalam masalah yang saya buka ( #3198 ), di mana saya ingin dapat melakukan:

helm package --version 1.2.3 --set image.tag 1.2.3

Dengan cara ini versi bagan dan versi gambar buruh pelabuhan adalah satu dan sama.

Saya baru saja menyelesaikan draf pertama dan memposting PR untuk ini.

@ngeor , @sslavic PR yang saya kirimkan menambahkan opsi --set dan --values, bisakah Anda melihatnya?

Hai @adshmh , terlihat bagus; sayangnya saya tidak tahu Go tapi saya melihat Anda menutupinya dengan kasus uji dan semua, jadi mungkin melakukan apa yang dikatakan :) Terima kasih!

Kapan fitur ini akan tersedia? Di 2.9.0?

3471 melewatkan tenggat waktu untuk 2,9 sehingga akan berada di 2,10.

Membuka kembali ini, karena #3471 perlu mundur.

Apa yang dilakukan ini pada komentar/dll dalam paket arsip? misalnya, apakah mereka ditelanjangi atau dibiarkan saja atau ??

Saat ini saya mencoba melakukan hal yang sama dengan yq tetapi hanya membuang nilai akhir setelah diproses. yaitu, semua komentar, baris kosong untuk organisasi, dll hilang.

3471 menghapus semua komentar, itulah sebabnya kami harus mendukung PR itu. Lihat https://github.com/kubernetes/helm/pull/3471#issuecomment -381779783 untuk info lebih lanjut

Dikembalikan dari 2.10 "feat: tambahkan opsi --set dan --values ​​ke 'paket helm'" https://github.com/helm/helm/commit/7b8aae466761448522acbd3beb2a16ad2283013a

Beberapa berita tentang ini?
Terima kasih

Sama seperti di atas; tidak ada yang mengerjakan tindak lanjut untuk memperbaiki bug di #3471 jadi ini belum diterapkan. Anda dipersilakan untuk melakukan fork Helm dan mengkompilasinya dengan #3471 jika Anda setuju dengan komentar yang dihapus dari file nilai.

Apakah ini dilakukan? Saya mencoba pada versi 2.11.0 dan 2.12.0 sepertinya tidak ada yang memiliki helm package --set...

+1. itu akan sangat membantu kami di CI untuk berhenti memasang dan meningkatkan nilai sebelum pengepakan.

+1

--set-string juga dapat berguna, mengapa tidak mengizinkan semua opsi override yang ada di install/upgrade.
Cukup jalankan kode yang sama yang digunakan untuk mengganti nilai untuk perintah paket, masuk akal bahwa paket tersebut akan memiliki nilai penimpaan - tanda tersebut harus dibagikan seperti halnya dengan install/upgrade.

2.13.1 juga tidak memiliki fitur seperti itu, apakah ada jadwal waktu untuk itu?

Seperti disebutkan sebelumnya, tidak ada yang sedang mengerjakan ini dan tidak ada jadwal kapan perbaikan akan tersedia. Jangan ragu untuk mengambil yang ini. Lihat #3471 untuk ide.

diimplementasikan di Helm 3 . Penutupan!

Melihat kodenya, tampaknya #3471 secara tidak sengaja masuk ke Helm 3, tetapi tidak pernah ditarik keluar seperti yang kami lakukan untuk Helm 2 karena komentar ini: https://github.com/helm/helm/pull/3471#issuecomment -381779783

Saya membuka kembali permintaan fitur ini karena kami menghapus flag --set dan --values ​​di Helm 3 dengan https://github.com/helm/helm/pull/7201. Lagi pula mereka tidak pernah bekerja... Apa pun yang diatur melalui --set atau --values tidak pernah disuntikkan ke dalam paket, dan itu memperkenalkan beberapa regresi fatal dengan helm package , yaitu fakta bahwa itu dilucuti keluar komentar dari values.yaml, yang digunakan beberapa anggota komunitas sebagai dokumentasi.

Mungkin saya salah paham, tetapi saya dengan senang hati menggunakan --set dengan paket untuk menetapkan nilai dan ini bekerja dengan baik dari 3.0.0 hingga 3.0.2, jelas bukan "tidak ada operasi" seperti yang dijelaskan dalam #7201 .

Pipa saya rusak sejak 3.0.3. Ini bekerja di 3.0.2. Mengapa ini tidak dianggap berguna, jika kita memiliki --version dan --app-version. Bagaimana cara kita mengedit gambar dan tag , untuk mencocokkan --app-version? Basah?

Melihat kode lagi, Anda benar @lukaslarson dan @maxhillaert. Namun, ini masih merupakan fitur yang dimaksudkan untuk dikembalikan karena menghapus semua komentar dari file nilai paket. Itu dihapus di Helm 2, tetapi secara tidak sengaja masuk ke Helm 3. Itu tidak pernah dimaksudkan untuk dikirim.

Jika seseorang ingin bekerja untuk menerapkan kembali #3471 yang menyimpan komentar, kami akan dengan senang hati melihat PR.

@bacongobbler Ini merusak beberapa hal untuk kami. Saya tertarik untuk mengerjakan PR, namun tampaknya tidak sepele, jadi saya ingin memeriksa pendekatannya.

Sepertinya gopkg.in/yaml.v3 mendukung penyimpanan komentar saat melakukan perjalanan pulang pergi. Proposal saya adalah membuat Values a yaml Node . Kemudian, saat menggabungkan nilai, jalankan pohon dari keluaran yang diurai daripada peta bersarang. Ini tentu saja kurang ergonomis, tetapi cara terbaik untuk menjaga komentar tetap akurat.

Ini sedikit masalah karena kami menggunakan sigs.k8s.io/yaml di mana-mana yang disematkan ke v2 dari lib yang mendasarinya. Minimal, ini membutuhkan pengenalan sebagai ketergantungan terpisah, yang agak menyebalkan. Tidak yakin apa pendekatan terbaik di sini untuk menghindari menyentuh semua yang berhubungan dengan yaml.

Opsi terbaik tampaknya bermigrasi ke yaml.v3, jadi sepertinya Anda berada di jalur yang benar.

Jika Anda ingin mulai mengerjakan PoC/fork Helm yang menggunakan yaml.v3 alih-alih sig.k8s.io/yaml, itu akan menjadi jalan yang baik. Dengan begitu kita dapat mulai mengevaluasi fungsionalitasnya dibandingkan dengan apa yang ada di master .

Setelah kami menetapkan bahwa yaml.v3 adalah jalur terbaik ke depan, kami dapat mengetahui cara melanjutkan dari sudut pandang SDK.

Apakah itu membantu membuka blokir Anda?

@jmcelwain Apakah Anda aktif mengerjakan ini? Saya akan dengan senang hati mengambil alih ini jika tidak.

@sreya92 Sibuk di tempat kerja. Di sinilah saya tinggalkan: beralih ke yaml.v3 sebagian besar mudah, dengan pengecualian bit ini di sini . Tidak yakin apa pendekatan terbaik untuk menangani ini tanpa sejauh vendor ketergantungan dan memperbaruinya ke v3 di sana.

Sepertinya ada beberapa pekerjaan yang dilakukan untuk memutakhirkan , tetapi tidak ada informasi lain dalam masalah, dll., dan saya tidak repot-repot membuka masalah. Opsi lainnya adalah menjaga kedua dependensi, tetapi itu tampaknya menjijikkan.

Pendapat pribadi saya adalah bahwa ini adalah pemblokir untuk masalah ini, kecuali jika pengelola merasa bahwa membawa dua salinan lib serupa bermanfaat. Tidak yakin apa LoE di sini, tetapi kita mungkin harus bekerja untuk mendapatkan github.com/ghodss/yaml ke v3 dan mendapatkan versi vendor di k8s yang ditingkatkan juga. Itu akan membuat semua ini lebih mudah.

Membuka https://github.com/ghodss/yaml/issues/61 untuk menanyakan tentang kemungkinan jalur peningkatan di sana. Akan menunggu untuk mendengar kabar dari mereka sebelum melanjutkan hal lain - memutakhirkan dependensi jauh lebih disukai daripada opsi lain IMO.

@jmcelwain Tidak ada banyak kode di https://github.com/ghodss/yaml , ada permintaan tarik yang tidak dilayani dari 2017: https://github.com/ghodss/yaml/pulls , dan kodenya adalah MIT berlisensi.

Apakah ketergantungan ini benar-benar menarik bebannya? Ini adalah beberapa pembantu yang menyusun tetapi mengelola untuk menahan masalah yang ketika diselesaikan dapat meningkatkan kemampuan banyak proyek untuk secara dinamis mengatur default paket pada waktu pembuatan (kasus penggunaan kami adalah tidak harus mempertahankan beberapa tempat yang berbeda untuk menyimpan tag versi sesuatu seperti --set image.tag=${GIT_TAG} untuk mengunci grafik dan versi gambar untuk sebuah proyek).

Bolehkah saya menyarankan agar kita tidak menunggu lebih lama lagi dan cukup salin kode yang diperlukan ke dalam helm (saya tidak akan repot-repot menjualnya, hanya menyerap dan menyesuaikan seperlunya). Saya pikir ini adalah proyek yang cukup besar untuk menangani pemeliharaan pembungkus ini dan YAML marshalling adalah kompetensi inti (tidak mengatakan Anda harus memelihara parser Anda sendiri, tapi...!)

Karena ini membuat kami kesakitan sekarang (dan menghentikan kami untuk meningkatkan dari helm 3.0.2), saya akan dengan senang hati mencobanya.

Saya lebih suka menghindari situasi itu. Tidak ada cukup pengelola untuk memelihara pengelola paket DAN pengurai YAML. Itu akan menimbulkan beban pemeliharaan yang signifikan bagi tim.

@bacongobbler itu _bukan_ pengurai yaml. Ini menggunakan gopkg.in/yaml.v2 untuk melakukan penguraian yang sebenarnya. Ini sekitar 900 baris kode pembungkus reflect di sekitar parser itu. Masalahnya adalah mereka tidak menggunakan gopkg.in/yaml.v3 yang akan menyelesaikan masalah ini.

Tampaknya bagi saya beban pemeliharaan menggunakan perantara kecil ini untuk ketergantungan Anda yang sebenarnya adalah beban yang lebih besar daripada mempertahankan sedikit kode ini.

Seperti yang disebutkan sebelumnya di utas, silakan ajukan PR upstream yang akan memperbarui ghodss/yaml ke yaml.v3. Jika mereka tidak mau menerimanya, jangan ragu untuk membayar proyek dan memeliharanya jika Anda merasa dapat menanggung beban pemeliharaan.

Biar saya perjelas: kami _tidak_ menerima permintaan tarik yang bercabang dan vendor ghodss/yaml ke Helm. Kami tidak dapat menanggung beban pemeliharaan tambahan dari seluruh pustaka Go hanya untuk mendukung satu fitur.

@bacongobbler silakan lihat PR saya di sini: https://github.com/helm/helm/pull/7963

Ini adalah 900 baris kode dengan tes yang disertakan dan fungsionalitas yang berlebihan dihapus.

Saat ini Anda bergantung pada apa yang tampak seperti perpustakaan yang relatif tidak terawat dengan jejak yang jauh lebih besar daripada yang saya tambahkan di sana.

seluruh perpustakaan Go hanya untuk mendukung satu fitur

Anda menggunakan semua satu fungsi dari seluruh pustaka Go ini, dan untuk melakukan itu, Anda telah berupaya membuat garpu permanen yang semakin mengaburkan dari mana kode itu berasal.

jangan ragu untuk membayar proyek dan memeliharanya jika Anda merasa dapat menanggung beban pemeliharaan.

Maksud saya, Anda sudah menjalankan garpu tujuan tunggal dari kode ini. Jika proyek ditinggalkan maka Anda sebenarnya tidak mendapat manfaat dari pemeliharaan apa pun dari penulis aslinya.

Jika Anda mau, saya dapat mengambil sejumlah kecil kode itu di PR saya dan memasukkannya ke dalam repo dan mengatakan saya akan mempertahankannya (dan saya akan berusaha melakukannya), tetapi tampaknya agak konyol.

Biar saya perjelas: kami tidak akan menerima permintaan tarik yang bercabang dan vendor ghodss/yaml ke Helm.

Sebagai catatan, saya sudah mendorong PR itu pada saat saya membaca ini, jadi saya harap Anda akan mempertimbangkan kembali karena saya pikir Anda memiliki pemikiran yang tidak jelas tentang 'vendoring' dan 'seluruh perpustakaan Go' (yang mungkin sering saya setujui ) tanpa melihat kode yang terlibat. Tapi mari kita bahas kode sebenarnya yang dimaksud di PR. Saya senang menjadi pemilik kode untuk kode ini jika itu membantu. Mari kita bayangkan saya menulisnya sebagai kontribusi... Saya memang melakukannya.

Mungkin mereka akan menggabungkannya: https://github.com/ghodss/yaml/pull/62

Alternatif lain yang saya jelajahi secara singkat adalah kemungkinan mengganti konversi YAML ke JSON melalui beberapa ketergantungan lain atau membuat serial melalui beberapa format perantara. Saya tidak cukup akrab dengan ekosistem Go untuk mengetahui apakah ini jalur yang layak -- saya agak terkejut karena saya tidak dapat menemukan lebih banyak lib tipe serialisasi ketika saya melihat sekilas.

Adakah ide kapan kita dapat memiliki --set kembali saat kita menggunakan ini untuk mengotomatiskan pengemasan helm. Itu ada di Helm 3.0.2 dan sekarang karena pembaruan tidak lagi didukung.

Kami masih diblokir untuk menggabungkan https://github.com/ghodss/yaml/pull/62 .

Melihat kode lagi, Anda benar @lukaslarson dan @maxhillaert. Namun, ini masih merupakan fitur yang dimaksudkan untuk dikembalikan karena menghapus semua komentar dari file nilai paket. Itu dihapus di Helm 2, tetapi secara tidak sengaja masuk ke Helm 3. Itu tidak pernah dimaksudkan untuk dikirim.

Jika seseorang ingin bekerja untuk menerapkan kembali #3471 yang menyimpan komentar, kami akan dengan senang hati melihat PR.

Apakah penting jika komentar dihapus, Jika ada peringatan menggunakan --set Saya tidak peduli dengan komentar.

Kami masih diblokir untuk menggabungkan ghodss/yaml#62 .

Saya kira terjebak dengan menggunakan 3.0.2 :(

3471 menghapus komentar terlepas dari apakah Anda menggunakan --set atau tidak, sehingga merusak pengguna yang tidak pernah menggunakan fitur ini. Itu merusak kompatibilitas ke belakang untuk semua orang. Oleh karena itu tidak dapat diperkenalkan kembali dengan peringatan, dan itulah sebabnya kami menunggu perbaikan yang tepat di hulu.

itulah mengapa kita harus tetap menggunakan 3.0.2

Kami masih diblokir untuk menggabungkan ghodss/yaml#62 .

Tapi karena sepertinya ketergantungan ini tidak lagi dipertahankan, mungkin lebih baik menggunakan versi yang bercabang, bukan?

Mengganti itu adalah ide yang bagus -- tetapi harus ditunda ke Helm 4. Seseorang harus mengajukan masalah khusus untuk mengganti parser YAML sehingga kami dapat melacaknya untuk proses Helm 4.

Biar saya perjelas: kami tidak akan menerima permintaan tarik yang bercabang dan vendor ghodss/yaml ke Helm. Kami tidak dapat menanggung beban pemeliharaan tambahan dari seluruh pustaka Go hanya untuk mendukung satu fitur.

Mengingat tampaknya https://github.com/ghodss/yaml tidak lagi dipertahankan, dan tidak ada tanda kehidupan di https://github.com/ghodss/yaml/pull/62 , apakah layak mempertimbangkan kembali posisi ini, dan mengevaluasi ulang https://github.com/helm/helm/pull/7963 ?

Kami tidak tertarik untuk menanggung beban pemeliharaan dengan mendukung seluruh perpustakaan penguraian YAML hanya untuk satu fitur.

Saya akan mendesak komunitas untuk mempertimbangkan bekerja dengan pengelola ghodss/yaml yang ada untuk menemukan kumpulan pengelola baru yang bersedia mendukung proyek, melakukan fork proyek, atau menemukan perpustakaan baru yang dapat menyimpan komentar.

Jadi apa itu?

• temukan pengelola baru untuk mendukung ghodss/YAML !?
• temukan seseorang untuk melakukan fork ghodss/YAML dan gunakan YAML.v3 (dan terus dukung) !!
• gunakan YAML.v3 secara langsung
• mengusulkan untuk mengganti parser YAML untuk helm 4

seluruh perpustakaan penguraian YAML

Ini salah mengartikan ruang lingkup kode yang terlibat di sini. Ini adalah beberapa pembungkus di sekitar parser lain.

Kami tidak tertarik untuk menanggung beban pemeliharaan dengan mendukung seluruh perpustakaan penguraian YAML hanya untuk satu fitur.

Mungkin kebingungan ini menjelaskan banyak hal - parsernya adalah https://github.com/go-yaml/yaml , bukan ghodss/YAML. Dari https://github.com/ghodss/yaml :

Pembungkus di sekitar go-yaml

Jadi solusi sederhananya adalah : hentikan saja penggunaan pembungkusnya.

"Pembungkus" memiliki pengaruh besar pada beberapa perilaku. Setelah mengganti parser (dan pustaka pembungkus) beberapa kali di awal proyek, pengelola inti sangat menyadari perbedaan kecil di antara mereka, dan bagaimana hal itu menghasilkan masalah kompatibilitas tingkat tinggi.

Ada kemungkinan bahwa kami mungkin mempertimbangkan untuk menggunakan garpu ghodss/yaml JIKA DAN HANYA JIKA pemilik garpu itu berkomitmen untuk melanjutkan pemeliharaan.

Mungkin saya bisa lebih tepat - berhenti menggunakan perpustakaan pembungkus yang ditinggalkan, dan lakukan perilaku pembungkus yang setara/identik di helm, yang dilakukan https://github.com/helm/helm/pull/7963 di sekitar ~250 LOC plus tes.

Ya, idealnya seseorang akan memperbaiki di ghodss/yaml, tetapi tidak lagi dipertahankan. Tentunya alternatifnya tidak menunggu sampai Helm 4?

Saya pikir forking mungkin adalah pilihan terbaik, IMO; @ghodss tampaknya tidak memiliki aktivitas apa pun di GH sejak awal 2019, dan komitmen terakhir untuk repo adalah satu setengah tahun yang lalu (oleh @bradfitz). Rilis (satu-satunya) terakhir adalah pada tahun 2017. Jika ada masalah keamanan laten dalam kode, itu tidak akan diperbaiki di main.

Saya sangat menganjurkan mengadopsi garpu jika seseorang bersedia berkomitmen untuk mempertahankannya; Saya tidak melihat kerugian apa pun sehubungan dengan terus menggunakan paket yang hampir mati dan ditinggalkan. Saya setuju bahwa pindah ke pembungkus yang berbeda lebih masuk akal sebagai perubahan besar (sepertinya pengangkatan yang cukup berat sehingga bisa dengan mudah menjadi hal Helm 4, tapi saya tidak akan berspekulasi lebih jauh), tapi saya pikir ini bisa diselesaikan dengan replace baris di go.mod .

Saya bersedia berkomitmen untuk membantu memelihara garpu jika orang lain juga; Saya tidak memiliki cukup bandwidth untuk melakukannya sendiri saat ini, tetapi saya memiliki cukup untuk berkontribusi.

Memang, saya sangat tertarik dengan ini sehingga saya dapat menyingkirkan tumpukan skrip sed saya untuk mengemas bagan Helm saya, tetapi jika itu yang diperlukan, biarlah.

Halo yang disana
Saya baru saja membuat plugin yang memungkinkan untuk menetapkan nilai saat mengemas. untuk saat ini hanya mendukung flag set (karena saya membutuhkannya :sweat_smile: ) tetapi saya bermaksud menambahkan flag lain. jangan ragu untuk mendorong PR jika Anda suka atau menambahkan komentar untuk memperbaikinya.
Terima kasih

Untuk berjaga-jaga jika ada yang belum mengikuti, ada beberapa kemajuan dalam ghodss/yaml#62 menghubungi pengelola, jadi semoga kami akan segera mendengar kabar baik!

Masalah ini telah ditandai sebagai basi karena telah dibuka selama 90 hari tanpa aktivitas. Thread ini akan ditutup secara otomatis dalam 30 hari jika tidak ada aktivitas lebih lanjut.

Pasti tidak basi. Saya telah mencoba mencari waktu untuk menindaklanjuti dengan https://github.com/ghodss/yaml/pull/62 dan melihat apakah kami dapat membantu menggabungkannya untuk membuka blokir kemajuan dalam masalah ini. Karena org saya telah meningkatkan ketergantungan kami pada Helm, kami terus ingin dapat memasukkan nilai ke dalam bagan paket build per-CI.

Saya telah menghapus semua komentar yang meminta pembaruan status karena tidak menambahkan apa pun ke percakapan yang ada. @jmcelwain memberikan pembaruan status tidak kurang dari 5 hari yang lalu (terima kasih, btw) dan sebaik apa pun. Seperti disebutkan sebelumnya, solusi untuk masalah ini rumit dan melibatkan pembaruan atau forking beberapa dependensi, jadi ada beberapa uji tuntas yang diperlukan.

Ketika kami memiliki lebih banyak informasi untuk dibagikan, kami akan memperbarui utasnya.

Sebagai solusinya, saya telah menggunakan https://github.com/mikefarah/yq untuk memperbarui bagan helm saya sebelum mengemas:

yq w -i values.yaml version $(Build.BuildNumber)

Di CI kami, kami membuat gambar aplikasi / buruh pelabuhan dan bagan di saluran yang sama (untuk memastikan bahwa aplikasi & bagan berkembang bersama dengan versi yang sama). Nilai default untuk bagan bergantung pada versi gambar yang dibuat sebelumnya.

Solusi yq dapat dengan mudah diintegrasikan dalam pipa, tetapi tampaknya aneh bahwa kasus penggunaan ini tidak dicakup dengan benar oleh helm !

Jadi mereka tidak ada cara terintegrasi dengan helm untuk mengatur image.tag selama/sebelum fase paket?

edit : menemukan solusi ini dalam kasus saya, kami perlu menggunakan Chart.AppVersion untuk tag gambar karena kami mengemas bagan dengan versi yang sama.

edit 2 : Chart.AppVersion / tidak berfungsi dengan bagan bersama (exp bagan spring-boot digunakan dalam beberapa bagan payung)

kesimpulan saya : Benar-benar perlu mengatur image.tag selama fase paket

Ada kabar tentang fitur ini?