相关请求：#2566

我已经开始了这方面的工作。
考虑到 #2566 上的评论，我们是在寻找 --values 还是 --set （或两者兼而有之？）

我打开的问题（#3198）中描述了一个很好的用例，我希望能够做到：

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

这样，chart 版本和 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 “壮举：将 --set 和 --values 选项添加到 'helm package'” https://github.com/helm/helm/commit/7b8aa ​​e466761448522acbd3beb2a16ad2283013a

有这方面的消息吗？
谢谢

同上； 没有人进行后续工作以修复 #3471 中的错误，因此尚未实施。 如果您同意从值文件中删除注释，那么非常欢迎您分叉 Helm 并针对 #3471 进行编译。

这完成了吗？ 我尝试了2.11.0和2.12.0版本，它们似乎都没有helm package --set...

+1。 它真的会帮助我们在 CI 中停止在打包之前对值的 yamls 进行粘贴和升级。

+1

--set-string 也很有用，为什么不允许安装/升级中存在的所有覆盖选项。
只需执行用于覆盖包命令的值的相同代码，包将具有覆盖值是有道理的 - 这些标志应该像安装/升级一样共享。

2.13.1也没有这个功能，有时间表吗？

如前所述，目前没有人致力于此工作，并且没有时间表确定何时可以进行修复。 随意拿这个。 看看#3471 的想法。

在 Helm 3 中实现。 关闭！

查看代码，似乎 #3471 意外进入了 Helm 3，但由于以下评论，我们从未像我们为 Helm 2 所做的那样退出： https ://github.com/helm/helm/pull/3471#issuecomment -381779783

我正在重新打开此功能请求，因为我们正在使用https://github.com/helm/helm/pull/7201 删除 Helm 3 中的 --set 和 --values 标志。 他们从来没有工作过......任何通过--set或--values设置的东西都不会注入到包中，并且它引入了一些致命的回归helm package ，即它剥离的事实从 values.yaml 中删除评论，一些社区成员将其用作文档。

也许我误解了，但我很高兴使用 --set 和包来设置值，它从 3.0.0 到 3.0.2 工作得很好，绝对不是 #7201 中描述的“无操作”。

我的管道从 3.0.3 开始就坏了。 这在 3.0.2 中有效。 如果我们有 --version 和 --app-version，为什么这不被认为是有用的。 我们应该如何编辑图像和标签以匹配--app-version？ 重击？

再次查看代码，您是正确的@lukaslarson和@maxhillaert。 但是，这仍然是一个旨在恢复的功能，因为它从包的值文件中删除了所有注释。 它在 Helm 2 中被移除，但意外地进入了 Helm 3。它从未打算被运送。

如果有人想重新实现保留评论的#3471，我们很乐意查看 PR。

@bacongobbler这为我们破坏了一些东西。 我有兴趣从事公关工作，但这似乎并不简单，所以我想检查一下这种方法。

看起来gopkg.in/yaml.v3支持往返时保留评论。 我的建议是使Values成为 yaml Node 。 然后，在合并值时，遍历已解析输出的树而不是嵌套映射。 这当然不太符合人体工程学，但却是保留评论的最佳方式。

这有点问题，因为我们在任何地方都使用sigs.k8s.io/yaml ，它被固定到底层库的v2上。 至少，这需要将其作为单独的依赖项引入，这有点糟糕。 不确定这里最好的方法是避免接触与 yaml 打交道的所有内容。

最好的选择似乎是迁移到 yaml.v3，所以听起来您走在正确的轨道上。

如果你想开始使用 yaml.v3 而不是 sig.k8s.io/yaml 的 Helm 的 PoC/fork，那将是一条很好的前进道路。 这样，我们就可以开始评估它与master中的功能相比的功能。

一旦我们确定 yaml.v3 是前进的最佳途径，我们就可以从 SDK 的角度找出如何着手。

这有助于解除封锁吗？

@jmcelwain您是否正在积极研究这个？ 如果没有，我很乐意接手。

@sreya92工作很忙。 这是我停下来的地方：切换到 yaml.v3 非常容易，除了这里的这一点。 不确定处理此问题的最佳方法是什么，而不是出售依赖项并将其更新到 v3。

