Hey folks! Has anyone had any success with using a

StringBuilder

with

Output<string>

objects? I'm trying to create a large string using a mix of `string`s and `Output<string>`s, and I'm scratching my head on how to make use of

StringBuilder

for this purpose

The Output<string> is like a Task<string>: it's something that eventually will be resolved into a string. So you can't use it as a regular string. The way to use it, is to use the Apply method on an Output<T>. https://www.pulumi.com/docs/concepts/inputs-outputs/#apply Inside the Apply, you can use the StringBuilder as usual.

Mixing these is probably tricky, Apply's run async and you really don't want to mix that with mutable state.

Thanks for the reply, both! @echoing-dinner-19531 I hope you don't mind me direct mentioning you on this, but I ran into an issue that getting insight from a Pulumi engineer on it would be appreciated! I'm trying to populate a config file that contains secrets, and upload it to Azure Blob Storage for use in an Azure App Gallery Application. To do this, I need to aggregate some disparate secrets, which are `Output<string>`s, into a single large string (it'll become a

.conf

file). Assembling all of these secrets gives me one large

Output<string>

. So far, so good. However, the

Source

parameter of the

Blob

resource accepts an

Input<AssetOrArchive>

. I want to put this big

Output<string>

into a

StringAsset

object (which inherits

AssetOrArchive

via

Asset

), but the only type it accepts is

string

, not

Output<string>

. If I construct this

StringAsset

inside an

Output.Apply

and get an

Output<StringAsset>

, Blob's

Source

parameter rejects it. It states that it cannot convert an

Output<StringAsset>

into

Input<AssetOrArchive>

, despite the types being completely compatible from what I can tell. Am I doing something wrong here, or have I run into a bug? If I'm not doing something wrong, this would suggest to me that there's currently no way to put an

Output<T>

into an Azure Blob.

Yeh... that sounds like an oversight of the asset code. It should be fine with Output<string>, but I think we just haven't filled that in. I'll reply on the ticket as well.

Thanks! Yeah, the only way I can think of that could resolve that would be making use of interfaces instead of abstract classes, but that'd probably be a significant rewrite 😓