1 Commits (27770ee8053da48fbb684fd23d415aae376d2bed)

Author	SHA1	Message	Date
Martin Atkins	5811be26f8	go.mod: Separate modules at code ownership boundaries ... Historically it's been hard for us to keep on top of dependency upgrades as a matter of course because it's unclear which code owners might be affected by or responsible for an upgrade of each module. After trying a few different techniques to try to mitigate this, the most promising one seems to be to tell the Go toolchain that each of these components is a separate Go module, but then to stitch them all back together again using replace directives so that we can mostly ignore these module boundaries in everyday development. The one case where we _do_ need to pay attention to these boundaries is also the case where the separation is useful: upgrading a dependency of any one of these modules might potentially force upgrading it for another module too, and so the Go toolchain will help us notice that interaction and we can immediately which code owners might need to be involved in reviewing and testing that particular upgrade. To make that process less onerous, this adds a new makefile target "make syncdeps" which runs "go mod tidy" in all of the modules at once and thus forces the toolchain to align their dependencies to the extent required for them all to be linked together successfully, and to generate go.mod and/or go.sum diffs that will match our configured code ownership paths to trigger the appropriate code review requests. Hopefully before too long we'll be able to move all the backends out into provider plugins and delete the "legacy" module entirely and then this oddness won't be needed anymore, but as long as we're all trying to play together in this same sandbox this is a small amount of extra ceremony in return for hopefully reducing the level of anxiety involved in keeping the system's dependencies up to date more consistently.	2 years ago