I'm not sure if the pattern I'm using isn't a common one, or if I'm still missing something, but using pulumi-cdk I seem to be hitting a bit of an issue: I'm using a custom Synthesizer with a designated bucket name, where assets are staged for deployment into multiple target accounts via my provider(s) that are configured to use an assumable role. But now when I add a second target account to my pulumi app to deploy (via config), I get this error:

Duplicate resource URN 'urn:pulumi:dev::example::pulumi:providers:aws-native::cdk-aws-native'; try giving it a unique name

I realise that the

createDefaultNativeProvider

in the pulumi-cdk module is responsible for creating a native provider with this exact ID if I don't specify any providers at the CDK app level. (See: https://github.com/pulumi/pulumi-cdk/blob/7cdb858ccfa2d129663651b65f3e5ffafb866257/src/stack.ts#L490) If I go and add my 2 x providers (1 x native, 1 x normal) at that level, then I hit this error:

error: Duplicate resource URN 'urn:pulumi:dev:example:cdk:construct:StagingStack$aws:s3/bucketV2:BucketV2::pulumi-cdk-staging-assets-for-org-access-123456789012'; try giving it a unique name

However, my custom Synthesizer that defines this bucket name is only defined once, and is not instantiated in the area where multiple target accounts are defined - its defined once and passed over to the area that needs it. I can't really define this Synthesizer per-target-account, since it needs a policy updated on the staging bucket manually to allow all my target accounts to get objects from it. Currently I pass my

providers

in to the

pulumicdk.Stack

options, and this works just fine when configuring 1 x target account. (Defining more than 1 is where I start hitting the first error). Is there a different way I should be tackling this?

I believe this is related to https://github.com/pulumi/pulumi-cdk/issues/308 Right now you have to create separate synthesizers for each stack that has a unique environment.

That sounds about what I'm experiencing - thanks for the link!

For the time being you could just fork the

PulumiSynthesizer

class in your own program and change what you want from it

An update on this - it was a little too complex for my liking (extended classes) in a codebase I want to keep simple, so I implemented a copy of my cdk library in pulumi, in our relevant monorepo, and made a common set of types that are used to configure both the cdk and pulumi versions. The pulumi lib is now published to our npm registry and I'm just simply installing that pulumi lib where I need it now. Much simpler than using the pulumi-cdk harness (IMO)

I'm curious to hear more about how that went, was it pretty straightforward to implement the CDK stuff in Pulumi? Anything you think we could do to make that type of migration easier?

It's a fairly simple CDK library I wrote a while ago that defines a few roles, a codebuild project, an SNS topic, a custom lambda function (typescript code) and a subscription for the lambda to the SNS topic. The library needs about 4 x parameters fed in to customise everything. Implmenting it in pulumi by hand would have taken me maybe 1-2 hours, but I used an LLM to look at the existing CDK code, and write it using Pulumi typescript for me, and that took maybe 5 minutes, plus 10-15 minutes tweaking things, adding some basic tests, and then maybe another 15 minutes to get the LLM to add a 'common' lib between the CDK and Pulumi versions so that in future anyone wanting to update both can just update the 'common' type library settings and it applies to both. So it was quite straight forward already, especially with an LLM to hand. Everything I needed was already available in Pulumi.