To clarify, is your GitLab-based job system done with configuration-as-code and does it share definitions of jobs across repos?
The solution we come up with in using Gerrit/Jenkins was to have a common test invocation (in our case `make test`) that glossed over all the details of a projects build process, and was expected to output test and coverage in specific formats Jenkins could consume (junit/xunit and cobertura). We have jobs that run `make test` no matter if the code is C, Go, Python, Javascript, etc.
This also had the beneficial side effect of lowering the barrier to entry for someone working on any random project - make papers over all those toolchain differences.
The solution we come up with in using Gerrit/Jenkins was to have a common test invocation (in our case `make test`) that glossed over all the details of a projects build process, and was expected to output test and coverage in specific formats Jenkins could consume (junit/xunit and cobertura). We have jobs that run `make test` no matter if the code is C, Go, Python, Javascript, etc.
This also had the beneficial side effect of lowering the barrier to entry for someone working on any random project - make papers over all those toolchain differences.