Ok. So most of these problems are related to Runner and Docker Containers for builds:
1. You can make Runner to not create cache containers with Advanced Settings and `disable_cache` option,
2. As for Git Repo, you can force Runner to retry cloning,
3. 500 with variables is new to me, let us know if you manage to get a stack trace from this error.
Thanks for writing that comment and making us aware of that case. I'm very sorry that it did that long to get reviewed and merged. The number of issues and merge requests that pass our hands is just crazy and sometimes it happens that some of them are oversight and not properly scheduled. Having people to be persistent, like you, makes them finally to be merged and be part of the product. Thank you for doing that! From our side, we will try our best to make this process to be more efficient.
1. Since the review apps is tied with a branch, as soon as branch is deleted the review app is stopped. This actually happening in above video. At the end you see the stopped review :)
2. You can use your own services. Sid did propose to use Helm package. If you look into Helm package sources you will see how they do it and following the same you get the same result on vanilla Docker.
The biggest plus of using integrated registry is that you have integrated authentication and authorization of GitLab that follow your groups and members assigned to your GitLab projects, making it really easy to have private container repositories stored on registry.
Second the built-in registry is really easy to configure and maintain. You have to specify the address and provide a certificate to start using it. You also use the same backups mechanism as you use for your GitLab installation.
In the future we may make it possible to use external storage for container images, like S3. This is something that is already supported by docker/distribution.
We are thinking big. The integrated Container Registry is part of our plan. We will soon have an integrated deployments with easy to access environments. We also plan to introduce manual actions on pipelines allowing you to execute arbitary things, ex. promote to production, but also merge it back to the master.
We choose docker-machine, because it also manages infrastructure, so this makes it much more easier for Administrators to manage hundred of build machines.
I'm thinking about an option to make it possible in one of the upcoming releases: how to scale gitlab-runner on other providers. You should look out for improvements in that department too!
This was problem in the past. Since we use Docker we have fairly good separation of builds. You are not able to fetch someone other source unless you find or use linux kernel exploit. This will get improved further with upcoming upgrades to shared runners offering: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/.... Most likely we will run the builds only once on the VM.
At this point it doesn't make sense to introduce support for another clustering manager. The GitLab Runner does support docker-machine (you can pretty easily configure it to create machines on-demand on any cloud provider). These machines will be pretty much self-managed. Soon the Runner will be also compatible with Docker Swarm, the implementation is already on separate branch.
From my perspective Kubernetes is great as platform for deploying applications, but I'm not so sure if it comes for distributing builds.
What is important that GitLab Runner is being constantly improved and at some point with more convincing (for example coming from You) we can get back to native Kubernetes executor :)
Previously we had problems with usernames/groups that had upper case letters. The recent improvements (8.5) fixes all these problems. Please try it now :)
Kamil, GitLab CI/CD Lead