fix(platform-outputs): actually derive the version the variables promise - #224
Merged
Merged
Conversation
Both variable descriptions say to leave the value empty and the module will derive it from the VERSION file at the cloned source ref. It did not. The derivation lives in providers/aws and providers/azure, which read the file and pass the result in — so a caller consuming modules/platform-outputs directly got an empty string and a description telling them that was the recommended path. Empty is not harmless here. platform-root uses platformVersion as the targetRevision of its $values source, so it resolves to nothing and every child Application fails on a value file it cannot read. The module sits two directories below the repository root, the same depth as providers/<name>, so the relative path is the one those providers already use. Guarded with fileexists rather than a bare file(): vendoring this directory alone should degrade to the old behaviour, not fail the plan. Explicit input still wins, so every existing caller is unchanged.
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.
As descrições de
platform_versioneplatform_revisiondizem para deixar vazio que o módulo deriva do arquivoVERSIONno ref clonado. Ele não derivava.A derivação vive em
providers/awseproviders/azure, que leem o arquivo e passam o resultado. Quem consomemodules/platform-outputsdiretamente recebia string vazia — e uma descrição dizendo que esse era o caminho recomendado.Por que vazio não é inofensivo
platform-rootusaplatformVersioncomotargetRevisionda própria source$values. Vazio resolve para nada, e toda Application filha falha num value file que não consegue ler.Foi encontrado assim: consumindo o módulo direto num deployment DigitalOcean, o ConfigMap de handoff saiu com
platformVersionvazio.A correção
O módulo está dois diretórios abaixo da raiz do repo — mesma profundidade de
providers/<name>— então o caminho relativo é o mesmo que aqueles providers já usam.Guardado com
fileexistsem vez defile()puro: quem vendorizar só este diretório não temVERSIONacima, e isso deve degradar para o comportamento anterior em vez de quebrar o plan.Compatibilidade
Entrada explícita continua vencendo.
providers/aws/main.tf:115passalocal.module_version, então segue idêntico. Ninguém que já passa o valor muda de comportamento.Divulgação: fui eu que introduzi isso ao extrair o módulo na v0.73.0 — trouxe a descrição do nível do provider e deixei a lógica para trás.