ayufan

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.

Kamil, GitLab CI/CD Lead

Could you point to problems and ideally issues that you are facing?

Kamil, GitLab CI/CD Lead

Thanks. We are aware of this issue, and we even know what is causing that, we also have ideas how to fix that. The plan is to release a fix with 10.5: https://gitlab.com/gitlab-org/gitlab-ce/issues/38265#note_55....

GitLab CI/CD Lead

Hi janciska,

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.

Kamil, CI/CD Lead at GitLab

Hi maktouch,

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.

Kamil, GitLab CI Lead

Currently not. The limitations can be found here: http://docs.gitlab.com/ce/container_registry/README.html#lim.... We plan to improve that in one of upcoming releases.

The Container Registry is available on our free GitLab.com.

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.

https://gitlab.com/gitlab-org/gitlab-ce/issues/17009 https://gitlab.com/gitlab-org/gitlab-ce/issues/17010

Thanks. We are working on bringing missing features to artifacts, so we will improve that workflow.

We are already considering that and given past experience it is a quite simple process: https://gitlab.com/gitlab-org/gitlab-ce/issues/14926

GitLab CI Lead

Thanks tobilg.

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!

GitLab CI Lead

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.

Currently Shared Runners offer only Linux-based builds. We can introduce extensions to that offering at some point.

The Linux-based Shared Runners are free for everyone, including for private projects.

Exactly. The image specified during registration is the default one.

You can override the image globally in .gitlab-ci.yml or on per-job basis. Full flexibility here :)

I understand your reasoning.

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.

The problem with cleaning old images and caches is also addressed. You may be interested in checking out this application: https://gitlab.com/gitlab-org/gitlab-runner-docker-cleanup

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 :)

GitLab CI Lead

You shouldn't be. Executing builds on Kubernetes is not the same as deploying an application :) We will solve that need with plugins :)

GitLab CI Lead

You may be interested in this example of Python application (django): http://doc.gitlab.com/ce/ci/examples/test-and-deploy-python-...

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 :)

Yes. Sure. Instead of adding the CNAME you need to add an A record. You can get the IP address with dig: $ dig a myuser.gitlab.io

Then configure your domain to point to that IP address.

We are currently working on documentation covering that part too.