... | ... | @@ -54,6 +54,26 @@ Upstream has [generic documentation on how to migrate from Jenkins](https://docs |
|
|
which could be useful for us. We have yet to write a more complete
|
|
|
guide on how to migrate jobs to GitLab CI.
|
|
|
|
|
|
## FAQ
|
|
|
|
|
|
* do runners have **network access**? **yes**, but that might
|
|
|
eventually change
|
|
|
* how to build from **multiple git repositories**? install `git` and
|
|
|
clone the extra repositories. using git submodules might work
|
|
|
around eventual network access restrictions
|
|
|
* how do I **trust runners**? you can setup your own runner for your
|
|
|
own project in the GitLab app, but in any case you need to trust
|
|
|
the GitLab *app*. we are considering options for this, see
|
|
|
[security](#security)
|
|
|
* how do i control the image used by the runners? the docker image is
|
|
|
specified in the `.gitlab-ci.yml` file. but through Docker image
|
|
|
policies, it might be possible for specific runners to be
|
|
|
restricted to specific, controlled, Docker images.
|
|
|
* do we provide, build, or host our own **Docker images**? **not
|
|
|
yet**. ideally, we would never use images straight from
|
|
|
hub.docker.com and build our own ecosystem of images, built `FROM
|
|
|
scratch` or from `debootstrap`
|
|
|
|
|
|
## Pager playbook
|
|
|
|
|
|
<!-- information about common errors from the monitoring system and -->
|
... | ... | @@ -268,7 +288,10 @@ many "jobs", defined in a project's git repository (the |
|
|
many "runners". Those runners are separate processes, usually running
|
|
|
on a different host than the main GitLab server.
|
|
|
|
|
|
They regularly poll the central GitLab for jobs and execute those
|
|
|
GitLab runner is a program written in Golong which clocks at about
|
|
|
800,000 SLOC, including vendored dependencies, 80,000 SLOC without.
|
|
|
|
|
|
Runners regularly poll the central GitLab for jobs and execute those
|
|
|
inside an "[executor](https://docs.gitlab.com/runner/executors/README.html)". We currently support only "Docker" as an
|
|
|
executor but are working on different ones, like a custom "podman"
|
|
|
(for more trusted runners, see below) or KVM executor (for foreign
|
... | ... | |