Re: Preliminary Doc on Moving to Go Modules

Eric Ball


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.

Eric Ball
Release Engineer
The Linux Foundation

On Wed, Jan 30, 2019 at 4:26 PM Gregg, James R <james.r.gregg@...> wrote:


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. 

What else?


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


From: EdgeX-TSC-DevOps@... <EdgeX-TSC-DevOps@...> On Behalf Of jeremyphelps@...
Sent: Monday, January 28, 2019 10:23 AM
To: EdgeX-TSC-DevOps@...
Subject: Re: [Edgex-tsc-devops] Preliminary Doc on Moving to Go Modules


Hi Everyone,
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 [1] 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 to automatically receive all group messages.