Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable workaround for using objects in config #449

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

AaronFriel
Copy link
Contributor

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:

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}.

Copy link
Member

@iwahbe iwahbe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@AaronFriel
Copy link
Contributor Author

@iwahbe Test fixed & test added.

Copy link
Contributor

@abhinav abhinav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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}`.
@AaronFriel
Copy link
Contributor Author

I've opened #451 to resolve the failing integration tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants