Re: Preliminary Doc on Moving to Go Modules
toggle quoted message. . .
I think in terms of the added workflow complexity, it would require additional overhead to the helpdesk / release engineer to create the repos where the submodules would reside.
I know that ci-management has git submodules and it seems to work well as long as the developers remember to do a recursive pull to ensure that the submodule code is refreshed.
~ James Gregg
On Behalf Of
Monday, January 28, 2019 10:23 AM
Re: [Edgex-tsc-devops] Preliminary Doc on Moving to Go Modules
I think there is one main problem to consider when using go mod in a mono-repo.
- git tag collisions
This could happen for example if when edgex-go goes from v1.0.0 to v2.0.0 if we also have pkg/contacts/v2 tagged at v2.0.0
I think that one possible way forward here is to use git submodules  for the internal deps.
ie; contacts v2 could live in it's own repo and be added to edgex-go as a submodule. We could then direct go mod to look for the
appropriate contracts tag on a specific path inside of edgex-go; we can define this as we see fit.
This does potentially introduce some workflow complexity, which we should discuss this coming Thursday.
Join EdgeX-TSC-DevOps@lists.edgexfoundry.org to automatically receive all group messages.