This message was deleted.

(as output functions should work)

Not quite. Output functions might not run at preview time, it depends on if the inputs to the function can be known or not.

So how should I make them not run? I'm really confused about this. I thought that if the function gets an output variable the function won't run on preview.

I thought that if the function gets an output variable the function won't run on preview.

No we try to run as much as we can at preview, outputs are used to indicate that we might not be able to run it at preview time and so it will stay unknown. If you have something that you don't want to run at preview time you can use

runtime.isDryRun()

That's really weird in some way, why would I want my preview code would be different from my up code. Doesn't Terraform know how to handle this?

Well terraform can't run general code so they don't have to worry about this problem.

you right for sure, but i’m really trying to understand how to manage my pulumi project now.

So your comment "why would I want my preview code would be different from my up code." is pretty spot on. You really don't want them to be different because that leads to mis-matches between preview and update. But you do want some operations to not happen at preview time (like obv it would be wrong to actually create a cloud resource at preview time but you still want to declare that's what you want to do with

new Resource

). Currently our method of making these "update-only" operations is to use a resource provider. But that is a bit heavy handed for just a helper method doing a http call.

When i’m previewing this dependency, the preview fails as the output apply result is

undefined

.

What output is this? It might be that its value really is

undefined

or it might be the unknown value tracking has a bug here.

basic as here : as you can see the issuer value is undefined during preview, which it makes sense because i’m previewing. but then my run fails as the url is undefined (line 24)

issuer

is a string why are you trying to

[0]

index it?

1. you right, my issue was applying the issuer[0], removed this and everything went smooth. 2. it’s truly a noop, removed this. So now I want to conclude it to myself, Pulumi does know how to handle outputs on preview ? what happens in the background of the functions when getting an output (as an input) in the preview ? If the question isn’t clear tell me and i’ll rephrase.

So see

Output<T>

a bit like a promise, it might have a value in it but you can't directly see that. Instead for a promise you use

then

to chain them together and the runtume calls each

then

method as the promise resolves.

Outputs

are similar but we use

apply

and we also support the concept of "unknown at preview time" where if an output is unknown because its coming from a resource operation that we won't run at preview time (like actually creating a cloud resource) then we don't run the apply function and just resolve the next part of the output chain to "unknown" as well.

great explanation. For example here, I got a

.replace

function on the issuer output, and for some reason I get :

Calling [toString] on an [Output<T>] is not supported.

To get the value of an Output<T> as an Output<string> consider either:
1: o.apply(v => `prefix${v}suffix`)
2: pulumi.interpolate `prefix${v}suffix`

Yup that's because all toString an Output<T> can return is "Output<T>" but people use it by mistake a lot so we make the result that warning text. It's likely that in 4.0 toString will just throw an error with that text instead.

so what will be the fix here ?

Probably using

all

and

apply

to take all those outputs and use them inside one apply to return the PolicyDocument

That’s good idea, but I forgot to share all the function. I created a PolicyDoc, and used it in order to create a Role, all inside the

apply

, but now I want to return this Role, which I can’t because now

externalDnsRole

is an output.

assumeRolePolicy can be an

Input<PolicyDocument>

. And an

Output<T>

is an

Input<T>

so it's fine to make the policy document inside an apply. In fact

PolicyDocument.Statement

is an input as are the args for a

PolicyStatement.

Hey @echoing-dinner-19531 , Thank you for your amazing help, I really appreciate it, I learned a lot about Pulumi from this thread. Do you think there's a way to implement an example for this kind of output usage ? I'm sure it'll help others.

I don't know our examples very well, might be we've already got one but yeh if we don't it's a good use case to show off.