tfbridge: GetSchema should re-inject version from Main when schema.json omits it, fixing pulumi package add

[videmsky]

What happened?

tfgen strips version from schema.json, and nothing puts it back at serve time — is a bridge-side fix planned?

Example

We maintain several bridged providers (internal, built on pulumi-terraform-bridge). All of them fail pulumi package add:

$ pulumi package add cosmic@2.44.3
error: <nil>: #/version: version must be provided when package supports packing;
error: failed to generate SDK: generation failed: <nil>: #/version: version must be
       provided when package supports packing; , and 2 other diagnostic(s)

(The error appears twice because the CLI and the language host each bind the same schema.)
What we traced it to

1. tfgen deliberately blanks the version when it emits schema.json, so the checked-in file is stable across releases — pkg/tfgen/generate.go:

case Schema:
    // Omit the version so that the spec is stable if the version is e.g. derived from the
    // current Git commit hash.
    pulumiPackageSpec.Version = ""

2. Nothing re-attaches it at serve time. tfbridge.Main(pkg, version, prov, schema) uses its version argument for GetPluginInfo, tracing tags and resource behaviour, while GetSchema returns the embedded bytes verbatim (Schema: string(p.pulumiSchema)). So the plugin reports 2.44.3 for --version while advertising a schema with no version at all.
3. On the consuming side, pulumi package add forces SupportPack = true (pkg/cmd/pulumi/packages/packages.go) and pkg/codegen/schema/bind.go then rejects a version-less schema. The CLI doesn't backfill from the @2.44.3 the user typed — SchemaFromSchemaSource backfills pluginDownloadURL and namespace, but not version. So the missing field is load-bearing, not cosmetic.
4. Upstream providers work around it in the provider cmd directory, not in the bridge — e.g. pulumi-aws's provider/cmd/pulumi-resource-aws/generate.go injects $VERSION into a generated schema-embed.json at build time (and log.Fatals if VERSION is unset). Our repos carry the //go:generate go run ./generate.go directive copied from that template, but the script itself was never added — so we embed the raw, version-less schema.json and hit the above.

Output of pulumi about

will provide

Additional context

❓
Do you consider this something the bridge should handle — e.g. tfbridge's GetSchema setting the top-level version from the version already passed to tfbridge.Main when the embedded schema omits it? That would keep schema.json stable in git (the stated reason for stripping it) while making every bridged provider correct by default, including ones that have never noticed because pulumi plugin install doesn't bind the schema. Is a change along those lines planned or on the table?

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[corymhall]

@videmsky yes we can and should make this change. It looks like the current solution grew over time, but is no longer necessary. It looks like the ideal flow is:

1. Build sets the provider binary version.
2. Provider embeds the versionless schema.json.
3. Bridge adds the binary version when GetSchema runs.

In the bridge (this repo) we can just update GetSchema to use the provider version if the schema doesn't have a version. That should solve this issue.

After this change, we should update all our providers

• In provider repos change:

  //go:embed schema-embed.json

to:

  //go:embed schema.json

Then remove generate.go when it only creates the versioned schema.

• In ci-mgmt remove:
  • schema_embed Make target
  • VERSION=... go generate
  • schema-embed.json artifact upload/download

Rollout would look something like:

1. Release the bridge fix.
2. Update ci-mgmt.
3. Upgrade and migrate providers gradually.

The build must still set the binary version. Everything related to copying that version into the schema can go away.