Enable workaround for using objects in config#449
Open
AaronFriel wants to merge 1 commit intomainfrom
Open
Conversation
iwahbe
approved these changes
Apr 24, 2023
Member
iwahbe
left a comment
There was a problem hiding this comment.
Can we add a test to confirm that this works and to document desired behavior?
I'm happy to merge here if there is a test in place.
Contributor
Author
|
@iwahbe Test fixed & test added. |
abhinav
approved these changes
Apr 24, 2023
Contributor
abhinav
left a comment
There was a problem hiding this comment.
Makes sense. foo.bar for a foo: Any should return an Any.
The type checker is modified to make property access on 'Any' return 'Any', which enables workarounds for #434 using programs like below. Unblocking this sans workaround will require further implementation of these issues to support more complex structured, hierarchical config: - pulumi/pulumi#1052 - pulumi/pulumi#2307 The workaround program is: ```yaml name: tmp.0T7TLEvBj8 runtime: yaml description: A minimal Pulumi YAML program variables: myObject: fn::secret: fn::std:jsondecode: input: fn::fromBase64: ${myJSON} outputs: test: ${myObject.result.test.password} ``` In this workaround we: 1. Base64 encode the JSON object we want to use in Pulumi YAML. This is necessary because Pulumi will attempt to JSON decode the value of config variables into objects on our behalf. ```sh pulumi config set --secret \ myJSON \ $(printf '{ "test": { "password": "secretpassword123" } }' | base64) ``` 2. Use `fn::fromBase64` to decode that string into its original value. 3. Use `fn::std:jsondecode` to convert that string to an object. 4. Use `fn::secret` to ensure the value is marked as a secret. (Experimentally, this was necessary.) The code change in the analyzer is necessary to allow indexing into the `Any` type on `${myObject.result}`.
Contributor
Author
|
I've opened #451 to resolve the failing integration tests. |
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
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.
The type checker is modified to make property access on 'Any' return 'Any', which enables workarounds for #434 using programs like below.
Unblocking this sans workaround will require further implementation of these issues to support more complex structured, hierarchical config:
The workaround program is:
In this workaround we:
Base64 encode the JSON object we want to use in Pulumi YAML. This is necessary because Pulumi will attempt to JSON decode the value of config variables into objects on our behalf.
sh pulumi config set --secret \ myJSON \ $(printf '{ "test": { "password": "secretpassword123" } }' | base64)Use
fn::fromBase64to decode that string into its original value.Use
fn::std:jsondecodeto convert that string to an object.Use
fn::secretto ensure the value is marked as a secret. (Experimentally, this was necessary.)The code change in the analyzer is necessary to allow indexing into the
Anytype on${myObject.result}.