関連するリクエスト：＃2566

私はこれに取り組み始めました。
＃2566のコメントを考慮して、-valuesまたは--set（あるいはその両方）を探していますか？

私が開いた問題（＃3198）には、次のような優れたユースケースが記載されています。

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

このように、チャートバージョンとDockerイメージバージョンは同じです。

最初のドラフトを完成させ、このためのPRを投稿しました。

@ ngeor 、 @ sslavic私が提出したPRは、-setと--valuesの両方のオプションを追加します。ご覧ください。

こんにちは@adshmh 、よさそうです。 残念ながら、Goはわかりませんが、テストケースなどでカバーされているので、おそらくそれが言っていることを実行します:)ありがとうございます。

この機能はいつ利用可能になりますか？ 2.9.0では？

3471は2.9の締め切りに間に合わなかったため、2.10になります。

＃3471をバックアウトする必要があるため、これを再度開きます。

これは、アーカイブパッケージのコメントなどにどのように影響しますか？ 例えば、それらは剥ぎ取られているのか、それとも放っておかれているのか？

現在、 yqで同じことをしようとしていますが、処理後に最終値をダンプするだけです。 つまり、すべてのコメント、組織の空白行などがなくなりました。

3471はすべてのコメントを削除しました。そのため、そのPRを取り消す必要がありました。 詳細については、 https： //github.com/kubernetes/helm/pull/3471#issuecomment-381779783を参照してください

2.10から復帰"feat：--setおよび--valuesオプションを'helmパッケージ'に追加" https://github.com/helm/helm/commit/7b8aa ​​e466761448522acbd3beb2a16ad2283013a

これについてのいくつかのニュース？
ありがとう

同上; ＃3471のバグを修正するためのフォローアップに取り組んだ人はいないため、これは実装されていません。 値ファイルからコメントが削除されても問題がない場合は、Helmをフォークして＃3471に対してコンパイルすることを歓迎します。

これは行われますか？ バージョン2.11.0と2.12.0を試してみましたが、どれもhelm package --set...を持っていないようです

+1。 CIで、パックする前に値のyamlの一時停止とアップガードを停止するのに本当に役立ちます。

+1

--set-stringも役立ちます。インストール/アップグレードに存在するすべてのオーバーライドオプションを許可しないのはなぜですか。
packageコマンドの値をオーバーライドするために使用したのと同じコードを実行するだけで、パッケージにオーバーライド値が含まれることは理にかなっています。これらのフラグは、install/upgradeと同じように共有する必要があります。

2.13.1にもそのような機能はありませんが、そのためのタイムテーブルはありますか？

先に述べたように、現在誰もこれに取り組んでおらず、修正がいつ利用可能になるかについてのスケジュールはありません。 これをお気軽にどうぞ。 アイデアについては＃3471をご覧ください。

Helm3に実装されています。 閉鎖！

コードを見ると、＃3471が誤ってHelm 3に入ったように見えますが、このコメントのためにHelm2の場合のように引き出されることはありませんでした： https ：//github.com/helm/helm/pull/3471#issuecomment -381779783

https://github.com/helm/helm/pull/7201を使用してHelm3の--setフラグと--valuesフラグを削除しているため、この機能リクエストを再度開きます。 とにかく機能しませんでした... --setまたは--valuesを介して設定されたものはパッケージに注入されず、 helm packageで致命的なリグレッションが発生しました。つまり、それが削除されたという事実です。いくつかのコミュニティメンバーがドキュメントとして使用しているvalues.yamlからコメントを出します。

誤解しているかもしれませんが、--set with packageを使用して値を設定してきました。これは、3.0.0から3.0.2までうまく機能し、＃7201で説明されているような「no-op」ではありません。

3.0.3以降、パイプラインが壊れています。 これは3.0.2で機能していました。 --versionと--app-versionがある場合、これが有用であると見なされないのはなぜですか。 --app-versionに一致するように、画像とタグをどのように編集する必要がありますか？ バッシュ？

