Re: Preliminary Doc on Moving to Go Modules

Gregg, James R
 

Jeremy,

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.
Thoughts?
Jeremy
[1] https://git-scm.com/book/en/v2/Git-Tools-Submodules

Join EdgeX-TSC-DevOps@lists.edgexfoundry.org to automatically receive all group messages.