Change invoke call to always use latest version #987
Conversation
| } else { | ||
| invokeOpts = {...invokeOpts, version: getVersion()}; | ||
| } | ||
| let invokeOpts: pulumi.InvokeOptions = { async: true, version: getVersion() }; |
There was a problem hiding this comment.
Do we still also need to pass through a parent so that it uses the right provider instance? Or does this invoke not actually care about the provider? Even if it doesn’t now, should we pass the parent through regardless?
I actually don’t know for sure - so maybe input from @pgavlin would be good.
There was a problem hiding this comment.
I tried passing both args, and it was failing the same way (invoke returning an empty object {}). That may be a bug with the engine, but I don't know enough about it to be sure.
I think using the version makes sense.
There was a problem hiding this comment.
Even if it doesn’t now, should we pass the parent through regardless?
I think the version makes the most sense here as well. This invoke does not need the particular provider instance (yet, at least).
lblackstone
force-pushed
the
lblackstone/invoke-version
branch
from
bfbf679
to
5fd0cde
Compare
| @@ -121,16 +121,11 @@ import * as outputs from "../types/output"; | |||
| resourcePrefix?: string; | |||
| } | |||
|
|
|||
| function yamlLoadAll(text: string, opts?: pulumi.CustomResourceOptions): Promise<any[]> { | |||
| function yamlLoadAll(text: string): Promise<any[]> { | |||
| // Rather than using the default provider for the following invoke call, determine the | |||
| // provider from the parent if specified, or fallback to using the version specified | |||
| // in package.json. | |||
There was a problem hiding this comment.
This comment block seems outdated.
|
Hopefully it will be still be possible to use |
|
@EronWright Right, this change won't affect that functionality. This change is an implementation detail that shouldn't be visible to users. |
|
@lblackstone I'm trying to use 1.5.3 and seeing errant behavior, that the |
|
@EronWright Can you open an issue with details? I just double-checked locally, and wasn't able to reproduce. I created a new GKE cluster + ConfigFile and it worked as expected. |
Proposed changes
Related issues (optional)