Allow providers to perform major version updates without ci-mgmt PRs

[AaronFriel]

Updating a major version in a provider currently requires four or more pull requests, as shown with recent updates to Keycloak.

See:

• Upgrade terraform-provider-keycloak to v4.1.0 pulumi-keycloak#162
• Prepare for major version bump to 5 pulumi-keycloak#163
• Bump keycloak to v5 #315
• Re-enable test pulumi-keycloak#164

Even major version updates should follow a normal release process for a software project: a code change followed by a release ceremony. For our providers, this would be a pull request and a @release-bot automation.

A pull request was made to Keycloak to demonstrate changes to ci-mgmt outputs that we'd have to make to support this:

• example: simplify major version updates pulumi-keycloak#165

If these changes were in place, three of the four pull requests would not have been needed to update Keycloak to v5.

[t0yv0]

The PR has been stalling a bit but I want to log some new findings/suggestions based on going through the TLS major version change.

One thing we should do is make the Makefile read VERSION_PREFIX from a file in the repository, to pass to pulumictl. Note that it's somehow a pain in Makefile to pass env vars to $(shell) sub-commands so that might need to be rewritten.. The requirement is that a maintainer that wants to initiate a new major version upgrade, edits the repo to indicate the new major version but does not edit the ci-mgmt controlled Makefile. Then this constraints version selection to start picking up new, say 5.x.x. versions. Which actually changes how sdk/go generated files look like.

[AaronFriel]

With the Keycloak PR above, the major version was completely removed from the Makefile. That simplified things quite a lot. I'd need to look to see how the VERSION_PREFIX was calculated, but I think pulumictl will pick it up from the git tag on release builds.

[t0yv0]

Also as regards to the PR in #319 - the idea to remove "/v5" completely from examples/ code is very clever, but costs making the examples a bit less copy-paste able. I'm on the fence there if the tradeoff's worth it. For an alt approach here's a quickie tool that does gofmt -r and go mod edit changes:

pulumi/upgrade-provider#9

It can also presumably scan README.md with regexes to update those, but maybe we should just edit out versioned references from the READMEs..

A version of this tool can be used as a read-only lint check to make sure the repo is consistent in terms of the major version, like the major version in the provider/ code is consistent with examples and sdk etc.

[t0yv0]

Yeah Keycloak still doing VERSION := $(shell pulumictl get version) that's going to compute the old (say v4.x.x) version uses you already have the new (say 5.x.x) tag in history, which is a pain for the upgrade PRs.

[t0yv0]

pulumi/pulumi-tls#190 runs tests on new version so there's no need to do the "disable/enable" test dance. I think that's really compelling.

[AaronFriel]

We can decouple the Keycloak PR's makefile changes from the examples changes - we don't need to ship both together.

[iwahbe]

Fixed by moving the source of truth about a provider to the provider's repo: .ci-mgmt.yaml.