No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

<@U0395G3QKAQ> it’s almost certainly easier to bridge the bitbucket provider

I and my team don’t know Go, so I worry that that would be far outside our skill set.

you actually don’t need to know a whole lot of go except module management, but that’s valid. I’ll see if I can try bridge one tomorrow

If you can make your work public I’d love to read through it.

Any thoughts on testing dynamic resources? I’m thinking I’ll start with functional tests and just try to create the resources with the automation API—then hit them with API calls to assert facts about them.

there are a bunch here: <https://github.com/lbrlabs/>

I generally try avoid dynamic resources personally, so not much I can help with there

Thanks! Do they have downsides besides not being language agnostic?

&gt; Do they have downsides besides not being language agnostic?
That's the big one, it limits your provider to only being used by python users, while a non-dynamic provider can generate SDKs for every language.

They're also relying on closure serialisation to work, which when it works is awesome but is a nightmare to debug when it doesn't work (this isn't unique to Pulumi, we're just using cloudpickle internally).

They're also _highly_ coupled to the SDK version which makes it very hard for us to update them. We've been looking at doing new dynamic providers that would be a separate library with their own update cadence but it's not been deemed a high enough priority to commit to yet.