I.e. if the Go mod lives in the root, then pushing the tag v1.2.3 will essentially create a release of the SDK. When this action runs and attempts to push the the Go SDK with the version number on a standalone commit, I think it'll try and push the tag v1.2.3 to that new commit too, which will fail because it already exists.

That's a good point... what do you think would be the best way to handle this? Do we not need the publish SDK step?

I think the pragmatic solution is to disable the Go publish step for this provider for now.

This publishing method likely means the SDK is either not pinning the provider version or is pinning the wrong provider version. We should open an issue to investigate. It's possible that the only way to make this work right now is to hard code the version in the repo and bump it ahead of each release.

Long term, we should use the same design of SDK publishing for consistency but that will be a breaking change.

@blampe this is going to affect ingress-nginx as well now, can I push a commit to this branch to fix those as well?

@rshade sorry I missed this, I think Daniel's suggestion to disable the Go publishing step is probably the best path forward for now, but that will probably requiring a little bit of plumbing in ci-mgmt.

@blampe no worries, I made a PR instead. I did try to make a go example on nginx and ran into problems:

go mod tidy
go: finding module for package github.com/pulumi/pulumi-kubernetes-ingress-nginx/sdk
go: simple-nginx-go imports
        github.com/pulumi/pulumi-kubernetes-ingress-nginx/sdk: module github.com/pulumi/pulumi-kubernetes-ingress-nginx/sdk@latest found (v0.0.10, replaced by ../../sdk), but does not contain package github.com/pulumi/pulumi-kubernetes-ingress-nginx/sdk

I am not sure that go.mod is setup right in sdk on either repo