* Don't throw on type mismatches in the dotnet sdk
Fixes#7329
The converter will no longer throw if resource providers return data
that does not match the expected type declared in the dotnet sdk.
Instead a warning will be logged for the resource and the value will be
set to `default(T)`.
While our CI seems happy with this line of code on master, my machine
with the 3.1 sdk is resolving it to non-nullable type and complaining
about the "= null" line later.
```
LocalWorkspace.cs(389,27): error CS8600: Converting null literal or
possible null value to non-nullable type.
[/workspaces/pulumi/sdk/dotnet/Pulumi.Automation/Pulumi.Automation.csproj]
```
Quick fix to just not use "var" here.
* .NET & python SDKs parity for bad pulumi versions
They handle invalid Pulumi CLI version gracefully.
* Make python version property lazy
* Clarify .NET logic
* Add python test for validate_pulumi_version
* Add tests for invalid versions
* Fix python test
* Fix typo
* Fix tests
* Have _validate_pulumi_version handle parsing
* Modify python and .NET to parseAndValidate
* Modify typescript and go to parseAndValidate
* fix name
This change fixes a regression marshaling assets/archives that was introduced after adding support for marshaling output values.
For example, when setting an `Asset` on a field typed as `AssetOrAchiveInput`, in `marshalInput`, the input was being converted into an `AssetOrArchiveOutput` via the `ToAssetOrArchiveOutputWithContext`. Awaiting the output returns an `*asset` struct, which is itself an `AssetInput`, which causes infinite recursion when passed recursively to `marshalInput`.
The fix is to skip the `Input` checks in recursive calls, which is equivalent to the previous behavior before the regression was introduced.
Another issue was that when the input is converted to an output, this would result in `marshalInput` always returning an output value, even if the original passed-in value was not an output. To address this, if the output's value is known, not a secret, and has no dependencies, we can return the value itself rather than wrapping it as an output.
* Fix race condition in TaskMonitoringHelper
Fixes#8163
TaskMonitoringHelper was using two seperate trackers for Idle and
FirstException and then calling WhenAny on both to see which state
happened first. This was racy as you could end up completing a task with
an exception but getting the idle tracker fire first, resulting in
TaskMonitoringHelper thinking no exception had happened.
I've combined the two trackers into TaskMonitoringHelper now. At each
task completion we check for exceptions and then idleness.
* Add changelog
These changes add a context type to `resource/testing` that can be used to
generate property values that are valid with respect to certain rules. The
context represents a Pulumi stack, and contains a project name, stack name,
and a list of resources.
- URNs generated using a context will always use the context's project
and stack name
- Resource references generated using a context will always refer to
resources in the context's resource list
- Output values generated using a context will always pull dependencies
from the context's resource list
`ConstructInputs.CopyTo` can error when falling back to the old marshaling behavior when it's lacking an input type registration for a _known_ output value. In such cases, it tries to unmarshal a known output value, it can't unmarshal it because of a missing switch case. This change adds the missing case.
* Enable output values by default
Enable output values by default in the resource monitor and change the polarity of the envvar from `PULUMI_ENABLE_OUTPUT_VALUES` to `PULUMI_DISABLE_OUTPUT_VALUES`.
* Marshal unknown as unknown string when `!KeepOutputValues`
Marshal all unknown output values as `resource.MakeComputed(resource.NewStringProperty(""))` when not keeping output values, which is consistent with what the SDKs do.
Otherwise, when `v.OutputValue().Element` is nil, `resource.MakeComputed(v.OutputValue().Element)` will be marshaled as a null value rather than as an unknown sentinel.
* Add MarshalOptions.DontSkipOutputs and use where needed
Before we expanded the meaning of `resource.Output`, `MarshalProperties` always skipped output values:
```go
if v.IsOutput() {
logging.V(9).Infof("Skipping output property for RPC[%s]: %v", opts.Label, key)
}
```
As part of expanding the meaning of `resource.Output`, I'd adjusted `MarshalProperties` to only skip output values when the value was unknown and when not keeping output values:
```go
if v.IsOutput() && !v.OutputValue().Known && !opts.KeepOutputValues {
logging.V(9).Infof("Skipping output property for RPC[%s]: %v", opts.Label, key)
}
```
However, this doesn't work the way we want when marshaling properties that include unknown output values to a provider that does not accept outputs. In that case, `opts.KeepOutputValues` will be `false` because we want the marshaler to fall back to returning non-output-values (e.g. unknown sentinel value for unknown output values), but instead of getting the intended fallback values, the unknown output values are skipped (not what we want).
I suspect we may be able to delete the output value skipping in `MarshalProperties` altogether (it's odd that it is skipping `resource.Output` but not `resource.Computed`), but to avoid any unintended side effects of doing that, instead, this commit introduces a new `MarshalOptions.DontSkipOutputs` option that can be set to `true` to opt-in to not skipping output values when marshaling. The check in `MarshalProperties` now looks like this:
```go
if !opts.DontSkipOutputs && v.IsOutput() && !v.OutputValue().Known {
logging.V(9).Infof("Skipping output property for RPC[%s]: %v", opts.Label, key)
}
```
`opts.DontSkipOutputs` is set to `true` when marshaling properties for calls to a provider's `Construct` and `Call`.
* [sdk/nodejs] Deserialize output values
This commit adds support for deserializing output values, which is needed in some cases when serialized inputs are returned as outputs in the SDK.
* [sdk/python] Deserialize output values
This commit adds support for deserializing output values, which is needed in some cases when serialized inputs are returned as outputs in the SDK.
v3.13.0 introduces support for serializing outputs in inputs as special output value objects in the Node.js and Python SDKs when serializing inputs for remote components and method calls. This functionality is currently disabled by default in the engine (setting the `PULUMI_ENABLE_OUTPUT_VALUES` envvar to a truthy value enables it).
However, unit testing remote components with mocks results in errors being raised in v3.13.0, related to the new output value support. This is due to the mock monitor implementation saying it supports all features (which now includes output values), so the SDK serializers are serializing outputs as output values, which the mock monitor can't handle correctly.
This change addresses the issue by updating the mock monitor implementation in the Node.js and Python SDKs to indicate the specific features that are supported, excluding support for output values. New tests with mocks fail before the change and pass after.
This schema can be used to validate the contents of a Pulumi deployment.
If a deployment validates against this schema, it should be considered
syntactically valid, though it may contain certain classes of semantic
errors (e.g. references to unknown resources in dependency lists,
dependency cycles, etc.).
This schema is not yet used for validation in practice and may not be
entirely accurate.
These changes also add this schema (and the schemas on which it depends)
to the developer documentation. jsonschema2md.go has been updated to
support multi-file schemas.