Ini menggigitku hari ini juga.

Sepertinya itu mungkin karena komit ini:
https://github.com/helm/helm/commit/32d7f1a3fc226c1745a58b51e318b7362bc7a0bf

TL; DR - Perbaiki validasi manifes

Sayangnya, jika Anda memiliki sesuatu yang sudah di-deploy dengan string kosong, Anda tidak dapat menerapkan sesuatu yang "diperbaiki" karena komponen yang sudah di-deploy akan gagal validasi. Satu-satunya jalan keluar Anda adalah helm delete --purge untuk menyingkirkan templat yang melanggar dari riwayat dan melanjutkan. Atau putar kembali kemudi / anakan

Seperti yang telah didiskusikan dengan anggota komunitas hari ini, # 5576 adalah perubahannya. Sebelum 2.14, Helm menerima kesalahan validasi skema secara diam-diam, tetapi mulai 2.14, semua manifes divalidasi, termasuk yang telah diterima sebelumnya. Hasil akhirnya adalah bahwa peningkatan ke 2.14 menyebabkan Tiller gagal dalam validasi manifes pada bagan yang telah diterima sebelumnya, sehingga mencegah peningkatan. Maaf soal itu!

Mitigasi untuk ini mudah: turunkan ke 2.13.1 untuk meningkatkan untuk saat ini hingga perbaikan dirilis.

5643 harus memperbaikinya karena validasi hanya terjadi untuk manifes baru yang ditambahkan ke rilis, dan kami ingin mendengar apakah itu menyelesaikan masalah yang diangkat di sini. Jika demikian, kita mungkin perlu memotong 2.14.1 dengan perbaikan.

EDIT: # 5576 adalah PR yang membuat perubahan. # 5643 adalah PR yang harus memperbaiki ini. :)

Saya bisa mencoba # 5643 besok kecuali seseorang mengalahkan saya untuk itu.

Bukankah tindakan yang bijaksana untuk memunculkan kesalahan validasi yang 'diam-diam' gagal sebelumnya, dengan peringatan, bahwa di rilis mendatang menjadi kesalahan? Atau setidaknya, hormati bendera gaya atau semacamnya yang memungkinkan pengguna untuk memilih bagaimana menanganinya?

Terima kasih semuanya atas balasan Anda!
Saya mencoba mengunduh binari dari Helm Canary build terbaru tetapi masalah masih mereproduksi. Saya tidak yakin bahwa binari ini sesuai dengan versi master terbaru.
Saya mengalami masalah saat membuat Helm secara lokal, jadi saya akan sangat tertarik dengan hasil pengujian Anda @ fooka03 !

Saya tidak yakin bahwa binari ini sesuai dengan versi master terbaru.

Periksa output dari helm version - yang akan memberi tahu Anda komitmen apa yang dijalankan klien helm dan anakan Anda. Karena tambalan di # 5643 adalah tambalan sisi server, Anda harus memastikan bahwa anakan telah diperbarui.

Sama, menggunakan k8s 1.8.4:

`Kesalahan: kesalahan memvalidasi" ": kesalahan memvalidasi data: [ValidationError (Deployment.spec.template.spec.containers [1] .ports [0]): bidang tidak dikenal" exec "di io.k8s.api.core.v1. ContainerPort, ValidationError (Deployment.spec.template.spec.containers [1] .ports [0]): kolom tidak dikenal "initialDelaySeconds" di io.k8s.api.core.v1.ContainerPort]

Kesalahan: kesalahan memvalidasi "": kesalahan memvalidasi data: ValidationError (StatefulSet.spec): bidang "serviceName" yang diperlukan tidak ada di io.k8s.api.apps.v1beta1.StatefulSetSpec Kesalahan: UPGRADE GAGAL: kesalahan memvalidasi data: ValidationError (StatefulSet.spec): bidang wajib "serviceName" di io.k8s.api.apps.v1beta1.StatefulSetSpec` tidak ada

Saya tidak yakin bahwa binari ini sesuai dengan versi master terbaru.