看起来有一些工作要升级，但问题等中没有其他信息，我也没有费心打开问题。 另一种选择是只保留两个依赖项，但这似乎很糟糕。

我个人的看法是，这是这个问题的一个障碍，除非维护者认为携带两个类似库的副本是值得的。 不确定 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}来锁定项目的图表和图像版本）。

我可以建议我们不要再等了，只需将必要的代码复制到 helm 中（我不会费心出售它，只是根据需要吸收和适应）。 我认为这是一个足够大的项目来处理这个包装器的维护，并且 YAML 编组是一项核心能力（不是说你应该维护自己的解析器，但是......！）

由于这正在给我们带来痛苦（并阻止我们从 helm 3.0.2 升级），我很乐意尝试一下。

我宁愿避免这种情况。 没有足够的维护者来维护包管理器和 YAML 解析器。 这会给团队带来巨大的维护负担。

@bacongobbler它_不是_ yaml 解析器。 它使用gopkg.in/yaml.v2来进行实际的解析。 该解析器周围有大约 900 行reflect包装器代码。 问题是他们不使用可以解决此问题的gopkg.in/yaml.v3 。

在我看来，使用这个次要中间体对你的实际依赖项的维护负担比维护这段代码的负担更大。

如线程前面所述，请随时提出 PR 上游，将 ghodss/yaml 更新为 yaml.v3。 如果他们不接受它，如果您觉得可以承担维护负担，请随意分叉项目并维护它。

不过让我明确一点：我们_不会_接受将供应商 ghodss/yaml 分叉到 Helm 的拉取请求。 我们不能仅仅为了支持一个特性就承担整个 Go 库的额外维护负担。

@bacongobbler请在此处查看我的 PR： https ://github.com/helm/helm/pull/7963

它是 900 行代码，包含测试并删除了多余的功能。

现在，您依赖于看起来像一个相对未维护的库，其占用空间比我在其中添加的要大得多。

一个完整的 Go 库只是为了支持一个特性

你使用了整个 Go 库中的所有一个函数，为了做到这一点，你已经努力创建一个永久分支，进一步模糊了代码的来源。

如果您觉得可以承担维护负担，请随意分叉项目并进行维护。

我的意思是您已经运行了此代码的单一用途分支。 如果项目被放弃，那么您实际上并没有从原作者的任何维护中受益。

如果您愿意，我可以在我的 PR 中获取少量代码并将其放在一个 repo 中并说我会维护它（我会尝试这样做），但这似乎很愚蠢。

不过让我明确一点：我们不会接受将供应商 ghodss/yaml 分叉到 Helm 的拉取请求。

作为记录，我在阅读本文时已经推送了 PR，所以我希望你能重新考虑，因为我认为你对“供应商”和“整个 Go 库”有一个缓存的想法（我可能经常同意) 无需查看所涉及的代码。 但是让我们在 PR 上讨论有问题的实际代码。 如果有帮助，我很高兴成为此代码的代码所有者。 让我们想象一下我把它写成一个贡献......我确实做到了。

也许他们会合并它： https ://github.com/ghodss/yaml/pull/62

我简要探讨的另一种选择是通过一些其他依赖项或通过一些中间格式序列化替换 YAML 到 JSON 转换的可能性。 我对 Go 生态系统不够熟悉，不知道这是否是一条可行的道路——当我简要地看时，我有点惊讶我找不到更多的序列化类型的库。

当我们使用它来自动化 helm 打包时，任何关于何时可以恢复 --set 的想法。 它在 Helm 3.0.2 中，现在不再支持更新。

我们仍然无法合并https://github.com/ghodss/yaml/pull/62 。

再次查看代码，您是正确的@lukaslarson和@maxhillaert。 但是，这仍然是一个旨在恢复的功能，因为它从包的值文件中删除了所有注释。 它在 Helm 2 中被移除，但意外地进入了 Helm 3。它从未打算被运送。

如果有人想重新实现保留评论的#3471，我们很乐意查看 PR。

