pulumi/pkg/resource/stack
Matt Ellis 31bd463264 Gracefully handle the case where secrets_provider is uninitalized
A customer reported an issue where operations would fail with the
following error:

```
error: could not deserialize deployment: unknown secrets provider type
```

The problem here was the customer's deployment had a
`secrets_provider` section which looked like the following:

```
"secrets_providers": {
    "type": ""
}
```

And so our code to try to construct a secrets manager from this thing
would fail, as our registry does not contain any information about a
provider with an empty type.

We do two things in this change:

1. When serializing a deployment, if there is no secrets manager,
don't even write the `secrets_provider` block. This helps for cases
where we are roundtripping deployments that did not have a provider
configured (i.e. they were older stacks that did not use secrets)

2. When deserializing, if we see an empty secrets provider like the
above, interpret it to mean "this deployment has no secrets". We set
up a decrypter such that if it ends up haiving secrets, we panic
eagerly (since this is a logical bug in our system somewhere).
2019-05-21 17:11:54 -07:00
..
testdata Add a version property to checkpoints 2018-03-10 13:03:05 -08:00
checkpoint.go Don't return serialized outputs from stack.GetRooStacktResource 2019-05-10 17:07:52 -07:00
checkpoint_test.go Add license headers 2018-05-22 15:02:47 -07:00
debug.test Add a version property to checkpoints 2018-03-10 13:03:05 -08:00
deployment.go Gracefully handle the case where secrets_provider is uninitalized 2019-05-21 17:11:54 -07:00
deployment_test.go Augment secret outputs based on per request options 2019-05-10 17:07:52 -07:00