Auto-update converter version

[danielrbradley]

Currently, the setting pulumiConvert defaults to disabled. To enable it, the .ci-mgmt.yaml must be updated with pulumiConvert: 1 and add the terraform converter plugin:

+plugins:
+  - name: terraform
+    version: "1.0.16"
+    kind: converter
+pulumiConvert: 1

This should now be enabled for all bridged providers.

Additionally, we want to auto-update the version of the terraform converter plugin as new releases come out.

We can update the defaults.config.yaml in ci-mgmt to always set pulumiConfig: 1 and always include the terraform converter plugin (or we could remove the option and always include the plugin).

Managing terraform converter versions

Option 1: Centrally bump via ci-mgmt

Rolling out a new version of the converter plugin could be done using the existing ci-mgmt rollout process - just update the version hard-coded in the template.

Pros:

• This keeps all providers on the same version.

Cons:

• The change history is less clear why a nightly ci-mgmt change is affecting the examples.

Option 2: Add a .terraform-converter.version file

Each provider could have their own version traked in a dedicated file, similar to what we use for the pulumi CLI version. This could be updated via a new nightly job in the repo itself.

Pros:

• Better PR/change descriptions.
• Doesn't block CI upgrades if there's an issue in the new converter version.
• Works better for third parties.

Cons:

• More engineering required.
• Versions of the converter could vary more per-provider.

Option 3: Improve ci-mgmt update change summaries

Do option 1, but also improve the descriptions on automated PRs from ci-mgmt to include a summary of changes since the last rollout.

[t0yv0]

Having the version automatically update and generate dedicated commits in history file is great value! That'd be wonderful. It would improve our docs as it will inherit fixes from the converter.

I do not have any objections to whichever way this gets done.

[mjeffryes]

I'm inclined toward option 1, possibly with some sort of variable to override the version in .ci-mgmt.yaml if a provider needs to temporarily opt out of a version bump.