是否删除评论是否重要，如果有使用 --set 的警告，我不关心评论。

我们仍然无法合并ghodss/yaml#62 。

我猜是坚持使用 3.0.2 :(

无论您是否使用--set ，3471 都会删除评论，因此它破坏了从未使用此功能的用户。 它打破了每个人的向后兼容性。 因此，它不能被重新引入警告，这就是为什么我们在上游等待适当的修复。

这就是为什么我们必须坚持 3.0.2

我们仍然无法合并ghodss/yaml#62 。

但是由于似乎不再维护这种依赖关系，所以使用分叉版本可能会更好，不是吗？

切换这是个好主意——但必须推迟到 Helm 4。有人应该提交一个关于切换 YAML 解析器的特殊问题，以便我们可以跟踪 Helm 4 进程。

不过让我明确一点：我们不会接受将供应商 ghodss/yaml 分叉到 Helm 的拉取请求。 我们不能仅仅为了支持一个特性就承担整个 Go 库的额外维护负担。

鉴于似乎不再维护https://github.com/ghodss/yaml ，并且 https://github.com/ghodss/yaml/pull/62上没有生命迹象，是否值得重新考虑这个位置，并且重新评估https://github.com/helm/helm/pull/7963 ？

我们对仅仅为一个特性承担支持整个 YAML 解析库的维护负担不感兴趣。

我会敦促社区考虑与 ghodss/yaml 的现有维护者合作，寻找一组愿意支持该项目的新维护者，分叉该项目，或者找到一个可以保存评论的新库。

那会是什么？

• 寻找新的维护者来支持 ghodss/YAML ！？
• 找人 fork ghodss/YAML 并使用 YAML.v3（并继续支持它）！！
• 直接使用 YAML.v3
• 建议为 helm 4 切换 YAML 解析器

一个完整的 YAML 解析库

这歪曲了此处涉及的代码的范围。 它是其他解析器的一些包装器。

我们对仅仅为一个特性承担支持整个 YAML 解析库的维护负担不感兴趣。

也许这种混乱解释了很多 - 解析器是https://github.com/go-yaml/yaml ，而不是 ghodss/YAML。 来自https://github.com/ghodss/yaml ：

go-yaml 的封装

所以简单的解决方案是：停止使用包装器。

“包装器”对某些行为有深远的影响。 在项目早期多次切换解析器（和包装库）后，核心维护者敏锐地意识到它们之间的细微差异，以及这些差异如何产生高级兼容性问题。

我们有可能考虑使用 ghodss/yaml 的分叉，如果且仅当该分叉的所有者承诺继续维护时。

也许我可以更精确 - 停止使用废弃的包装器库，并在 helm 中执行等效/相同的包装行为，这就是https://github.com/helm/helm/pull/7963在大约 ~250 LOC 中所做的测试。

是的，理想情况下，有人会在 ghodss/yaml 中进行修复，但它不再维护。 当然替代方案不是等到 Helm 4 吗？

我认为分叉可能是最好的选择，IMO； 自 2019 年初以来， @ghodss似乎在 GH 上没有任何活动，最后一次提交回购协议是一年半前（@bradfitz）。 最后一个（唯一的）版本是在 2017 年。如果代码中存在任何潜在的安全问题，它们将不会在 main 上得到修复。

如果有人愿意维护它，我强烈主张采用分叉； 相对于继续使用垂死的和废弃的包裹，我没有看到任何不利之处。 我同意移动到不同的包装器作为一个重大变化更有意义（似乎是一个足够重的提升，它很容易成为 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 解决方法可以很容易地集成到管道中，但是 helm 没有正确覆盖这个用例似乎很奇怪！

所以它们不是与 helm 集成的方式来在包阶段/之前设置 image.tag 吗？

编辑：在我的情况下找到了这个解决方案，我们需要使用 Chart.AppVersion 作为图像标签，因为我们使用相同的版本来打包图表。

编辑 2 ：Chart.AppVersion / 不适用于共享图表（exp 用于多个伞形图表的 spring-boot 图表）

我的结论：确实需要在打包阶段设置 image.tag

有关此功能的任何消息？