Automatic Go workspace initialization

[AaronFriel]

Configures Go workspaces in bridged provider repositories.

Users will experience Go workspaces configured on their behalf, unless they have opted out of Go workspaces. CI sets GOWORK=off to opt out in all of the workflows related to build and test.

Builds with GOWORK=off are considered release builds in the updated Makefile and contributing guide.

See this PR and associated branch for a demonstration:

• dev: automatic go workspace config pulumi-venafi#105

[t0yv0]

We're having way too much fun here with meta-make.

[t0yv0]

Thanks for clarifying the docs here.

[guineveresaenger]

I would like to hold this for discussion with the team.

What problem does this address? I have had few good experiences with Go workspaces, and I would prefer this not be part of the default, as I doubt I'm the only one who is not using Go workspaces at the moment.

[danielrbradley]

As noted on the slack thread I think this is the wrong approach. I think this adds a lots of complexity to our build processes which could make things more difficult to diagnose when something goes wrongs and harder to make structural changes to our providers and builds.

A better approach would be to have

1. A standalone target to set up the workspace if you want it.
2. Set GOWORK=off by default when running through the makefile so we have consistency between local and CI builds.
3. Add an environment to not disable workspaces in the makefile.

I think this should go to ideation before opening a PR.

[iwahbe]

The code change looks good. The review experience is impressively bad. We should consider changing how this repo works so we don't need to check in every file.

I agree with the team that this should probably go through an ideation, given the current lack of buy-in.

[abhinav]

Echoing Ian. Makefile target looks fine; will give this another look once there's agreement on the approach.

[AaronFriel]

@danielrbradley @guineveresaenger Happy to go through ideation, but I would be unhappy to delay this and do not think we can afford to have our contributor & employee onboarding UX have these outcomes.

I cloned a repository, pulumi-venafi, and tested a variety of local configurations. With this change, all of the failure modes below are resolved except for the warning when a user has experimentalWorkspaceModule enabled.

Clone location	Go version	gopls version	gopls.EWM Enabled?	Makefile make tfgen	VS Code Silent Start	VS Code Problems Found	gopls LSP Code Completion
GOPATH	1.18.10	0.11.0	FALSE	✅	✅	>100	❌
GOPATH	1.19.7	0.11.0	FALSE	✅	✅	>100	❌
GOPATH	1.20.2	0.11.0	FALSE	✅	✅	>100	❌
GOPATH	1.18.10	0.11.0	TRUE	✅	❌[1]	0	✅
GOPATH	1.19.7	0.11.0	TRUE	✅	❌[1]	0	✅
GOPATH	1.20.2	0.11.0	TRUE	✅	❌[1]	0	✅
GOPATH	1.18.10	HEAD	FALSE	✅	✅	>100	❌
GOPATH	1.19.7	HEAD	FALSE	✅	✅	>100	❌
GOPATH	1.20.2	HEAD	FALSE	✅	✅	>100	❌
GOPATH	1.18.10	HEAD	TRUE	✅	❌[2]	>100	❌
GOPATH	1.19.7	HEAD	TRUE	✅	❌[2]	>100	❌
GOPATH	1.20.2	HEAD	TRUE	✅	❌[2]	>100	❌
Not in workspace	1.18.10	0.11.0	FALSE	✅	❌[3]	~10	❌
Not in workspace	1.19.7	0.11.0	FALSE	✅	❌[3]	~10	❌
Not in workspace	1.20.2	0.11.0	FALSE	✅	❌[3]	~10	❌
Not in workspace	1.18.10	0.11.0	TRUE	✅	❌[1]	0	✅
Not in workspace	1.19.7	0.11.0	TRUE	✅	❌[1]	0	✅
Not in workspace	1.20.2	0.11.0	TRUE	✅	❌[1]	0	✅
Not in workspace	1.18.10	HEAD	FALSE	✅	❌[3]	~10	❌
Not in workspace	1.19.7	HEAD	FALSE	✅	❌[3]	~10	❌
Not in workspace	1.20.2	HEAD	FALSE	✅	❌[3]	~10	❌
Not in workspace	1.18.10	HEAD	TRUE	✅	❌[2][3]	~10	❌
Not in workspace	1.19.7	HEAD	TRUE	✅	❌[2][3]	~10	❌
Not in workspace	1.20.2	HEAD	TRUE	✅	❌[2][3]	~10	❌
In workspace	1.18.10	0.11.0	FALSE	❌[4]	✅	~10	❌[5]
In workspace	1.19.7	0.11.0	FALSE	❌[4]	✅	~10	❌[5]
In workspace	1.20.2	0.11.0	FALSE	❌[4]	✅	~10	❌[5]
In workspace	1.18.10	0.11.0	TRUE	❌[4]	❌[1]	~10	❌[5]
In workspace	1.19.7	0.11.0	TRUE	❌[4]	❌[1]	~10	❌[5]
In workspace	1.20.2	0.11.0	TRUE	❌[4]	❌[1]	~10	❌[5]
In workspace	1.18.10	HEAD	FALSE	❌[4]	✅	~10	❌[5]
In workspace	1.19.7	HEAD	FALSE	❌[4]	✅	~10	❌[5]
In workspace	1.20.2	HEAD	FALSE	❌[4]	✅	~10	❌[5]
In workspace	1.18.10	HEAD	TRUE	❌[4]	❌[2]	~10	❌[5]
In workspace	1.19.7	HEAD	TRUE	❌[4]	❌[2]	~10	❌[5]
In workspace	1.20.2	HEAD	TRUE	❌[4]	❌[2]	~10	❌[5]

Notes	Description
❌[1]	Go LSP pops a toast notification that EWM has been replaced, told to use Go workspaces. Note, this will not help the user unless the workspace is correctly configured.
❌[2]	Go LSP pops a toast notification that EWM has been deprecated. No other information is provided.
❌[3]	Go status bar indicates that there is an error loading the workspace, the repository has been cloned outside of GOPATH or a workspace.
❌[4]	Make fails with an error that "no required module provides ...", tells the user that they must run "go get...", but this is not accurate. That go get command will fail.
❌[5]	In these situations, imported packages succeeded if they were present in my Go module cache. Any import not in my go module cache failed, and code completion or go to definition for imports within the repository failed.

[iwahbe]

@AaronFriel I'm really concerned by all the ❌s next to make tfgen that are ✅s in "Not in Workspace".

[AaronFriel]

Yes, if a user clones a repository into a directory, and that directory has a parent Go workspace, the outcomes are especially bad. Until the user adds the repository to their workspace, they will see some potentially misleading error messages.

The error that tells the user to go get ... is particularly egregious.