コードをもう一度見ると、あなたは正しい@lukaslarsonと@maxhillaertです。 ただし、これは、パッケージの値ファイルからすべてのコメントを削除したため、元に戻すことを目的とした機能でした。 Helm 2で削除されましたが、誤ってHelm3に侵入しました。出荷することを意図したものではありませんでした。

コメントを保持する＃3471の再実装に取り​​組みたい場合は、PRを検討させていただきます。

@bacongobblerこれは私たちのためにいくつかのものを壊しました。 PRに興味がありますが、些細なことではないようですので、アプローチを確認したいと思います。

gopkg.in/yaml.v3は、往復の際のコメントの保持をサポートしているようです。 私の提案は、 Valuesをyaml Nodeにすることです。 次に、値を合体するときに、ネストされたマップではなく、解析された出力のツリーをウォークします。 これは確かに人間工学的ではありませんが、コメントを保存するための最良の方法です。

基になるライブラリのv2に固定されているsigs.k8s.io/yamlをどこでも使用しているため、これは少し問題です。 最低限、これには別の依存関係として導入する必要がありますが、これは一種の厄介です。 ここでの最善のアプローチは、yamlを扱うすべてのものに触れないようにすることです。

最良のオプションはyaml.v3に移行するように見えるので、正しい方向に進んでいるように聞こえます。

sig.k8s.io/yamlの代わりにyaml.v3を使用するHelmのPoC/フォークで作業を開始したい場合は、それが良い道です。 そうすれば、 masterにあるものと比較してその機能を評価し始めることができます。

yaml.v3が最善の道であることが確認できたら、SDKの観点からどのように進めるかを理解できます。

それはあなたのブロックを解除するのに役立ちますか？

@jmcelwainこれに積極的に取り組んでいますか？ そうでなければ喜んで引き継ぎます。

@sreya92仕事で忙しくなりました。 ここで中断しました。yaml.v3への切り替えは、ここのこのビットを除いて、ほとんど簡単でした。 依存関係をベンダー化し、そこでv3に更新することなく、これを処理するための最善のアプローチが何であるかはわかりませんでした。

アップグレードのためにいくつかの作業が行われたようですが、問題などに関する他の情報はなく、私はわざわざ問題を開くことはしませんでした。 もう1つのオプションは、両方の依存関係を維持することですが、それはひどいようです。

私の個人的な意見では、メンテナが同様のライブラリの2つのコピーを持ち歩く価値があると感じない限り、これはこの問題のブロッカーであると思います。 LoEがここにあるかどうかはわかりませんが、おそらくgithub.com/ghodss/yamlをv3に移行し、k8sのベンダーバージョンもアップグレードする必要があります。 それはこれをすべてはるかに簡単にするでしょう。

https://github.com/ghodss/yaml/issues/61を開いて、そこでのアップグレードパスの可能性について問い合わせました。 他のことを続行する前に、それらからの返信を待ちます-依存関係のアップグレードは、他のオプションIMOよりもはるかに望ましいです。

@jmcelwain https://github.com/ghodss/yamlには大量のコードはなく、2017年からのサービスされていないプルリクエストがあります： https ：//github.com/ghodss/yaml/pulls、コードはMITですライセンス供与。

この依存関係は本当にその重みを引いていますか？ これはいくつかのマーシャリングヘルパーですが、解決すると、多くのプロジェクトがビルド時にパッケージのデフォルトを動的に設定する機能を向上させる可能性がある問題を抱えています（私たちのユースケースは、バージョンタグを格納するために複数の異なる場所を維持する必要がないことです）プロジェクトのチャートと画像のバージョンをロックステップするための--set image.tag=${GIT_TAG}のようなもの）。

