This doesn't support injecting digests where they don't already exist, so it is not fully #8089 .
I'm using this test repository: https://github.com/thepwagner/renovate-kustomize-image-digests
Kustomize images are complicated, the updated README contains several example possibilities. Renovate's implementation was limited to updating the
Edge cases exist when the user has provided additional information that kustomize won't use. Those are skipped, with a warning logged:
- name: quay.io/argoproj/argocd newTag: v2.0.5-moot # does not matter because digest is provided digest: sha256:b53a2f76f949849cbe7e0b1e343a2076c7f205cfcfe8116e461e6861369fa81f
There's a bias towards formats that provide the version+digest within a single YAML value:
- name: quay.io/argoproj/argocd newTag: v2.0.5@sha256:b53a2f76f949849cbe7e0b1e343a2076c7f205cfcfe8116e461e6861369fa81f - name: quay.io/argoproj/argocd newName: email@example.com@sha256:b53a2f76f949849cbe7e0b1e343a2076c7f205cfcfe8116e461e6861369fa81f - name: quay.io/argoproj/argocd newName: custom/argo newTag: v2.0.5@sha256:b53a2f76f949849cbe7e0b1e343a2076c7f205cfcfe8116e461e6861369fa81f
So this is not #8089 , but it is enough for my use case and should be backwards compatible.
Documentation (please check one with an [x])
How I've tested my work (please tick one)
I have verified these changes via:
The text was updated successfully, but these errors were encountered:
If I understand correctly,
What I'm not sure is: is it the current digest for the existing tag (in which case the result is fully correct) or is it selecting the digest of the latest tag?
I'd really like to update both, but ok with a mid step if it improves the situation. I'm a big fan of having both the informative tag plus synced normative digest.
Also, would it be reasonable to support the combined tag@digest approach only and document that, if users want both updated in lockstep?
@rarkins Yep, your assumptions are correct. When
With this proposed implementation+example, I think the latter: since the
This is definitely a mid-step; I was working on a solution that maintained both, but it awkwardly parsed the
I think that's the most reasonable middle ground, it's the compromise I was willing to make! I can take this PR in that direction.
Thanks for the feedback!
I would prefer to avoid this behavior, because I think it's downside is far worse than what we have today. Today, we can mislead people that they updated from version X to version X+1 but actually nothing changed. In other words, they stay on a version which hopefully works.
With this PR's change, we could be updating them to a completely non-working version for them, because sometimes
Have I understood correctly and do you agree?
I think this is definitely best. I would only like to do a digest update if it matches
What if we intentionally skipped any extracted dependency which has both newTag and digest in separate fields and logged a warning that it's unsupported? i.e. support only one field at a time.
Considering how small these YAML files should be, we shouldn't be concerned with "optimization" of two parse-throughs. But if you think the logic itself is too convoluted then it's another matter.
Would that align with what I suggested earlier about intentionally skipping extracted deps with both fields defined?
(And let's open a new issue for the advanced case of both fields present, so that one day someone may work out how to elegantly achieve it)
I think warning is best.
I think that's the only one we need.
This PR is still in progress - I'll edit the OP and mark RFR when it is.
But an update: I've ported most of _viceice's cases to https://github.com/thepwagner/renovate-kustomize-image-digests.
Yep! Sorry, I should have mentioned that. I liked the pattern of a regex to match multiple YAML keys. I figured that pattern would need to include
That's what sent me look at pre-splitting the
I abandoned the latter approach as
- newTag: 3.12.2 name: alpine digest: sha256:25f5332d060da2c7ea2c8a85d2eac623bd0b5f97d508b165f846c7d172897438 - digest: sha256:e1488cb900233d035575f0a7787448cb1fa93bed0ccc0d4efc1963d7d72a8f17 newTag: 1.32.1 name: busybox:1.30.0 - newName: amd64/busybox:1.30.1 name: busybox digest: sha256:e1488cb900233d035575f0a7787448cb1fa93bed0ccc0d4efc1963d7d72a8f17
So when I realized