我刚刚阅读https://docs.fluxcd.io/projects/helm-operator/en/stable/helmrelease-guide/debugging/#manually-performing-a-release-to-debug以及常见问题解答，但无法不知道如何触发 HelmRelease 的重试。
我的解决方法是对监视的版本存储库提交一个无关紧要的更改，只是为了让 helmoperator 获取差异。有没有更好的办法？
我正在尝试在我们公司引入 GitOps。大多数情况下，我们都有用 Django 编写的微服务（但是，它也可以是任何其他 Web 框架）。我对数据库迁移有一个概念性问题。向前迁移很简单：您可以将它们作为作业或 init 容器或 helm 中的钩子来运行。但是向后迁移呢？假设我想从 v1.1 回滚到 v1.0，并且我有一些迁移需要取消应用。现在怎么办？我想使用 argo cd 或 Flux。
有一篇非常好的文章：https://www.weave.works/blog/how-to- Correctly-handle-db-schemas-during-kubernetes-rollouts 。然而，它需要一些 Django 中没有的纪律
我已经使用Flux v2设置了持续交付管道（因为 Flux v1 已弃用），并且运行良好。另一方面，我看到 Argo 和 Flux 在 2019 年底开始合并（请检查此链接）。
我想知道 Flux v2 是否是 Argo-Flux 合并的演变，或者它们是两个独立的 GitOps 实现选项。
我的印象是 Flux v2 非常活跃，所以我想它是一个真正的选择，并且至少会存在一段时间。但我对 Argo-Flux 不了解，也找不到太多信息。
谢谢！
continuous-deployment continuous-delivery argoproj fluxcd gitops
我有以下图像政策：
apiVersion: image.toolkit.fluxcd.io/v1alpha2
kind: ImagePolicy
metadata:
name: cps-kul-beta-imagepolicy
namespace: flux-system
spec:
imageRepositoryRef:
name: cps-kul-image
filterTags:
pattern: '^sha-(?P<ts>.*)-.+'
extract: '$ts'
policy:
numerical:
order: asc
version list argument cannot be empty在该对象上执行 kubectl describe 时出现错误。
在我的集群中，我使用weave Flux及其 Flux-helm-operator 以 gitops 方式管理我的集群。
然而，当我对 Flux git 存储库中的图表进行更改时，我经常遇到以下错误消息：
ts=2019-09-25T11:54:37.604506452Z caller=chartsync.go:328 component=chartsync
warning="unable to proceed with release"
resource=mychart:helmrelease/mychart release=mychart
err="release requires a rollback before it can be upgraded (FAILED)"
我不确定这在 helm 中意味着什么，但无论如何，我不应该运行任何 helm 命令，因为版本是由 Flux 管理的，所以我想知道在生产中处理此错误的正确方法是什么
（除了删除版本并等待 Flux 重新创建它之外）
一个解释清楚的答案将被非常接受，谢谢。