mysterious-australia-14256
06/25/2021, 2:20 PMPulumi.Config config = new Pulumi.Config();
var mySettings = config.RequireObject<MyModel>("Key");
MyModel contains several properties and I've recently tried to add a new one with a type of Pulumi.Input<string>?. Since adding that if I try to run the code I get an error saying
The JSON value could not be converted to Pulumi.Input`1[System.String]
Is this possible at all?bored-oyster-3147
06/25/2021, 2:25 PMInput<string>?
? I would just make it string?
. That can be passed to Input<string>
without much issuebrave-planet-10645
06/25/2021, 2:33 PMJsonElement
if you use Structured Config (see example at the bottom), so that should get you startedmysterious-australia-14256
06/25/2021, 2:54 PMbored-oyster-3147
06/25/2021, 3:01 PMstring
in your config. string
can be implicitly cast to Input<string>
so that is a non-issuemysterious-australia-14256
06/25/2021, 3:56 PM// create the service bus namespace
var serviceBusSettings = config.RequireObject<ServiceBusNamespaceModel>("ServiceBus");
var serviceBusNamespace = PulumiAzureWrappers.ServiceBusNamespace.Create(
namespaceSettings: serviceBusSettings,
dependsOn: new List<Resource> { resourceGroup }
);
So I have a line that reads all of the setting from a config file into a model (e.g. ServiceBusNamespaceModel) and then I pass that off to a method in a wrapper class to actually run the Pulumi code to create it. The method then returns the relevant Pulumi object (e.g. a Pulumi.AzureNative.ServiceBus.Namespace).
The downside is that if I create a resource (such as an IntegrationAccount) the another resource depends on then the Model I pass with all of the settings has to support it.
For my Logic App model I have a string property called IntegrationAccountId that I was hoping I could use to pass the string value of the ID from the created Integration Account in but when I tried this it was passing Pulumi.Output`1[System.String] rather than the actual ID. Changing the property from string to Pulumi.Input<string> fixed that issue but broke the deserialization into that property when I was using an ID in a config file rather than using an object.
Thanks for your time with this anyway but I think with sticking with 2 properties (one for a string ID and one for a resource) is probably easiest unless I can either deserialize to Pulumi.Input<string> somehow or access the string ID value of a created Pulumi Integration Account to get the actual value rather than the Pulumi.Output`1[System.String]