もう待たずに、必要なコードを兜にコピーすることを提案できますか（必要に応じて吸収して適応させるだけで、わざわざベンダーに売り込むことはありません）。 このラッパーのメンテナンスを処理するのに十分な大きさのプロジェクトであり、YAMLマーシャリングはコアコンピテンシーだと思います（独自のパーサーをメンテナンスする必要があると言っているわけではありませんが...！）

これが今私たちに苦痛を与えているので（そして私たちがヘルム3.0.2からアップグレードするのを止めているので）私はそれを突き刺して喜んでいます。

私はそのような状況を避けたいと思います。 パッケージマネージャーとYAMLパーサーの両方を維持するのに十分なメンテナーがありません。 それはチームにかなりのメンテナンス負担をもたらします。

@bacongobblerそれはyamlパーサーではありません。 gopkg.in/yaml.v2を使用して実際の解析を行います。 そのパーサーの周りに約900行のreflectラッパーコードがあります。 問題は、この問題を解決するgopkg.in/yaml.v3を使用しないことです。

実際の依存関係のこのマイナーな中間体を使用することのメンテナンスの負担は、このコードのビットを維持することよりも大きな負担であるように私には思えます。

スレッドで前述したように、ghodss/yamlをyaml.v3に更新するPRアップストリームを自由に提案してください。 彼らがそれを受け入れない場合は、プロジェクトをフォークして、メンテナンスの負担を引き受けることができると思われる場合は、プロジェクトをメンテナンスしてください。

ただし、はっきりさせておきます。私たちは、ヘルムにフォークしてベンダーのghodss/yamlを実行するプルリクエストを受け入れません。 1つの機能をサポートするためだけに、Goライブラリ全体の追加のメンテナンス負担を負うことはできません。

@bacongobblerここで私のPRを見てください： https ：//github.com/helm/helm/pull/7963

これは900行のコードであり、テストが含まれ、不要な機能が削除されています。

今、あなたは私がそこに追加したものよりもはるかに大きなフットプリントを持つ比較的メンテナンスされていないライブラリのように見えるものに依存しています。

1つの機能をサポートするためのGoライブラリ全体

このGoライブラリ全体から1つの関数をすべて使用します。これを行うために、コードの出所をさらに曖昧にする永続的なフォークを作成する努力をしました。

メンテナンスの負担がかかると思われる場合は、プロジェクトをフォークしてメンテナンスしてください。

つまり、このコードの単一目的のフォークをすでに実行しているということです。 プロジェクトが放棄された場合、実際には元の作成者によるメンテナンスの恩恵を受けていません。

よろしければ、その少量のコードをPRに取り、それをレポに入れて、それを維持すると言います（そして、そうしようとします）が、それはかなりばかげているようです。

ただし、はっきりさせておきます。Helmにforkおよびvendor ghodss/yamlするプルリクエストは受け付けません。

ちなみに、これを読んだ時点ですでにそのPRをプッシュしていたので、「ベンダー」や「囲碁ライブラリ全体」（よく同意するかもしれません）についてキャッシュされた考えを持っていると思うので、再考してください。 ）関連するコードを見ずに。 しかし、PRで問題の実際のコードについて説明しましょう。 それが役に立ったら、このコードのコード所有者になれることを嬉しく思います。 私が貢献としてそれを書いたと想像してみましょう...私はある種のことをしました。

多分彼らはそれをマージするでしょう： https ：//github.com/ghodss/yaml/pull/62

私が簡単に調べた他の代替案は、他の依存関係を介してYAMLからJSONへの変換を置き換えるか、いくつかの中間形式を介してシリアル化する可​​能性でした。 私はGoエコシステムに精通していないため、これが実行可能なパスであるかどうかを知ることができません。簡単に見てみると、シリアル化タイプのライブラリがこれ以上見つからないことに少し驚いていました。

ヘルムパッケージングを自動化するためにこれを使用するときに、-setをいつ戻すことができるかについてのアイデア。 Helm 3.0.2でしたが、更新がサポートされなくなったためです。

