CI/CD development documentation · Gitlab 中文文檔

# CI/CD development documentation > 原文：[https://docs.gitlab.com/ee/development/cicd/](https://docs.gitlab.com/ee/development/cicd/) * [CI Architecture overview](#ci-architecture-overview) * [Job scheduling](#job-scheduling) * [Communication between Runner and GitLab server](#communication-between-runner-and-gitlab-server) * [`Ci::RegisterJobService`](#ciregisterjobservice) # CI/CD development documentation[](#cicd-development-documentation "Permalink") 此處列出了特定于 CI / CD 的開發指南. 如果要創建新的 CI / CD 模板，請閱讀[GitLab CI / CD 模板的開發指南](templates.html) . ## CI Architecture overview[](#ci-architecture-overview "Permalink") 以下是 CI 體系結構的簡化圖. 為了集中在主要組件上，省略了一些細節. [![CI software architecture](https://img.kancloud.cn/86/eb/86ebae2cb4e0366679c5737e96f63504_1226x651.png)](img/ci_architecture.png) 在左側，我們有一些事件可以根據各種事件觸發管道（由用戶或自動化觸發）： * `git push`是觸發管道的最常見事件. * The [Web API](../../api/pipelines.html#create-a-new-pipeline). * 用戶單擊 UI 中的"運行管道"按鈕. * [創建或更新合并請求時](../../ci/merge_request_pipelines/index.html#pipelines-for-merge-requests) . * 將 MR 添加到[合并列車時](../../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.html#merge-trains-premium) . * A [scheduled pipeline](../../ci/pipelines/schedules.html#pipeline-schedules). * 當項目被[訂閱到上游項目時](../../ci/multi_project_pipelines.html#trigger-a-pipeline-when-an-upstream-project-is-rebuilt) . * 啟用[自動 DevOps 時](../../topics/autodevops/index.html) . * 當 GitHub 集成用于[外部請求請求時](../../ci/ci_cd_for_external_repos/index.html#pipelines-for-external-pull-requests) . * 當上游管道包含[橋接作業時](../../ci/yaml/README.html#trigger) ，該[作業](../../ci/yaml/README.html#trigger)會觸發下游管道. 觸發任何這些事件將調用[`CreatePipelineService`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/ci/create_pipeline_service.rb) ，后者將輸入事件數據并觸發用戶，然后嘗試創建管道. `CreatePipelineService`很大程度上依賴于[`YAML Processor`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/yaml_processor.rb)組件，該組件負責將 YAML Blob 作為輸入并返回管道的抽象數據結構（包括階段和所有作業）. 該組件還可以在處理 YAML 時驗證其結構，并返回任何語法或語義錯誤. 在`YAML Processor`組件中，我們定義了[所有](../../ci/yaml/README.html)可用于構建管道[的關鍵字](../../ci/yaml/README.html) . `CreatePipelineService`接收`YAML Processor`返回的抽象數據結構，然后將其轉換為持久化模型（管道，階段，作業等）. 之后，就可以處理管道了. 處理管道意味著按執行順序（階段或 DAG）運行作業，直到以下任一情況為止： * 所有預期的作業均已執行. * 故障會中斷管道執行. 處理管道的組件是[`ProcessPipelineService`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/ci/process_pipeline_service.rb) ，它負責將所有管道的作業移至完成狀態. 創建管道時，其所有作業最初都處于`created`狀態. 該服務根據流水線結構查看在`created`階段可以處理哪些作業. 然后，它們將它們移到`pending`狀態，這意味著它們現在[可以被 Runner 拾取](#job-scheduling) . 執行作業后，它可以成功完成或失敗. 管道中作業的每個狀態轉換都會再次觸發此服務，該服務會尋找下一個要轉換為完成的作業. 在此過程中， `ProcessPipelineService`更新作業，階段和整個管道的狀態. 在圖的右側，我們有一個列表[運動員](../../ci/runners/README.html#configuring-gitlab-runners)連接到 GitLab 實例. 這些可以是共享運行者，組運行者或項目特定的運行者. Runners 與 Rails 服務器之間的通信通過一組 API 端點（稱為`Runner API Gateway` . 我們可以注冊，刪除和驗證運行器，這也將導致對數據庫的讀/寫查詢. 連接了 Runner 之后，它會繼續詢問要執行的下一個作業. 這將調用[`RegisterJobService`](https://gitlab.com/gitlab-org/gitlab/blob/master/app/services/ci/register_job_service.rb) ，后者將選擇下一個作業并將其分配給 Runner. 此時，作業將轉換為`running`狀態，由于狀態更改，該狀態再次觸發`ProcessPipelineService` . 有關更多詳細信息，請參閱" [作業調度"](#job-scheduling) . 在執行作業時，運行程序將日志以及任何可能需要存儲的工件發送回服務器. 此外，作業可能依賴于先前作業中的工件才能運行. 在這種情況下，Runner 將使用專用的 API 端點下載它們. 工件存儲在對象存儲中，而元數據保留在數據庫中. 工件的重要示例是報表（JUnit，SAST，DAST 等），這些報表在合并請求中進行了解析和呈現. 作業狀態轉換并非全部自動化. 用戶可以運行[手動作業](../../ci/yaml/README.html#whenmanual) ，取消管道，重試特定的失敗作業或整個管道. 導致作業更改狀態的任何事件都將觸發`ProcessPipelineService` ，因為它負責跟蹤整個管道的狀態. 一種特殊類型的作業是[橋接作業](../../ci/yaml/README.html#trigger) ，當過渡到`pending`狀態時，該[作業](../../ci/yaml/README.html#trigger)在服務器端執行. 這項工作負責創建下游管道，例如多項目或子管道. 每次觸發下游管道時，工作流程循環都將從`CreatePipelineService`重新開始. ## Job scheduling[](#job-scheduling "Permalink") 創建管道時，將為所有階段一次創建所有作業，初始狀態為`created` . 這使得可視化管道的全部內容成為可能. 跑步者將不會看到具有`created`狀態的作業. 為了能夠將作業分配給 Runner，該作業必須首先轉換為`pending`狀態，這在以下情況下可能發生： 1. 作業是在管道的第一階段創建的. 2. 該作業需要手動啟動，并且已被觸發. 3. 前一階段的所有作業均已成功完成. 在這種情況下，我們將所有工作從下一階段過渡到`pending` . 4. 該作業使用`needs:`指定了 DAG 依賴項`needs:`并且所有依賴項都已完成. 連接了 Runner 時，它將通過連續輪詢服務器來請求下一個`pending`作業運行. **注意：** Runner 用于與 GitLab 交互的 API 端點在[`lib/api/runner.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/api/runner.rb)中定義服務器收到請求后，將根據[`Ci::RegisterJobService`算法](#ciregisterjobservice)選擇`pending`作業，然后將其分配并發送給 Runner. 在當前階段完成所有作業后，服務器通過將其狀態更改為" `pending` "，從下一階段"解鎖"所有作業. 現在，當 Runner 請求新作業時，可以由調度算法選擇這些內容，并像這樣繼續進行，直到完成所有階段. ### Communication between Runner and GitLab server[](#communication-between-runner-and-gitlab-server "Permalink") 使用注冊令牌[注冊](https://docs.gitlab.com/runner/register/)了 Runner 之后，服務器便知道其可以執行的作業類型. 這取決于： * 它注冊的賽跑者類型為： * 共享跑步者 * 團體賽跑者 * 項目特定的跑步者 * 任何關聯的標簽. 跑步者通過請求作業執行`POST /api/v4/jobs/request`來啟動通信. 盡管輪詢通常每隔幾秒鐘發生一次，但如果作業隊列不變，我們將通過 HTTP 標頭利用緩存來減少服務器端的工作量. 該 API 端點運行[`Ci::RegisterJobService`](https://gitlab.com/gitlab-org/gitlab/blob/master/app/services/ci/register_job_service.rb) ，該命令： 1. 從`pending`作業池中選擇要運行的下一個作業 2. 分配給跑步者 3. 通過 API 響應將其呈現給 Runner ### `Ci::RegisterJobService`[](#ciregisterjobservice "Permalink") 此服務使用 3 個頂級查詢來收集大多數作業，并且根據 Runner 注冊到的級別選擇它們： * 選擇共享的 Runner（實例級別）的作業 * 選擇組級別運行器的作業 * 選擇項目亞軍的工作 This list of jobs is then filtered further by matching tags between job and Runner tags. **注意：**如果作業包含標簽，則與**所有**標簽都不匹配的跑步者將不會選擇該作業. 跑步者可能具有比該工作定義的標簽更多的標簽，但反之則沒有. 最后，如果 Runner 僅能選擇帶標簽的作業，則所有未帶標簽的作業都會被過濾掉. 在這一點上，我們遍歷剩余的`pending`作業，然后嘗試根據其他策略分配"可以選擇" Runner 可以選擇的第一個作業. 例如，標記為`protected`運行者只能選擇針對受保護的分支（例如生產部署）運行的作業. 當我們增加池中的"奔跑者"數量時，如果將同一工作分配給不同"奔跑者"，也會增加發生沖突的機會. 為防止這種情況，我們會適當地挽救沖突錯誤并在列表中分配下一個作業.