gitlab-runner 或 Docker 默認緩存 /builds 目錄嗎？

Question

我在我的 MacBook Pro 上使用 gitlab-runner 和 Docker。 我正在使用 gitlab.com 來托管我的 git 存儲庫。 我已將一個存儲庫配置為在將提交推送到存儲庫時執行管道。 管道有兩個工作：顯示一些信息，並克隆一個單獨的存儲庫作為依賴項。

這是第一份工作的輸出：

Running with gitlab-runner 12.2.0 (a987417a)
  on old_gen_runner 6fsjs96e
Using Docker executor with image gcc-arm_4_7-2013q3:3.0 ...
Using docker image sha256:5d4741a428654beb44a3c004822e4d2ceededc88f22ec1ec7f45dedf707a0302 for gcc-arm_4_7-2013q3:3.0 ...
Running on runner-6fsjs96e-project-13664495-concurrent-0 via my_laptop.local...
Fetching changes with git depth set to 50...
Initialized empty Git repository in /builds/staging-fw/my-project/.git/
Created fresh repository.
From https://gitlab.com/staging-fw/my-project
 * [new branch]      master     -> origin/master
Checking out 722c2c38 as master...

Skipping Git submodules setup
$ python /scripts/info.py
Printing job info...

Builds dir: /builds

Commit Message: 
Modified yml file.

Branch: master
Project dir: /builds/staging-fw/my-project
$ ls /builds
my-project

這是第二個作業的輸出：

Running with gitlab-runner 12.2.0 (a987417a)
  on old_gen_runner 6fsjs96e
Using Docker executor with image gcc-arm_4_7-2013q3:3.0 ...
Using docker image sha256:5d4741a428654beb44a3c004822e4d2ceededc88f22ec1ec7f45dedf707a0302 for gcc-arm_4_7-2013q3:3.0 ...
Running on runner-6fsjs96e-project-13664495-concurrent-0 via my_laptop.local...
Fetching changes with git depth set to 50...
Reinitialized existing Git repository in /builds/staging-fw/my-project/.git/
Checking out 722c2c38 as master...

Skipping Git submodules setup
$ git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/staging-fw/my-dependencies.git /builds/dependencies
Cloning into '/builds/dependencies'...
Job succeeded

可以看到，第一次創建管道，就成功了。

如果我通過推送新更改再次運行它，這是第一個作業的輸出：

Running with gitlab-runner 12.2.0 (a987417a)
  on old_gen_runner 6fsjs96e
Using Docker executor with image gcc-arm_4_7-2013q3:3.0 ...
Using docker image sha256:5d4741a428654beb44a3c004822e4d2ceededc88f22ec1ec7f45dedf707a0302 for gcc-arm_4_7-2013q3:3.0 ...
Running on runner-6fsjs96e-project-13664495-concurrent-0 via my_laptop.local...
Fetching changes with git depth set to 50...
Reinitialized existing Git repository in /builds/staging-fw/my-project/.git/
From https://gitlab.com/staging-fw/my-project
   722c2c3..f321b75  master     -> origin/master
Checking out f321b75f as master...

Skipping Git submodules setup
$ python /scripts/info.py
Printing job info...

Builds dir: /builds

Commit Message: 
Modified yml file.

Branch: master
Project dir: /builds/staging-fw/my-project
$ ls /builds
my-project
dependencies
Job succeeded

如您所見，dependencies 文件夾還在嗎？ 不僅如此，它不再像在第一個作業的第一次運行中那樣說Initialized empty Git repository ，而是說Reinitialized existing Git repository 。

以下是第二次運行期間第二個作業發生的情況：

Running with gitlab-runner 12.2.0 (a987417a)
  on old_gen_runner 6fsjs96e
Using Docker executor with image gcc-arm_4_7-2013q3:3.0 ...
Using docker image sha256:5d4741a428654beb44a3c004822e4d2ceededc88f22ec1ec7f45dedf707a0302 for gcc-arm_4_7-2013q3:3.0 ...
Running on runner-6fsjs96e-project-13664495-concurrent-0 via my_laptop.local...
Fetching changes with git depth set to 50...
Reinitialized existing Git repository in /builds/staging-fw/my-project/.git/
Checking out f321b75f as master...

Skipping Git submodules setup
$ git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/staging-fw/my-dependencies.git /builds/dependencies
fatal: destination path '/builds/dependencies' already exists and is not an empty directory.
ERROR: Job failed: exit code 1

我的問題是：

1. 是否為 Docker 中的每個單獨容器創建了/builds目錄？ 這是我最初的理解，Docker 中的每個容器都有自己獨立的 /builds 目錄。

2. /builds目錄是否為所有 Docker 容器共享？ 我找不到這方面的任何信息。

2a。 如果/builds目錄為所有 Docker 容器共享，那么它在哪里以及是誰創建的？

Answer 1

GitLab CI/CD 的默認 Git 策略是“獲取”。 如果相同的靜態運行器一遍又一遍地用於相同的管道，GitLab 不會進行新的克隆，而只會在后續運行中獲取更改。

如果您每次想要“克隆”策略時都想要一個新鮮的環境。 有兩種方法可以更改此行為：

