fix(cert-manager): do not emit an empty helm parameters key - #225
Merged
Conversation
On a provider that is neither aws nor azure, and with no git provenance injected, every entry under `parameters:` is skipped and the key renders with nothing beneath it. The API server reads that as null and rejects the Application outright: spec.sources[0].helm.parameters in body must be of type array: "null" The whole platform-root sync then fails, not just cert-manager, because one object failing to apply fails the operation. This could not surface while aws and azure were the only providers: each always contributes its identity annotation, so the block was never empty. Found on a DigitalOcean cluster, where cert-manager needs no ServiceAccount annotation at all — there is no cloud identity to attach. Rendering for aws and azure is byte-identical to v0.73.0.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Num provider que não é
awsnemazure, e sem provenance de git injetada, toda entrada sobparameters:é pulada e a chave renderiza vazia. O API server lê isso como null e recusa a Application:E o sync inteiro do platform-root falha junto — um objeto que não aplica reprova a operação, não só o seu próprio Application.
Por que nunca apareceu
Enquanto
awseazureeram os únicos providers, cada um sempre contribuía a anotação de identidade (IRSA / Workload Identity), então o bloco nunca ficava vazio. O helper de provenance também fica em silêncio quando não há provenance.Encontrado num cluster DigitalOcean real, onde o cert-manager não precisa de anotação nenhuma na ServiceAccount — não há identidade de nuvem para pendurar.
A correção
A chave só é emitida quando há algo para pôr embaixo dela.
parametersé opcional na CRD, mas uma vazia não é o mesmo que ausente.Sem regressão