https://github.com/ghodss/yaml/pull/62をマージすることはまだブロックされています。

コードをもう一度見ると、あなたは正しい@lukaslarsonと@maxhillaertです。 ただし、これは、パッケージの値ファイルからすべてのコメントを削除したため、元に戻すことを目的とした機能でした。 Helm 2で削除されましたが、誤ってHelm3に侵入しました。出荷することを意図したものではありませんでした。

コメントを保持する＃3471の再実装に取り​​組みたい場合は、PRを検討させていただきます。

コメントが削除されても問題ありません。--setを使用する際の注意点がある場合は、コメントは気にしません。

ghodss / yaml＃62をマージすることはまだブロックされています。

私は3.0.2を使用して立ち往生していたと思います:(

--setを使用したかどうかに関係なく、3471はコメントを削除したため、この機能を使用したことがないユーザーを壊しました。 これにより、すべてのユーザーの下位互換性が失われました。 したがって、注意して再導入することはできません。そのため、アップストリームでの適切な修正を待っています。

そのため、3.0.2に固執する必要があります

ghodss / yaml＃62をマージすることはまだブロックされています。

しかし、この依存関係はもはや維持されていないように思われるので、フォークバージョンを使用する方が良いのではないでしょうか。

切り替えは良い考えですが、Helm 4に延期する必要があります。Helm4プロセスで追跡できるように、誰かがYAMLパーサーの切り替えに関する特別な問題を提出する必要があります。

ただし、はっきりさせておきます。Helmにforkおよびvendor ghodss/yamlするプルリクエストは受け付けません。 1つの機能をサポートするためだけに、Goライブラリ全体の追加のメンテナンス負担を負うことはできません。

https://github.com/ghodss/yamlが維持されなくなったようで、 https：//github.com/ghodss/yaml/pull/62に生命の兆候がないことを考えると、この位置を再検討する価値はありますか？ https://github.com/helm/helm/pull/7963を再評価しますか？

1つの機能のためだけにYAML解析ライブラリ全体をサポートするというメンテナンスの負担を引き受けることには関心がありません。

コミュニティには、ghodss / yamlの既存のメンテナーと協力して、プロジェクトをサポートしたり、プロジェクトをフォークしたり、コメントを保存できる新しいライブラリを見つけたりすることをいとわない新しいメンテナーのセットを見つけることを検討することをお勧めします。

それで、それは何でしょうか？

• ghodss / YAMLをサポートする新しいメンテナを見つけてください！？
• ghodss / YAMLをフォークしてYAML.v3を使用する人を見つけてください（そしてそれを引き続きサポートしてください）!!
• YAML.v3を直接使用する
• ヘルム4のYAMLパーサーを切り替えることを提案する

YAML解析ライブラリ全体

これは、ここに含まれるコードの範囲を誤って伝えています。 これは、他のパーサーのラッパーです。

1つの機能のためだけにYAML解析ライブラリ全体をサポートするというメンテナンスの負担を引き受けることには関心がありません。

おそらく、この混乱は多くのことを説明しています-パーサーはhttps://github.com/go-yaml/yamlであり、ghodss/YAMLではありません。 https://github.com/ghodss/yamlから：

go-yamlのラッパー

したがって、簡単な解決策は次のとおりです。ラッパーの使用を停止するだけです。

「ラッパー」は、いくつかの動作に大きな影響を与えます。 プロジェクトの早い段階でパーサー（およびラッパーライブラリ）を数回切り替えた後、コアメンテナは、パーサー（およびラッパーライブラリ）間の小さな不一致、つまりそれらが高レベルの互換性の問題を引き起こす方法を痛感しています。

ghodss / yamlのフォークの使用を検討する可能性があるのは、そのフォークの所有者が継続的なメンテナンスを約束した場合のみです。

おそらく私はもっと正確にすることができます-放棄されたラッパーライブラリの使用をやめ、ヘルムで同等/同一のラッピング動作を行います。これは、 https：//github.com/helm/helm/pull/7963が約250LOCプラスで行うことです。テスト。

はい、理想的には代わりに誰かがghodss / yamlで修正しますが、それはもはや維持されていません。 確かに、代替案はヘルム4まで待っていませんか？

フォークはおそらく最良の選択肢だと思います、IMO。 @ghodssは2019年の初め以来、GHで何の活動もしていないようで、リポジトリへの最後のコミットは1年半前（@bradfitzによる）でした。 最後の（唯一の）リリースは2017年でした。コードに潜在的なセキュリティの問題がある場合、メインで修正されることはありません。

誰かがフォークを維持することをいとわないのであれば、フォークを採用することを強くお勧めします。 瀕死の放棄されたパッケージを使い続けることに比べて、マイナス面は見られません。 別のラッパーに移動することは、大きな変更としてより理にかなっていることに同意します（Helm 4のものになる可能性があるほど重いリフトのようですが、これ以上推測するつもりはありません）が、これは解決できると思いますgo.modにreplace行があります。

他の誰かがフォークを共同で維持するのを手伝うことを約束します。 現在、自分でそれを行うのに十分な帯域幅がありませんが、貢献するのに十分です。

確かに、私はこれに主に興味があるので、Helmチャートをパッケージ化するためのsedスクリプトの山を取り除くことができますが、それが必要な場合はそうです。

こんにちは
パッケージ化時に値を設定できるプラグインを作成しました。 今のところ、 setフラグをサポートしているだけですが（：sweat_smile：が必要だったため）、他のフラグを追加するつもりです。 よろしければPRをプッシュするか、それを改善するためにコメントを追加することを躊躇しないでください。
ありがとう

誰かがフォローしていない場合に備えて、ghodss / yaml＃62がメンテナに連絡するのにある程度の進展があったので、すぐにいくつかの良いニュースが聞こえることを願っています！

この問題は、アクティビティがない状態で90日間開いているため、古いものとしてマークされています。 それ以上のアクティビティが発生しない場合、このスレッドは30日後に自動的に閉じられます。

間違いなく古くない。 私はhttps://github.com/ghodss/yaml/pull/62でフォローアップする時間を見つけて、この問題の進行をブロック解除するためにそれをマージするのに役立つかどうかを確認しようとしています。 私の組織がHelmへの依存度を高めているため、CIごとのビルドパッケージチャートに値をベイクできるようにしたいと考えています。

手元の会話に何も追加されないため、ステータスの更新を要求するコメントを削除しました。 @jmcelwainは、5日以上前にステータスの更新を提供しました（ありがとう、ところで）。 前述のように、この問題の解決策はトリッキーであり、いくつかの依存関係を更新またはフォークする必要があるため、ある程度のデューデリジェンスが必要です。

共有する情報が増えたら、スレッドを更新します。

回避策として、 https：//github.com/mikefarah/yqを使用して、パッケージ化する前にヘルムチャートを更新しました。

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

CIでは、アプリ/ Dockerイメージとチャートを同じパイプラインで構築します（アプリとチャートが同じバージョン管理で進化することを保証するため）。 チャートのデフォルト値は、以前に作成されたイメージのバージョンによって異なります。

yqの回避策はパイプラインに簡単に統合できますが、このユースケースがヘルムで正しくカバーされていないのは奇妙に思えます。

したがって、パッケージフェーズ中/パッケージフェーズの前にimage.tagを設定するためのhelmとの統合された方法はありませんか？

編集：私の場合、この解決策が見つかりました。チャートを同じバージョンでパッケージ化するため、画像タグにChart.AppVersionを使用する必要があります。

編集2 ：Chart.AppVersion /共有チャートでは機能しません（複数のアンブレラチャートで使用されるスプリングブートチャートを説明します）

私の結論：パッケージフェーズ中にimage.tagを設定する必要があります

この機能に関するニュースはありますか？