Re: Preliminary Doc on Moving to Go Modules
toggle quoted messageShow quoted text
Thank you Eric
Is there additional overhead for setting team permissions that allow the update to the main repo?
Does LF manage GitHub via infrastructure as code?
On Jan 30, 2019, at 5:32 PM, Eric Ball <eball@...
In addition to the initial creation of the repo (which isn't a big deal) and devs needing to pull submodules, there's also the added step of having to update one repo (the one using the submodule) when the other one is updated. This is an extra step, and
an easy one to forget, but it's certainly not a major source of complexity. Just something to keep in mind when weighing the options. Jeremy, please chime in if I forgot anything.
The Linux Foundation
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 jeremyphelps@...
Sent: Monday, January 28, 2019 10:23 AM
Subject: 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.