Periksa output dari helm version - yang akan memberi tahu Anda komitmen apa yang dijalankan klien helm dan anakan Anda. Karena tambalan di # 5643 adalah tambalan sisi server, Anda harus memastikan bahwa anakan telah diperbarui.

Terima kasih @bacongobbler ! Mengikuti komentar Anda, saya meningkatkan anakan saya:

Client: &version.Version{SemVer:"v2.14+unreleased", GitCommit:"9fb19967bab21ecb9748440a99487f2fb0560f63", GitTreeState:"clean"}
Server: &version.Version{SemVer:"canary+unreleased", GitCommit:"9fb19967bab21ecb9748440a99487f2fb0560f63", GitTreeState:"clean"}

Namun, saya masih mendapatkan kesalahan yang sama persis saat menjalankan helm install . :(
Kesalahan: validasi gagal: kesalahan memvalidasi "": kesalahan memvalidasi data: jenis objek tidak dikenal "nil" di Deployment.spec.template.metadata.annotations.buildID

Komit tersebut sesuai dengan https://github.com/helm/helm/commit/9fb19967bab21ecb9748440a99487f2fb0560f63 , jadi sepertinya masalah tersebut masih muncul kembali dalam kasus saya meskipun telah diperbaiki.

Bisakah kita mendapatkan ETA untuk perbaikan terbaru? Saya benar-benar ingin menghindari menambal server saya dengan helm / anakan yang dibuat sendiri. Terima kasih!

@ daniv-msft Bisakah Anda mencoba melakukan ini di template Anda yaml?

template:
  metadata:
    labels:
      app: {{ template "gateway.name" . }}
      draft: {{ default "draft-app" .Values.draft }}
      release: {{ .Release.Name }}
    annotations:
      buildID: {{ .Values.buildID | quote }}

@SeriousM untuk saat ini Anda dapat melakukan rollback ke 2.13.1 dan menunggu rilis 2.14.1. Saya mencoba commit 9fb19967 dan berhasil untuk saya

@SeriousM untuk saat ini Anda dapat melakukan rollback ke 2.13.1 dan menunggu rilis 2.14.1. Saya mencoba commit 9fb19967 dan berhasil untuk saya

kami memiliki banyak pipeline rilis devops biru (30+) dan masing-masing berusaha mempertahankan versi build stabil terbaru. Saya dapat menurunkan versi untuk saat ini tetapi setelah pipeline build berikutnya dimulai, versinya akan kembali ke 2.14.0 dan saya benar-benar tidak membahas semua 30+ untuk menonaktifkan langkah tersebut dan mengaktifkannya kembali nanti. Maaf, tapi saya harus menunggu perbaikan terbaru.

Apakah ada ETA di hotfix?

@ daniv-msft Bisakah Anda mencoba melakukan ini di template Anda yaml?

template:
  metadata:
    labels:
      app: {{ template "gateway.name" . }}
      draft: {{ default "draft-app" .Values.draft }}
      release: {{ .Release.Name }}
    annotations:
      buildID: {{ .Values.buildID | quote }}

Ini adalah konten saya dari file deployment.yaml yang cocok dengan jalur Deployment.spec.template.metadata.annotations.buildID :

spec:
  template:
    metadata:
      annotations:
        buildID: {{ .Values.buildID }}
      labels:
        app: {{ template "fullname" . }}
        env: {{ .Values.labels.env }}

Apakah menurut Anda | quote dapat memperbaiki masalah?

@Serius Kesalahan apa yang Anda dapatkan saat ini? Dan saya mencoba | quote dengan master commit, bukan versi rilis, dan itu pada dasarnya akan mengelilingi nilai dengan tanda kutip ganda, dan ini berguna ketika nilainya kosong, karena yaml dirender sebagai

  annotations:
    buildID: ""

Jika Anda tidak menggunakan | quote , itu akan dirender sebagai

  annotations:
    buildID: 

yang akan menyebabkan kesalahan validasi yang dijelaskan dalam masalah tersebut. Saya memverifikasi ini dengan menggunakan bagan dummy yang saya buat ini:

issue-5750.tar.gz

@Serius Kesalahan apa yang Anda dapatkan saat ini?

Kesalahan saya Error: UPGRADE FAILED: error validating "": error validating data: unknown object type "nil" in Deployment.spec.template.metadata.annotations.buildID tapi saya tidak mengerti mengapa. Pertama saya berpikir bahwa buildID tidak diteruskan ke perintah cli dari azure devops tetapi karena @ daniv-msft mendapat kesalahan yang sama, saya kira itu karena validasi server.

@Serius Kesalahan apa yang Anda dapatkan saat ini?

Saya mencoba mengubah deployment.yaml saya dengan menambahkan | quote dan bahkan menghapus metadata/annotations/buildID sama sekali tetapi ini tidak membantu.

Ini adalah kesalahan yang saya dapatkan ketika saya menghapus anotasi buildID:

Error: failed decoding reader into objects: error validating "": error validating data: unknown object type "nil" in Deployment.spec.template.metadata.annotations.buildID

Berkenaan dengan rilis 2.14.1, kami mungkin tidak akan dapat menghentikan rilis hingga setelah KubeCon.

Berkenaan dengan rilis 2.14.1, kami mungkin tidak akan dapat menghentikan rilis hingga setelah KubeCon.

Yang pasti untuk mendapatkan ini dengan benar, maksud Anda KubeCon ini?

KubeCon EU, yang minggu depan, bukan November. :)

