test(feat): rudimentary values go/yaml synchronization enforcement #12657
Conversation
|
If I'm reading this correctly, this test will fail whenever either the values.yaml or values.go files change (and so we'll have to regenerate the golden file when either of them change). But this means that a change that properly updates both files will necessarily fail. A test failure only indicates that you have touched the files and haven't run the update command. Is this valuable? To my understanding, this continues to put the onus on the reviewer to ensure that the data structure and config file are actually kept in sync. Simply rerunning the test command with -update (as is the standard practice) will resolve the failure, and allow the inconsistency to persist. |
You are reading it correctly
Honestly, I'm not sure? In theory, the same argument could be applied to all the golden file based tests so it's tough to say 100% one way or the other. The desire to shift out-of-sync detection leftward was a not-inconsiderable part of the conversation that sparked the idea though, so I'd argue that from that perspective at least there's some value to it as a guardrail of sorts (even if it's arguably a bit of a flimsy guardrail). That's also why I called it out as a PoC and filed the PR as a draft though, kind of a "this works, but it ain't great and I bet we can do better; let's talk about it" sort of deal 😅 |
PR is a rudimentary PoC for using the test suite to enforce synchronization between
values.goandvalues.yamlfiles