mirror of https://github.com/pulumi/pulumi.git
7a173bedac
11456: Implement YAML roundtripping, comment preserving edits r=AaronFriel a=AaronFriel By caching a copy of the raw bytes of the original loaded document - project, policy project, or stack - on save we: * Unmarshal the original bytes to a YAML AST * Recursively edit nodes of the document to match the values of the value we're saving, preserving trivia * Marshal the modified AST to []byte Closes #423, as we don't support comments in JSON presently (not using "JSON5") Closes #5235 Simplifies work done in #10797 and #10437 which used the previous `yamlutil` package to edit AST nodes directly. # Automation API Integration with automation API requires that operations either perform a "read-modify-write" in a single operation, or use a side channel to allow subsequent "read" (select stack?) and "write" operations to keep state of the original file. However I don't expect this to be needed. We don't have a reason to believe automation API users maintain comments in particular stack files, and doing so is already unsupported in automation scenarios. The Pulumi Service does not persist raw config files, thus `pulumi config refresh` and `CreateOrSelectStack` create config files without comments. n.b.: If you test this, due to the new behavior of this PR, `pulumi config refresh` will persist comments if there is an existing config file. I would expect automation API using local file workspaces to behave similarly. When using these tools to create a config file from the last deployment's definition, the file is created restored without comments. # Tradeoffs I believe that this closes #423 in spirit, but doesn't strictly implement round-tripping. There are a couple reasons for this. ## Marshaller interface and round-tripping simplification decisions We support unmarshaling "simplified" YAML, including allowing: ```yaml runtime: yaml # this unmarshals to a struct, not a scalar value config: someKey: "someScalar" # likewise ``` These simplifications make it much more difficult, the `Marshal` operation would _also_ need context of decisions made when unmarshaling to ensure a bijection. Otherwise we may save one of these as the other: ```yaml runtime: name: yaml ``` ```yaml runtime: yaml ``` This could be considered a feature, as it enforces a style guide - the decisions implemented in our custom `Marshaller` implementations become the style enforced on save. That said, I believe the new `Edit` API while not round-trippable, does reach a fixed point after one save through the new API. Once saved with this API, subsequent loads & saves without changes are idempotent. ## Indentation The YAML library uses a global indentation when marshaling values to YAML, as opposed to indentation being a property of AST nodes. This means we may lose other indentation. Co-authored-by: Aaron Friel <mayreply@aaronfriel.com> |
||
|---|---|---|
| .. | ||
| dotnet | ||
| go | ||
| nodejs | ||
| proto | ||
| python | ||
| README.md | ||
| go.mod | ||
| go.sum | ||