Commit Graph

6 Commits

Author SHA1 Message Date
Pat Gavlin 53e80f7e65
[config] Clean up toDecryptedPropertyValue ()
- Plumb a `context.Context` parameter to pass to the decrypter
- Rephrase conversion over `config.Plaintext` values in order to
decouple decryption and conversion
2023-11-16 17:55:14 +00:00
Thomas Gummerer 6d5f2ff0b2
fix panic when we have a nil object ()
In some cases we construct a nil object, which isn't handled properly
when we convert it into a property value. This is likely related to
https://github.com/pulumi/pulumi/issues/14146, where we started allowing
such objects as a fix for a similar, but separate issue.

Fixes 

## Checklist

- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
  - [x] I have formatted my code using `gofumpt`

<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!--- 
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-10-24 16:22:03 +00:00
Thomas Gummerer 80acb16a54
pass through property values to RunRequest ()
# Description

This is an alternative to https://github.com/pulumi/pulumi/pull/14244.
Instead of adding type information to the run request, pass the config
through as property values. Property values are properly encoded on the
wire, and can be unmarshalled on the other end including type
information, so this should be a more future proof way to go forward.

Eventually we'll want to parse the config directly into property values,
but that can be left for the future, as it's a bigger change.

## Checklist

- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
  - [x] I have formatted my code using `gofumpt`

<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!--- 
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-10-20 10:44:16 +00:00
Thomas Gummerer bf76b6c525
ignore unexpected types instead of erroring out ()
Before , when we encountered unexpected types in a yaml file, we
ignored them. However that PR changed that, and we end up panicing, e.g.
in case we have a config like the following:

```
config:
  aws:region: us-east-1
  aws🆔
    -
```

Fix that by getting the old behaviour of ignoring this error back.

Fixes  

## Checklist

- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
  - [x] I have formatted my code using `gofumpt`

<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!--- 
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->

---------

Co-authored-by: Kyle Dixler <kyle@pulumi.com>
2023-10-11 16:39:16 +00:00
Pat Gavlin 4d3b82cb9f
[cli] Add support for environments ()
These changes add support for ESC environments to the Pulumi CLI. This
involves two major changes:

- Support for the `env` subcommand
- Support for the `environment` stanza in stack config files

The former reuses the command from `esc` itself with a little
rebranding.

The latter adds support to stack config files for an `environment`
property of the form:

```yaml
environment:
  - list
  - of
  - environment
  - names
```

If this property is present in a stack's config file, the CLI will open
the and merge the listed environments during `pulumi up` et. al. If an
object-valued `pulumiConfig` property is present in the opened
environment, its values will be merged on top of the stack's config
prior to whatever operation is to be performed. If an object-valued
`environmentVariables` property is present inthe opened environment, its
values will be published as environment variables prior to the Pulumi
operation. Any values in the open environment's `pulumiConfig` or
`environmentVariables` that are marked as secret will be encrypted in
the resulting config and will be filtered from the command's logs.
2023-10-10 01:35:39 +00:00
Pat Gavlin 6756c12fd0
[config] Clean up implementation ()
These changes replace the idiosyncratic implementation of some of the
config Map and Value APIs with (hopefully) more straightforward code.

The fundamental representation of a config.Value remains a (value,
secure, object) tuple, where value is either a plain, possible-encrypted
string value or the JSON encoding of an object value. All operations on
values that need to observe the object value itself still decode the
JSON representation into a richer representation. This richer
representation, however, is no longer composed of `any` values: instead,
it is composed of `object` values. These values contain a restricted set
of types and directly track whether or not their contents are a secure
string value. The object-based representation allows for much clearer
implementations of the marshaling and traversal code without breaking
compatibility.

In addition to the new implementation for config.Value, these changes
add a config.Plaintext type that represents a plaintext config value. A
Plaintext value can be created manually or by decrypting a Value, and
can be encrypted and converted to a Value. This allows for more natural
creation and manipulation of config values.
2023-10-09 04:51:21 +00:00