in summary, may or may not be completely different from the relevant upstream org/repo that we would want to check versions from.
This behavior is correct for "typical" providers with no renames, replaces, or otherwise obscuring the link to the GitHub org/repo location of the upstream provider, so it "works" in those instances.
The reason we did not detect this bug sooner is that we did not ever actually use the go.Mod.UpstreamProviderOrg before attempting to discover upstream upgrades.
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).
What happened?
For the new upstream upgrade check we use
go.Mod.UpstreamProviderOrgto detect upstream releases.However, the way that field gets populated is by attempting to read the upstream provider from the
provider/go.modfile, which:returns the first found match for
*/terraform-provider-foodoes not account for submodules that have since been reamed (such as DataDog - the org is
DataDognotterraform-providers.does not account for gitlab having a mirror repository, which never makes it into our go.mod
in summary, may or may not be completely different from the relevant upstream org/repo that we would want to check versions from.
This behavior is correct for "typical" providers with no renames, replaces, or otherwise obscuring the link to the GitHub org/repo location of the upstream provider, so it "works" in those instances.
The reason we did not detect this bug sooner is that we did not ever actually use the
go.Mod.UpstreamProviderOrgbefore attempting to discover upstream upgrades.Example
https://github.com/pulumi/pulumi-gitlab/issues/445
Output of
pulumi aboutn/a
Additional context
No response
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).