search

pulumi / pulumi-terraform-bridge

A library allowing providers built with the Terraform Plugin SDK to be bridged into Pulumi.
Apache License 2.0
183 stars 41 forks source link

Upgrade to `pulumi/pulumi` 3.120.0 #2099

Open lunaris opened 1 week ago

lunaris commented 1 week ago

This commit bumps the bridge to use the latest available version of Pulumi core. The most notable change here is that provider method signatures now accept a context.Context, meaning that we can deprecate the bridge's forked ProviderWithContext interface and methods.

lunaris commented 1 week ago

Apologies, I completely missed pf. This is interesting because currently we have ProviderWithContext, but now that all the methods have been standardised to take a Context, we might be able to do away with this entire concept, maybe?

iwahbe commented 1 week ago

Apologies, I completely missed pf. This is interesting because currently we have ProviderWithContext, but now that all the methods have been standardised to take a Context, we might be able to do away with this entire concept, maybe?

Making an internal thread public:

ProviderWithContext can and should be removed with the new signatures. I originally redid plugin.Provider because I was tired of plumbing changes through ProviderWithContext. The bridge actually has a fork of some of plugin (here), which I’m hoping we can now remove.

Any PR that you open which gets the bridge compiling against latest pu/pu would be welcome! That said, the more of the plugin folder you can remove from the bridge, the better.

lunaris commented 1 week ago

I've made some progress on this, but probably still need a few pointers. I've removed pf/internal/plugin and made provider an instance of plugin.Provider by tweaking the method signatures appropriately. This all appears to type check fine. However, the tests fail. I suspect this is down to two things:

  1. I've made a mistake when porting the old signatures to the new (e.g. passed old inputs instead of old outputs or similar due to differences in naming). I've spotted and fixed one such bug already (thanks tests!) but might have missed others.
  2. The internal code used a bespoke configEncode to handle unmarshalling in CheckConfig/DiffConfig. I don't know if there is a natural way to port this behaviour under plugin.Provider -- if there is, can someone advise? If not, I guess we will be unable to use plugin.NewProviderServer as-is and have to wrap it still?

Of course it's possible there are other problems/things I've missed -- all input welcome!