I must be missing something here. It seems like the point of go workspaces is to enable local dev without mucking up the go.mod file with "replace", which seems great. But if a go.work file exists, any go command will silently use the local dev related dependencies defined in that file. The default GOWORK env var cannot be edited, so the existence of the file is enough to quietly use different dependencies than the go.mod file for any commands run. This seems like a massive footgun to release local dev changes as part of your package if anyone forgets to run all commands with GOWORK=off or delete the go.work file. Why would running in dev mode be the default? Is there a way to turn it off without deleting the file?
Asked
Active
Viewed 530 times
4
blackgreen
- 34,072
- 23
- 111
- 129
EMC
- 1,560
- 2
- 17
- 31
1 Answers
0
The danger is in the same ballpark as for example running go test while having new source files present (before they are added to git). Both situations can be solved with:
Have a continuous integration (CI) job running on a fresh machine (or on a fresh container). This frees your release process from an entire category of risk of poisoning/contamination.
kubanczyk
- 5,184
- 1
- 41
- 52
-
Was there supposed to be a link to another question in this answer? – larsks Jul 20 '23 at 12:09
-
1@larsks No, not really.... I've fixed the botched phrasing - thanks. – kubanczyk Jul 20 '23 at 17:23