KubeCon EU, yang minggu depan, bukan November. :)

Jadi kita bisa mengharapkan perbaikan dalam bentuk v2.14.1 di 24.5.19?
Dapatkah saya mengompilasinya sendiri?

@SeriousM Kesalahan pertama yang Anda dapatkan, yaitu
Error: UPGRADE FAILED: error validating "": error validating data: unknown object type "nil" in Deployment.spec.template.metadata.annotations.buildID
karena masalah pada templat bagan yamls, yang tampaknya telah Anda perbaiki dengan | quote

Kesalahan selanjutnya
Error: failed decoding reader into objects: error validating "": error validating data: unknown object type "nil" in Deployment.spec.template.metadata.annotations.buildID
disebabkan oleh manifes yang buruk dalam rilis yang ada. Untuk menghindari hal ini, anakan tidak boleh memvalidasi manifes rilis dan hanya memeriksa manifes yang diberikan oleh pengguna, dan itulah yang dilakukan dan dimiliki oleh PR https://github.com/helm/helm/pull/5643 (fix) telah digabung menjadi master. Anda dapat menggunakan gambar kenari anakan untuk memeriksa apakah semuanya bekerja untuk Anda. Jika rilis yang gagal diperbaiki satu kali (dengan mengupgrade dengan manifes yang tepat), maka jika pipeline menggunakan versi 2.14, tidak akan ada masalah validasi

Anda dapat menggunakan gambar kenari anakan untuk memeriksa apakah semuanya bekerja untuk Anda.

Bagaimana cara menerapkan gambar ini?

@SeriousM Dengan versi helm klien apa pun, Anda dapat menggunakan

helm init --tiller-namespace <namespace> --upgrade --canary-image

Untuk mendapatkan helm client (master) terbaru, Anda dapat menggunakan ini: https://helm.sh/docs/using_helm/#from -canary-builds

Jadi sepertinya # 5643 memperbaiki masalah validasi manifes:

helm version
Client: &version.Version{SemVer:"v2.14.0", GitCommit:"05811b84a3f93603dd6c2fcfe57944dfa7ab7fd0", GitTreeState:"clean"}
Server: &version.Version{SemVer:"canary+unreleased", GitCommit:"9fb19967bab21ecb9748440a99487f2fb0560f63", GitTreeState:"clean"}

Release "belligerent-horse" has been upgraded.
LAST DEPLOYED: Fri May 17 10:32:12 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME                             DATA  AGE
<redacted>-belligerent-horse  1     181d
<redacted>                      2     181d

