Replies: 1 comment
-
|
I recommend using Flux image automation with dedicated branches from where you open PRs, then you decide when to merge them.
You can also run Flux image automation in an ephemeral Kubernetes Kind cluster in CI. Example here:
Flux source-controller fetches tags, the registry API for tag listing does not contain a timestamp only the tag string. The OCI specification has no concept of timestamps for tags so it's not possible to do this unless we download the whole artifact for each tag, which would generate a huge amount of traffic and will result in Flux being rate limited by most registries. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Due to supply chain issues, I'd like to have a small delay in updating most releases in one of our clusters. There should still be automatic updates.
I don't want to pin the dependencies (although with something like renovate, kustomize magic, and additional complexity that might also work), because the configuration between different clusters would be different.
Do you think that feature request makes sense?
I see two ways of specifying it.
A field in
Kustomization, that only considers releases older than the specified age in all subsequent repositories (OCI, Helm). I would argue that's the most convenient spot to set that setting.Or a field in
HelmRepositoryandOCIRepository(I don't think it makes sense inGitRepositories) that specifies the minimum age of the repository. Arguably it belongs to that part, because it's the source of the artifacts.In either way it should have a mean to override the delay, e.g. for security updates that are vetted manually.
What do you think?
Beta Was this translation helpful? Give feedback.
All reactions