This PR reverts part of the changes made in #214 in favor of using an explicit new config var, upstreamProviderOrg.
The use context here focuses on having a valid git host url for detecting new versions upstream that is separate from the go module path.
When this config variable is set on the provider's .ci-mgmt config file, upgrade-provider will read this value first and set it in the context.
When it is unset, we will continue to infer the upstream org from the go.mod file as before.
We are removing parsing the resources.go file for the GitHubOrg value as that use case requires a valid go module path.
The rollout here will cause a few providers to fail their nightly upstream version check. The fix is to add the correct upstreamProviderOrg to the CI config.
Corresponding ci-mgmt PR.
This PR reverts part of the changes made in #214 in favor of using an explicit new config var,
upstreamProviderOrg. The use context here focuses on having a valid git host url for detecting new versions upstream that is separate from the go module path.When this config variable is set on the provider's
.ci-mgmtconfig file,upgrade-providerwill read this value first and set it in the context. When it is unset, we will continue to infer the upstream org from the go.mod file as before. We are removing parsing the resources.go file for theGitHubOrgvalue as that use case requires a valid go module path.The rollout here will cause a few providers to fail their nightly upstream version check. The fix is to add the correct
upstreamProviderOrgto the CI config. Corresponding ci-mgmt PR.Additionally, this PR moves some org mapping configuration out of this tool to be configured on provider level instead. In order to keep logic straightforward, one option is to hard code the GitLab provider's remote - if that is objectionable, please only consider changes up to https://github.com/pulumi/upgrade-provider/pull/228/commits/c22dec245d9c706ae6f35e0e88ea6b259f2358e9.
Fixes #221.