Fundermantals : How best to structure repository dependencies?

How to Use GitLab
1

Hi
I’m trying to design a git workflow for a team of about 20 sw designers building component based embedded applications with a common framework. The framework is a collection of in house reusable libraries and ChibiOS (a open source Real Time Kernel and HAL).
The aspect I need some help on is how to best structure repository dependencies.

I’m contemplating the following 3 possibilities:

Structure 1:
repo: ChibiOS
└─Kernal
└─HAL

repo: All Libs
└─Lib1 source files
└─lib2 source files
└─lib3 source files
└─lib4 source files

repo: ApplicationA
└─submodule(chibiOS)
└─submodule(All Libs)
└─appA source files

Structure 2:
repo: ChibiOS
└─Kernal
└─HAL

repo: Lib1
└─Lib1 source files

repo: Lib2
└─Lib2 source files

repo: Lib3
└─Lib3 source files

repo: Lib4
└─Lib4 source files

repo: AppA
└─submodule(chibiOS)
└─submodule(Lib1)
└─submodule(Lib3)
└─appA source files

repo: ApplicationB
└─submodule(chibiOS)
└─submodule(Lib1)
└─submodule(Lib4)
└─appB source files

Structure 3:
repo: ChibiOS
└─Kernal
└─HAL

repo: Framework
└─submodule(ChibiOS)
└─Lib1 source files
└─Lib2 source files
└─Lib3 source files
└─Lib4 source files

repo: ApplicationA
└─submodule(framework)
└─appA source files

Does GitLab have a convention for this? Your input is much appritiated!

2

Structure 2 seems best to me as it tracks the components in the most direct way, through submodules.

I have used a similar organization in several projects with GitLab. It works great, except that forking projects and relative submodules are not well-supported in GitLab.

3

BTW, ChibiOS rocks hard. Love it, so clean. Especially after working with the mess that is MQX.

4

I like structure 2. But I would like to know how to implement CI for Lib1 in Structure 2. ie. whenever there is a push to Lib1, clone the AppA. git submodule update Lib1 into AppA. Run tests in Lib1 only.