Hey folks 👋 — I'm building a Pulumi-based internal platform using the Automation API with many dynamically generated stacks, all orchestrated from Go. Each stack uses the same

pulumi.RunFunc

, and we’re integrating a Terraform provider via

pulumi package add

. I’m trying to decide what to do about the generated Go SDK code (

sdks/<provider>/...

) that comes from

pulumi package add terraform-provider kong/konnect

. The SDK works only after some manual fixes (e.g. removing broken files, patching

provider.go

), and then it’s imported by the main program to provision resources. My question: For people building similar platforms — do you check the generated SDK code into version control, or do you treat it like any other build artifact and regenerate as needed? I’m leaning toward checking it in because: • The SDK requires manual patches • It simplifies onboarding • I want deterministic builds across environments But I’d love to hear what others in the Pulumi community are doing. Any best practices, war stories, or gotchas?

I note that Pulumi checks in all generated code, E,g, https://github.com/pulumi/pulumi-aws/blob/master/sdk/nodejs/amp/getDefaultScraperConfiguration.ts

// *** WARNING: this file was generated by pulumi-language-nodejs. ***
// *** Do not edit by hand unless you're certain you know what you are doing! ***

@white-answer-67284 for generated SDKs added via

pulumi package add

, you do not need to commit this code to your repo. If someone checks out a project using an upstream TF provider via Any TF, the SDK is regenerated when running

pulumi install

instead of the install command from your package manager (

npm ci

,

pip install

, ...). The Pulumi command will regenerate the SDK followed by running your package manager install command.

Can you share the details on what is broken in the generated SDK? That sounds like a potential bug we would want to fix on the Pulumi side.

Yeah sure thing. just a moment. Also let me know if I need to formalize this as a bug/issue and I'm happy to do so. Context: • pulumi version:

v3.210.0

• language

go

• go version:

go version go1.24.0 darwin/arm64

Steps to reproduce: 1.

mkdir provider-debug-dir && cd provider-debug-dir

2.

pulumi new go -y

3.

pulumi package add terraform-provider kong/konnect

4.

cd sdks/konnect

5.

go mod tidy

At this point, two compilation errors are visible in the generated code:

konnect/provider.go:122:10: cannot use providerTerraformConfigResultOutput{} (value of type providerTerraformConfigResultOutput) as pulumi.MapOutput value in return statement

After fixing that one manually, there is one more

konnect/getPlatformIpAddresses.go:78:62: undefined: pulumi.StringArrayMapMapOutput
konnect/getPlatformIpAddresses.go:79:116: undefined: pulumi.StringArrayMapMapOutput

As a quick-and-dirty fix I just deleted that file. Then I was able to use the generated sdk successfully (and it works) Hence, my philosophical question - as in my case, checking it in would make sense because some manual remediation was necessary.

Can I request you to file an issue here? https://github.com/pulumi/pulumi/issues I was able to reproduce the issue given your steps, and it seems to be generating code referencing a type "StringArrayMapMapOutput" which does not exist in the pulumi sdk. My guess is that there is something unusual in the schema for this provider and the code generation is not handling it properly, but this is not my area of expertise.

Here it is https://github.com/pulumi/pulumi/issues/21238. Thanks! And as far as my original question goes - I understand that the sdks are not intended to be checked into vcs - this makes sense (when there are no bugs in the generated sdk 😉 )

@white-answer-67284 Any advice on how to get this working, minimal example of how to use a terraform provider locally generated sdk in an inline automation API program in go would be amazing since this is not documented anywhere as far as I can see.