1. 使用docker executor runner時，出現Runner無法連接網絡的問題
這個是關於宿主機與Container的DNS的映射問題，詳情可以訪問https://github.com/docker/libnetwork/issues/2187。
你的pipeline可能出現如下情況：
fatal: unable to access 'https://gitlab-ci-token:xxxxxxxxxxxxxxxxxxxx@code.siemens.com/zhen.xie/iavgitlabrunnertest.git/': Could not resolve host: code.siemens.com
該問題的解決辦法是在Runner的配置文件config.toml里增加dns = ["..."]，dns的值你可以通過在宿主機上運行nmcli dev show來獲得。
這個問題講述的是docker executor無法訪問外網的問題，需要添加dns配置參數來實現
我這邊遇到這個問題跟這個有點類似，是無法解析自定義的域名的問題，處理辦法是添加參數：extra_hosts = ["gitlab.example.com:192.168.80.201","jdd.io:192.168.2.162"]
詳看文章 gitlab和gitlab-runner的一個小坑：https://www.cnblogs.com/sanduzxcvbnm/p/14668269.html
2.Pipeline出現"JAVA_HOME is not set and no java command could be found in your PATH"
這個錯誤通常出現在使用Shell executor時，可以在GitLab page上設置這個環境變量，具體路徑是GitLab page -> Settings -> CI/CD -> Variables。
3.Runner間隔多久去GitLab上檢查是否有job
config.toml文件的check_interval字段會決定這個時間間隔，它的默認值是3秒(注意當你把它設為0時依然采用的是默認值3秒，而不是0秒)。
在config.toml文件中定義了很多runner，它們可能executor類型不同，可能注冊地址不同，但都是由GitLab Runner這個服務來管理的，為了與GitLab Runner區分開，我們將config.toml文件中定義的runner稱為worker。對於不同的worker，worker之間(如worker A ---> worker B)的間隔為check_interval / worker_nums，但是對於worker A本身來說它下次去檢查是否有job的時間間隔仍為check_interval。我們再舉個簡單例子：config.toml定義了3個worker—— worker A, worker B 和 worker C，check_interval采用默認值為3秒，第0秒時worker A會去檢查是否有屬於自己的job，第1秒時worker B會去檢查，第2秒時worker C去檢查，第3秒時worker A再檢查……這個過程中worker A到worker B的間隔為3 / 3 = 1秒，而對於worker A下次檢查job時的時間間隔為check_interval，即3秒。
4.config.toml里的concurrent字段的意義
concurrent限制了整個GitLab Runner能並發處理job的數量。特別注意concurrent與worker數量無任何關系，所有worker的工作是受GitLab Runner控制的，如果concurrent值為1並且有一個worker已經在工作了，那么即使其他worker達到了可以工作的條件也只能“pending”。
5.cache存儲在哪里，怎樣清除cache
cache是沒有過期時間的，而且每一次新的push觸發的pipeline，都會重新生成cache，重新生成的cache的名字為“-”，其中num是隨着push數量遞增的。如果不去清除cache，cache會永久保留在Runner上，日積月累會填滿存儲空間的，因此最好隔一段時間進行一次清除，清除方法請參考https://docs.gitlab.com/ee/ci/caching/#clearing-the-cache， 清除cache的原理是將相關的volume移除，當然，docker也有自帶的清除命令，推薦將docker system prune -f --volumes加入到定時任務中。
6.當我的Runner采用docker作為executor時，無法build docker image
這是個“dind(docker in docker)” 問題，一般pipeline會報如下錯誤：
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
time="2018-12-17T11:12:33Z" level=error msg="failed to dial gRPC: cannot connect to the Docker daemon. Is 'docker daemon' running on this host?: dial unix
有兩種解決辦法：
第一種解決辦法：將本地的docker socket綁定到container里來解決這個問題，具體方法是將volumes = ["/var/run/docker.sock:/var/run/docker.sock"]配置到config.toml文件里。
第二種解決辦法：.gitlab-ci.yml文件中增加如下設置
services:
- docker:dind
7.如何在job所對應的container里使用git clone命令
首先要確保宿主機有權限clone代碼，然后你就可以將你的secret掛載到container里，例如，你是通過ssh的方式克隆代碼，並且你的ssh目錄為/home/.ssh，你就可以在config.toml文件里添加如下配置：
volumes = ["/home/.ssh:/root/.ssh:ro"]
然后，這個job所對應的container就可以拉取指定代碼了。