==> v1/Pod(related)
NAME                               READY  STATUS       RESTARTS  AGE
<redacted>-belligerent-horse-0  1/1    Running      0         5m16s
<redacted>-belligerent-horse-1  1/1    Terminating  0         17h

==> v1/Service
NAME           TYPE       CLUSTER-IP  EXTERNAL-IP  PORT(S)   AGE
<redacted>  ClusterIP  None        <none>       8080/TCP  181d

==> v1/StatefulSet
NAME                             READY  AGE
<redacted>-belligerent-horse  2/2    181d

Tentu saja masih harus menyetel bidang validasi yang hilang di template "baru", tetapi setidaknya itu akan memungkinkan Anda menerapkan pada rilis yang ada.

@SeriousM Dengan versi helm klien apa pun, Anda dapat menggunakan

helm init --tiller-namespace <namespace> --upgrade --canary-image

Untuk mendapatkan helm client (master) terbaru, Anda dapat menggunakan ini: https://helm.sh/docs/using_helm/#from -canary-builds

Terima kasih banyak, saya akan mencobanya secepatnya

@ fooka03 > Terima kasih telah membagikan hasil tes Anda! Meskipun telah diperbaiki, saya masih mereproduksi masalah dengan bagan saya sendiri dan bagan yang disediakan oleh @ karuppiah7890 ( issue-5750.tar.gz ). Bisakah Anda membagikan bagan yang Anda gunakan, atau beri tahu kami jika Anda melihat ada perbedaan dalam bagan Anda dibandingkan dengan yang ini?

@ karuppiah7890 > Dengan bagan yang Anda berikan, agar pemasangan helm berhasil, saya harus menambahkan | quote ke deployment.yaml dan buildID juga harus disediakan di values.yaml. Jika saya mengomentari baris ke #buildID: "" atau menghapus | quote , maka kesalahan mereproduksi sementara itu berfungsi dengan baik di v2.13.1.

Sayangnya, dalam kasus saya, tidak mungkin untuk meningkatkan file bagan, jadi perbaikan yang tidak menyiratkan perubahan apa pun pada bagan yang ada akan jauh lebih mudah ditangani.

Apakah saya satu-satunya yang mereproduksi masalah meskipun sudah diperbaiki? Versi helm tampaknya mengembalikan versi yang benar, tetapi adakah hal lain yang harus saya verifikasi untuk memastikan saya menggunakan bit terbaru?

Client: &version.Version{SemVer:"v2.14+unreleased", GitCommit:"9fb19967bab21ecb9748440a99487f2fb0560f63", GitTreeState:"clean"}
Server: &version.Version{SemVer:"canary+unreleased", GitCommit:"9fb19967bab21ecb9748440a99487f2fb0560f63", GitTreeState:"clean"}

@ daniv-msft Dalam bagan saya, template yang tidak valid kehilangan kuncinya sepenuhnya (serviceName untuk statefulset). Karena helm telah menyetel ini secara otomatis ke string kosong (serviceName: "") dalam manifes yang diterapkan, saya hanya menambahkan serviceName: {{ .Values.serviceName | default "" | quote }} ke template saya. Filter default dalam hal ini berarti saya tidak perlu memberikan nilai untuk serviceName.

Seperti yang saya sebutkan dalam komentar saya, versi tetap masih mengharuskan Anda membuat perubahan pada manifes baru untuk melewati validasi. Satu-satunya hal yang berbeda adalah bahwa versi tetap tidak juga melakukan validasi terhadap bagan yang sudah diterapkan yang akan memungkinkan Anda untuk menerapkan tanpa harus membersihkan terlebih dahulu.

Pada akhirnya saya pikir dalam skenario Anda di mana Anda tidak dapat memperbarui file bagan Anda, Anda akan terjebak menggunakan 2.13.1 sampai mereka diubah untuk lulus validasi.

