fail e proteções de validação personalizadas

Os pacotes devem rejeitar configurações sem sentido logo no início. Um bom modelo pode interromper a renderização e informar ao usuário exatamente o que deu errado.

A função fail interrompe imediatamente a renderização do modelo e exibe como erro a mensagem fornecida por você.

Envolva fail em um if para que ele só seja acionado quando um valor estiver ausente ou for inválido, sem afetar instalações válidas.

Para um único valor obrigatório, required é mais simples: ele retorna o valor ou falha com a sua mensagem quando o valor está vazio.

Use required para exigir diretamente um único valor e fail quando a verificação envolver várias condições ou precisar de lógica personalizada.

Você pode verificar se um valor pertence a um conjunto permitido, falhando claramente quando o usuário escolhe algo não compatível.

Escreva a mensagem de falha como uma orientação: informe o valor e a correção necessária para que o usuário não precise adivinhar por que a instalação parou.

Algumas regras envolvem dois campos. Uma validação pode falhar quando um recurso habilitado não tiver o valor complementar de que depende.

Colocar a validação em um modelo nomeado dentro de _helpers.tpl mantém as verificações em um só lugar, fora dos arquivos de recursos.

Execute helm template com valores inválidos para confirmar que cada validação seja acionada com uma mensagem clara antes que qualquer coisa chegue ao cluster.

Para regras de tipo e intervalo, um arquivo values.schema.json complementa fail ao rejeitar entradas inválidas antes mesmo de qualquer modelo ser executado.

Faça uma verificação rápida sobre os auxiliares de validação.

Você aprendeu a interromper instalações inválidas logo no início: use fail para validações personalizadas com várias condições e required para valores únicos obrigatórios. 🎉