1. 通過轉到項目設置 -> CI/CD -> 通用管道 -> 將“管道的 Git 策略”設置為git clone ，將項目默認值更改為“克隆”
2. 通過.gitlab-ci.yml更改策略：

variables:
  GIT_STRATEGY: clone

您可以在 GitLab 文檔 - Git 策略中了解有關此設置的更多信息

Answer 2

轉到您的項目菜單：CI/CD -> Pipeline 然后單擊 [Clear runner caches] 這對我有用！

Answer 3

1. 是否為 Docker 中的每個單獨容器創建了 /builds 目錄？ 這是我最初的理解，Docker 中的每個容器都有自己獨立的 /builds 目錄。

簡短回答：使用 docker 執行程序時，它取決於GIT_STRATEGY 。

/builds是一個 docker 卷，它是從主機掛載的。

這在文檔中以某種方式提到：

• https://docs.gitlab.com/runner/executors/docker.html#the-builds-and-cache-storage
• https://docs.gitlab.com/runner/executors/docker.html#the-persistent-storage

卷是否持續存在取決於作業的GIT_STRATEGY ：

• 如果 GIT_STRATEGY=="fetch" 卷保持不變，並與運行作業的連續一次性容器共享（在此主機上，對於此項目）。
• 否則，該卷被認為是“臨時的”並在作業結束時被刪除。

這可以在gitlab-runner 的實現中看到：

func (e *executor) createBuildVolume() error {
    ...
    if e.Build.GetGitStrategy() == common.GitFetch {
        err = e.volumesManager.Create(e.Context, jobsDir)
        ...
    } else {
        err = e.volumesManager.CreateTemporary(e.Context, jobsDir)
    }
...
}

當您的跑步者正在構建某些東西時，您還可以檢查它的容器並找出使用了哪些卷（這里在 linux 上使用 gitlab-runner 14.10，使用GIT_STRATEGY=="fetch"運行作業）：

# docker container ls
9c981d9ec900   7d926f4bcaec   "sh -c 'if [ -x /usr…"   8 minutes ago   Up 8 minutes             runner-dfciu5nh-project-3374-concurrent-0-b73d69d36b7291e4-build-2

# docker container inspect 9c981d9ec900 | jq .[0].Mounts
[
  {
    "Type": "volume",
    "Name": "runner-dfciu5nh-project-3374-concurrent-0-cache-3c3f060a0374fc8bc39395164f415a70",
    "Source": "/var/lib/docker/volumes/runner-dfciu5nh-project-3374-concurrent-0-cache-3c3f060a0374fc8bc39395164f415a70/_data",
    "Destination": "/cache",
    "Driver": "local",
    "Mode": "z",
    "RW": true,
    "Propagation": ""
  },
  {
    "Type": "volume",
    "Name": "runner-dfciu5nh-project-3374-concurrent-0-cache-c33bcaa1fd2c77edfc3893b41966cea8",
    "Source": "/var/lib/docker/volumes/runner-dfciu5nh-project-3374-concurrent-0-cache-c33bcaa1fd2c77edfc3893b41966cea8/_data",
    "Destination": "/builds",
    "Driver": "local",
    "Mode": "z",
    "RW": true,
    "Propagation": ""
  }
]

因此，名為runner-dfciu5nh-project-3374-concurrent-0-cache-c33bcaa1fd2c77edfc3893b41966cea8是從/var/lib/docker/volumes/runner-dfciu5nh-project-3374-concurrent-0-cache-c33bcaa1fd2c77edfc3893b41966cea8/_data在主機上到容器中的/builds 。

2. /builds 目錄是否為所有 Docker 容器共享？ 我找不到這方面的任何信息。

如果GIT_STRATEGY=="fetch"則/builds卷確實存在並被重復用於同一項目的后續構建。 請注意項目 ID（在我的示例中為 3374）在卷名中的位置。 如果您的 runner 接受多個並發作業，則您的 runner 可能每個項目也有幾個 /builds 卷（因此卷名稱中的並發 ID）。

如果GIT_STRATEGY!="fetch" ，則該卷不會持久存在並且不會與任何容器共享。

2a。 如果 /builds 目錄為所有 Docker 容器共享，那么它在哪里以及是誰創建的？

它是由 gitlab-runner 自己懶惰地創建的（即，如果在運行給定作業時需要）。

順便說一句，為了清除構建目錄，您可以：

• 使用與“fetch”不同的GIT_STRATEGY 。
• 在檢查源代碼時，使用GIT_STRATEGY=="fetch"並讓 gitlab-runner 在運行您的工作之前執行此操作。 這可以使用GIT_CLEAN_FLAGS進行配置。 這也可以在作業結束時使用 FF_ENABLE_JOB_CLEANUP功能標志完成。
• 使用disable_cache docker-specific runner 設置配置你的runner
• 在工作的開始和/或結束時執行rm -rf （在.gitlab-ci.yml文件中）
• 刪除主機上的 docker 卷。 使用或從clearing-docker-cache 腳本中獲取靈感。 這更多的是用於垃圾收集而不是確保新的構建環境。

我還懷疑您可以調整builds_dir和volumes運行器設置以使用 tmpfs

（我沒試過）。