@ fooka03 > Terima kasih atas balasan Anda! Saya tidak mengerti sebelumnya bahwa perbaikan hanya akan berlaku untuk bagan yang diterapkan yang ditingkatkan, dan bukan yang baru.

Dalam kasus saya, sayangnya tetap menggunakan v2.13.1 juga bukan merupakan pilihan. :(
Bagan yang kami buat dan yang berfungsi untuk v2.13.1 disediakan untuk pengguna kami sebagai bagian dari alat, dan meskipun kami akan mendorong versi baru untuk memperbaikinya, kami tidak dapat memaksa pengguna kami untuk menggunakan versi terbaru alat kami.
Mendorong versi baru alat / bagan dapat mengurangi dampaknya, tetapi bagaimanapun juga, kami akan mendapati beberapa pengguna kami mencoba memasang versi bagan kami sebelumnya dengan Helm v2.14.0, dan dengan demikian mendapatkan kesalahan validasi.

Meskipun saya memahami bahwa kasus saya spesifik, bukankah perubahan ini juga akan merusak beberapa diagram lain yang dibuat sebelumnya (saya memikirkan https://github.com/helm/charts/tree/master/ stabil)?

Jika ini masalahnya, apakah mungkin untuk menunda perubahan validasi ke Helm v3, dan / atau menerapkan saran @StephanX di atas dan menampilkan peringatan untuk saat ini?

Ada pemikiran tentang strategi mitigasi, @mortent? Mungkin kita harus menariknya keluar dan memindahkannya ke Helm 3. Meskipun berguna, sepertinya ini merusak kasus penggunaan yang ada yang sebelumnya berfungsi. Apa pendapatmu tentang itu?

@bacongobbler Saya setuju kita harus menarik ini keluar. Berdasarkan diskusi di sini, saya tidak yakin bahwa hanya membatasi validasi ke manifes baru (seperti di # 5643) sudah cukup untuk membantu semua pengguna. Saya memiliki PR yang menonaktifkan validasi skema dalam semua kasus: # 5760.

Akan sangat bagus jika seseorang yang mengalami masalah dapat memverifikasi bahwa ini benar-benar menyelesaikan masalah mereka.

Saya baru saja menggunakan gambar kenari tetapi mendapatkan kesalahan yang sama seperti sebelumnya: Error: failed decoding reader into objects: error validating "": error validating data: unknown object type "nil" in Deployment.spec.template.metadata.annotations.buildID .
Jadi saya melakukan hal terdekat yang dapat saya lakukan dan menghapus properti annotations.buildID dari deployment.yaml . Ini mungkin bukan cara orang lain dapat menyelesaikan masalah ini, tetapi jika Anda bisa, hapus saja.
Saya menjalankan citra anakan 2.14.0 tanpa masalah.

@SeriousM Tampaknya build canary hanya didasarkan dari cabang master, Anda harus membuat # 5760 sendiri karena belum digabungkan.

Saya sedang mengalami pemadaman listrik besar-besaran di sini, jadi sepertinya saya tidak dapat mengujinya sendiri hari ini.

Terima kasih atas balasan Anda! Saya ingin menguji perbaikan bug juga, tetapi saya masih mengalami masalah dalam membuat Helm secara lokal.
Saya melihat permintaan tarik dan, meskipun saya tidak terbiasa dengan basis kode, perubahannya terlihat cukup mudah.

Apakah mungkin untuk menyelesaikan permintaan tarik, sehingga saya dapat mencobanya di build Canary berikutnya?
Kasus terburuk, jika ada yang salah, masih mungkin untuk mengembalikan komit ini sebelum mencapai pengguna sebenarnya, bukan?

Kami telah menggunakan referensi penerusan YAML selama 2 tahun terakhir di values.yaml tanpa masalah. Ini bukan YAML yang valid - tetapi berfungsi dan membuat hidup pengembang kami lebih mudah.
YAML terlalu sederhana dan terbatas untuk konfigurasi yang lebih kompleks, tetapi itulah bahasa deklaratif yang digunakan Helm sejauh ini.

Harap pertimbangkan untuk membuat validasi ini diaktifkan oleh sebuah bendera, atau berikan opsi untuk menonaktifkannya dengan sebuah bendera di Helm 3.0 yang akan datang.

Kami mendukung perubahan ini dan memotong 2.14.1.

Kedengarannya bagus, terima kasih @bacongobbler dan semua orang yang terlibat dalam memperbaiki ini!
Saya akan mencoba memperbaikinya segera setelah tersedia.

Yang menyenangkan adalah saya mendapatkan kesalahan validasi yang sama "" untuk restartPolicy di AKS (sama seperti OP), untuk GCP, DigitalOcean, dan Lokal dengan Kubernetes Desktop, hal itu tidak terjadi sama sekali.

Setiap orang yang mengalami masalah ini menggunakan AKS?

Edit:

Saya dapat mengonfirmasi dalam kasus saya (tanpa menggunakan helm atau alat lain di belakang kubectl) bahwa masalahnya ada di AKS karena suatu alasan. Dan meskipun saya berkomentar di lapangan itu mengeluh, kesalahan masih terjadi.

Saya tidak yakin mengapa ini terjadi, tetapi itu hanya di cluster AKS.

Tahu kapan v2.14.1 akan tersedia?

@WoLfulus Saya melihat ini dengan 2.14.0 di GKE:

$ helm upgrade my-release --install --namespace test ./my-chart/ -f ./my-chart/values.yaml
UPGRADE FAILED
Error: failed decoding reader into objects: error validating "": error validating data: ValidationError(Deployment.spec.template): unknown field "annotations" in io.k8s.api.core.v1.PodTemplateSpec
Error: UPGRADE FAILED: failed decoding reader into objects: error validating "": error validating data: ValidationError(Deployment.spec.template): unknown field "annotations" in io.k8s.api.core.v1.PodTemplateSpec

$ helm version
Client: &version.Version{SemVer:"v2.14.0", GitCommit:"05811b84a3f93603dd6c2fcfe57944dfa7ab7fd0", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.0", GitCommit:"05811b84a3f93603dd6c2fcfe57944dfa7ab7fd0", GitTreeState:"clean"}

@WoLfulus Saya menggunakan cluster handspun jadi jelas tidak terbatas pada AKS. Saya tidak yakin bagaimana Anda menjalani tes untuk memberi Anda wawasan tentang mengapa Anda mengalami perilaku yang tidak konsisten seperti itu.

@andyast dari apa yang dikatakan @bacongobbler sebelumnya, seharusnya paling cepat minggu ini. Mereka ditunda karena kubecon yang minggu lalu.
https://github.com/helm/helm/issues/5750#issuecomment -493464958

@ fook3 dan fook3

Ini sangat aneh sebenarnya.

Saya pikir itu ada hubungannya dengan AKS (dalam kasus saya), tetapi masalah saya sedikit berbeda.

Saya mencoba menetapkan restartPolicy untuk penerapan initContainers (yang tidak ada dalam spesifikasi Container , tetapi beberapa vendor (DigitalOcean) menerimanya seolah-olah kubectl dipanggil dengan --validate=false ).

Saya harus menghapus restartPolicy untuk membuatnya berfungsi di AKS.

Jadi saya rasa dalam kasus saya itu tidak ada hubungannya dengan Helm, meskipun format kesalahannya persis sama dengan masalah ini.

kapan kita bisa mengharapkan perbaikan untuk ini?

Permintaan pull https://github.com/helm/helm/pull/5760 yang menonaktifkan validasi telah digabungkan menjadi master oleh @bacongobbler (terima kasih!).
Saya berasumsi bahwa, seperti yang disebutkan oleh @ fooka03 , versi 2.14.1 tidak akan tersedia sebelum beberapa hari tetapi saya ingin membagikan kabar baik. :)

Perubahan telah digabungkan ke master, jadi Anda seharusnya dapat menarik perubahan sekarang.

Bagi mereka yang ingin mencoba build canary: https://helm.sh/docs/using_helm/#from -canary-builds

Adakah yang bisa menguji kenari dan mengonfirmasi jika tambalan yang diterapkan ke master memperbaiki masalah ini? Saya ingin bug ini diverifikasi dan diperbaiki sebelum harus memotong 2.14.1, menghindari kebutuhan untuk 2.14.2. Terima kasih!

Saya akan menguji perbaikan dalam membangun kenari hari ini dan akan memberi tahu Anda hasilnya.

Saya dapat mengonfirmasi bahwa bagi kami itu berhasil

Hal yang sama di sini: Saya menguji perbaikan dari canary build terbaru dan berfungsi untuk kami juga.

@SeriousM Dengan versi helm klien apa pun, Anda dapat menggunakan

helm init --tiller-namespace <namespace> --upgrade --canary-image

Untuk mendapatkan helm client (master) terbaru, Anda dapat menggunakan ini: https://helm.sh/docs/using_helm/#from -canary-builds

Ini berhasil untuk saya, terima kasih banyak

Adakah yang tahu cara mencegah jaringan pipa gitlab menggunakan helm: terbaru? Kami menerapkan semuanya melalui laptop kami karena gitlab menggunakan 2.14. Ini membutuhkan banyak waktu.

@pulpbill Bagaimana Anda menginstal atau mendapatkan klien helm di GitLab? Apakah Anda mengunduh dari rilis? atau menggunakan gambar buruh pelabuhan? Dan Anda ingin menginstal 2.13.1 kan?

Saya mencoba menemukan gambar buruh pelabuhan untuk helm, tetapi tidak dapat menemukan gambar resmi. Jika Anda mau, Anda bisa membuat image buruh pelabuhan dengan mendownload dan meletakkan binary helm di dalamnya dan kemudian Anda bisa menggunakan image itu di gitlab ci config. Anda dapat menemukan url untuk mengunduh binari (semua versi) dari halaman rilis - https://github.com/helm/helm/releases . Dan Anda dapat melakukan hal yang sama (unduh dan instal dalam $PATH ) di dalam pekerjaan gitlab Anda juga, jika Anda tidak ingin menggunakan gambar buruh pelabuhan dan pelari buruh pelabuhan di gitlab.

Mari kita coba untuk menjaga topik tetap pada subjek. @pulpbill jika Anda tidak keberatan mengirimkan email ke milis pengguna helm atau dengan bertanya langsung kepada tim gitlab, itu bagus; ini sepertinya masalah dengan gitlab lebih banyak daripada dengan Helm, dan tampaknya tidak terkait dengan masalah yang ada di sini.

AutoDevops mengunduh helm saat menjalankan tugas penerapan jika Anda melihatnya di sini: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab- ci.yml # L472
Saya pikir jika Anda menyetel env var HELM_VERSION di variabel cicd, ini mungkin memungkinkan Anda untuk menimpanya tetapi saya tidak yakin.

Terima kasih @ karuppiah7890 dan

@bacongobbler Maaf untuk di luar topik!

Helm v2.14.1 telah dirilis: https://github.com/helm/helm/releases/tag/v2.14.1

Halo Tim, Kami juga menghadapi masalah ini di v3 yang baru dirilis tetapi tidak di versi beta v3.0.0-beta.4. Mohon bantuannya dengan resolusi.

ini masih terjadi pada v3.2.4 . v3.2.3 berfungsi dengan baik.

ini masih terjadi pada v3.2.4 . v3.2.3 berfungsi dengan baik.

Terjadi di 3.2.3 juga di Mac

versi helm
version.BuildInfo {Versi: "v3.2.3", GitCommit: "8f832046e258e2cb800894579b1b3b50c2d83492", GitTreeState: "clean", GoVersion: "go1.13.12"}

Saya tidak memiliki akses ke kode lama, tetapi saya memiliki masalah nyata pada bagan saya yang mengakibatkan dan kesalahan pada v3.3.0 dan kesalahan itu hilang ketika saya memperbaikinya