Re: go repos concerns

Fede Claramonte
 

Jeremy,

My second point was about just breaking the compilation. Some module not compiling because of changes in another repo.

Fede


On 18/12/17 16:01, Jeremy Phelps wrote:
Hi Fede,
These are actually all really good points, I appreciate you bringing them up.  I agree that we need to discuss this as there are some cases where it could cause us some troubles.
For example...if the dependencies are vendored is there a way to pin to a specific version?

1) Each time a repo changes we all will need to update the vendor folder manually. I think it will be wearisome and error-prone.
    Not only that but how do we manage different versions under vendoring...there may be a case where the vendored code will be a release branch and not the tip of master for example.

2) Another problem is to know if a change in any module (e.g. core-domain-go) breaks some other module. We will need to manually compile all the dependent modules to make sure we will not break any other module.
    This is not a unique problem in this case I think.  This is just an issue with mico-services in general.  We can lessen the impact by strict adherence to sematic versioning and some smoke tests before we kick off blackbox-testing.

3) Previous point will be also influence how CI is implemented, it will need to launch several jobs after a change to test if it breaks some other module.
    I think this is what blackbox-testing would cover no?

On Mon, Dec 18, 2017 at 8:40 AM, Fede Claramonte <fclaramonte@...> wrote:
Hi all,

First of all I want to thank Dell for the initial go code for the core microservices. Good work.

I have been learning about the core Go code and I have some concerns about the layout of the code on different repositories.

We have several repos, each one with one different edgex module or lib. Each repo uses glide to vendor all dependencies, including the other edgex modules. So we have the same code copied over all the repositories in the vendor folder(e.g. core-domain-go, support-domain-go). My concerns:

1) Each time a repo changes we all will need to update the vendor folder manually. I think it will be wearisome and error-prone.

2) Another problem is to know if a change in any module (e.g. core-domain-go) breaks some other module. We will need to manually compile all the dependent modules to make sure we will not break any other module.

3) Previous point will be also influence how CI is implemented, it will need to launch several jobs after a change to test if it breaks some other module.

On the other hand we have the layout Drasko set up for export services. It contains all the needed code to compile several microservices and it is trivial to know when any change breaks some other module in the repo.

I would propose to use something similar to what Drasko did, i.e. having all/most of the edgex Go code in only one repo as follows:

edgex-go
├── cmd                 // The main file for each microservice in each folder
│   ├── core-data
│   ├── core-metadata
│   ├── export-client
│   ├── export-distro
│   └── support-logging
├── core                // core-domain-go
│   ├── clients         // core-clients-go
│   ├── data            // core-data-go
│   └── metadata        // core-metadata-go
├── device              // Device helplers
│   └── virtual         // device virtual
├── dockerfiles
├── export // The export repository
│ ├── client
│   └── distro
└── support             // support-domain-go
    └── logging

With this layout it will be easier to work with the code, all in only one repo. After changing something in edgex-go/core/XXX.go you just need to build and run the tests locally to know if the change breaks something. This is also a lot easier for CI, as there is no dependencies between different repos.

Opinions?

Fede

_______________________________________________
EdgeX-GoLang mailing list
EdgeX-GoLang@...y.org
https://lists.edgexfoundry.org/mailman/listinfo/edgex-golang


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