CI/CD for microservices in monorepo on Gitlab I'm working on a project that consists of several different services in different languages (a React webapp, a Scala backend, some Python stuff etc). I currently have each of these services in separate repositories on Github, and build them separately using CircleCI. 

Some people seem to promote mono repos. As I'm planning to migrate the code over to Gitlab I wanted to take the opportunity to understand how this could be made into a monorepo. I have three questions:


Assume I put all the services in the same Project (Gitlab repos are called Projects right?), can I then get the CI/CD system to build each component independently?
Can I have Gitlab emit several images into my container registry?
Assume I commit a change to one service, and want to make sure it works with my other services before I deploy, how do I best setup integration tests that condition the success of my commit on the interaction with my other services?
Monorepos are nice because it eliminates the technical constraints between multiple projects. This does however open the door to other complications within your repository (naming conventions, cross-team dependencies, merge conflict increases, etc.). I do not have any experience with CircleCI, but I will provide some input based on other CI tools I have used. 


I don't see any reason why you wouldn't be able to. In your CI/CD system, instead of referencing your individual source repositories, you will use your main monorepo as the source repository and then reference the specific project directory within it. 
It looks like as of GitLab version 9.1 this is supported.
In my opinion, this wouldn't be something that would happen on commit. You could do this, but I think it would slow down your development speed significantly and use up a lot of resources if you have many commits. The two key points to consider are:


Before every production release, you should run a full suite test on all projects in your infrastructure. This is the only way to be certain that all project dependencies are non-breaking.
Tests/provisionings must run in parallel. By doing this, your full repository testing speed will be the length of the longest test/provisioning in your repository. (As a side effect, this puts an emphasis on speeding up your slowest test)