Migrating from CircleCI · Gitlab 中文文檔

# Migrating from CircleCI > 原文：[https://docs.gitlab.com/ee/ci/migration/circleci.html](https://docs.gitlab.com/ee/ci/migration/circleci.html) * [`config.yml` vs `gitlab-ci.yml`](#configyml-vs-gitlab-ciyml) * [Jobs](#jobs) * [Docker image definition](#docker-image-definition) * [Workflows](#workflows) * [Parallel and sequential job execution](#parallel-and-sequential-job-execution) * [Scheduled run](#scheduled-run) * [Manual run](#manual-run) * [Filter job by branch](#filter-job-by-branch) * [Caching](#caching) * [Contexts and variables](#contexts-and-variables) * [Orbs](#orbs) * [Build environments](#build-environments) * [Machine and specific build environments](#machine-and-specific-build-environments) # Migrating from CircleCI[](#migrating-from-circleci "Permalink") 如果您當前正在使用 CircleCI，則可以將 CI / CD 管道遷移到[GitLab CI / CD](../introduction/index.html) ，并開始使用其所有強大功能. 查看我們的[CircleCI 與 GitLab](https://about.gitlab.com/devops-tools/circle-ci-vs-gitlab.html)比較，以了解有什么不同. 在開始遷移之前，我們已經收集了一些您可能會覺得有用的資源. [快速入門指南](../quick_start/README.html)很好地概述了 GitLab CI / CD 的工作方式. 您可能還對[Auto DevOps](../../topics/autodevops/index.html)感興趣，可以將其用于構建，測試和部署應用程序，而幾乎不需要或根本不需要進行任何配置. 對于高級 CI / CD 團隊， [自定義項目模板](../../user/admin_area/custom_project_templates.html)可以啟用管道配置的重用. 如果您有未在此處回答的問題， [GitLab 社區論壇](https://forum.gitlab.com/)將是一個很好的資源. ## `config.yml` vs `gitlab-ci.yml`[](#configyml-vs-gitlab-ciyml "Permalink") CircleCI 的`config.yml`配置文件定義了腳本，作業和工作流程（在 GitLab 中稱為"階段"）. 在 GitLab 中，對存儲庫根目錄中的`.gitlab-ci.yml`文件使用類似的方法. ### Jobs[](#jobs "Permalink") 在 CircleCI 中，作業是執行特定任務的步驟的集合. 在 GitLab 中， [作業](../yaml/README.html#introduction)也是配置文件中的基本元素. 在 GitLab CI / CD 中，不需要`checkout`參數，因為系統會自動獲取存儲庫. CircleCI 示例作業定義： ``` jobs: job1: steps: - checkout - run: "execute-script-for-job1" ``` GitLab CI / CD 中相同作業定義的示例： ``` job1: script: "execute-script-for-job1" ``` ### Docker image definition[](#docker-image-definition "Permalink") CircleCI 在作業級別定義圖像，GitLab CI / CD 也支持該圖像. 此外，GitLab CI / CD 支持全局設置此設置，以供所有未定義`image`作業使用. CircleCI 示例圖像定義： ``` jobs: job1: docker: - image: ruby:2.6 ``` Example of the same image definition in GitLab CI/CD: ``` job1: image: ruby:2.6 ``` ### Workflows[](#workflows "Permalink") CircleCI 確定具有`workflows`作業的運行順序. 這也可用于確定并發，順序，計劃或手動運行. GitLab CI / CD 中的等效功能稱為[stage](../yaml/README.html#stages) . 同一階段的作業并行運行，并且僅在先前階段完成后才運行. 默認情況下，當作業失敗時，將跳過下一階段的執行，但是即使[在](../yaml/README.html#allow_failure)作業失敗之后，也可以繼續執行下一階段. 有關可使用的不同類型的管道的指南，請參見["管道體系結構概述](../pipelines/pipeline_architectures.html) ". 可以定制管道來滿足您的需求，例如大型復雜項目或具有獨立定義組件的 monorepo. #### Parallel and sequential job execution[](#parallel-and-sequential-job-execution "Permalink") 以下示例顯示了作業如何并行或順序運行： 1. `job1`和`job2`并行運行（在 GitLab CI / CD 的`build`階段）. 2. 僅在`job1`和`job2`成功完成之后（在`test`階段）， `job1` `job3`運行. 3. 僅在`job3`成功完成之后（在`deploy`階段）， `job3` `job4`運行. CircleCI `workflows`示例： ``` version: 2 jobs: job1: steps: - checkout - run: make build dependencies job2: steps: - run: make build artifacts job3: steps: - run: make test job4: steps: - run: make deploy workflows: version: 2 jobs: - job1 - job2 - job3: requires: - job1 - job2 - job4: requires: - job3 ``` 與 GitLab CI / CD 中的`stages`相同的工作流程示例： ``` stages: - build - test - deploy job 1: stage: build script: make build dependencies job 2: stage: build script: make build artifacts job3: stage: test script: make test job4: stage: deploy script: make deploy ``` #### Scheduled run[](#scheduled-run "Permalink") GitLab CI / CD 具有易于使用的 UI 來[調度管道](../pipelines/schedules.html) . 同樣，可以使用[規則](../yaml/README.html#rules)來確定是否應將作業包括在計劃的管道中或從計劃的管道中排除. 計劃的工作流程的 CircleCI 示例： ``` commit-workflow: jobs: - build scheduled-workflow: triggers: - schedule: cron: "0 1 * * *" filters: branches: only: try-schedule-workflow jobs: - build ``` 使用 GitLab CI / CD 中的[`rules`](../yaml/README.html#rules)使用同一調度管道的示例： ``` job1: script: - make build rules: - if: '$CI_PIPELINE_SOURCE == "schedule" && $CI_COMMIT_REF_NAME == "try-schedule-workflow"' ``` 保存管道配置后，您可以在[GitLab UI 中](../pipelines/schedules.html#configuring-pipeline-schedules)配置 cron 計劃，并且還可以在 UI 中啟用或禁用計劃. #### Manual run[](#manual-run "Permalink") 手動工作流程的 CircleCI 示例： ``` release-branch-workflow: jobs: - build - testing: requires: - build - deploy: type: approval requires: - testing ``` 使用[`when: manual`](../yaml/README.html#whenmanual) GitLab CI / CD 中的[`when: manual`](../yaml/README.html#whenmanual)的相同工作流程示例： ``` deploy_prod: stage: deploy script: - echo "Deploy to production server" when: manual ``` ### Filter job by branch[](#filter-job-by-branch "Permalink") [規則](../yaml/README.html#rules)是一種機制，用于確定作業是否將針對特定分支運行. 按分支過濾的作業的 CircleCI 示例： ``` jobs: deploy: branches: only: - master - /rc-.*/ ``` 在 GitLab CI / CD 中使用`rules`的相同工作流程示例： ``` deploy_prod: stage: deploy script: - echo "Deploy to production server" rules: - if: '$CI_COMMIT_BRANCH == "master"' ``` ### Caching[](#caching "Permalink") GitLab 提供了一種緩存機制，可通過重用以前下載的依賴項來加快作業的構建時間. 重要的是要了解[緩存和工件](../caching/index.html#cache-vs-artifacts)之間的區別，以充分利用這些功能. 使用緩存的作業的 CircleCI 示例： ``` jobs: job1: steps: - restore_cache: key: source-v1-< .Revision > - checkout - run: npm install - save_cache: key: source-v1-< .Revision > paths: - "node_modules" ``` 在 GitLab CI / CD 中使用`cache`的同一管道的示例： ``` image: node:latest # Cache modules in between jobs cache: key: $CI_COMMIT_REF_SLUG paths: - .npm/ before_script: - npm ci --cache .npm --prefer-offline test_async: script: - node ./specs/start.js ./specs/async.spec.js ``` ## Contexts and variables[](#contexts-and-variables "Permalink") CircleCI 提供了[上下文，](https://s0circleci0com.icopy.site/docs/2.0/contexts/)以跨項目管道安全地傳遞環境變量. 在 GitLab 中，可以創建一個[組](../../user/group/index.html)來將相關項目組裝在一起. 在組級別， [變量](../variables/README.html#group-level-environment-variables)可以存儲在各個項目之外，并安全地傳遞到跨多個項目的管道中. ## Orbs[](#orbs "Permalink") 有兩個 GitLab 問題需要解決 CircleCI Orb，以及 GitLab 如何實現類似功能. * [https://gitlab.com/gitlab-com/Product/-/issues/1151](https://gitlab.com/gitlab-com/Product/-/issues/1151) * [https://gitlab.com/gitlab-org/gitlab/-/issues/195173](https://gitlab.com/gitlab-org/gitlab/-/issues/195173) ## Build environments[](#build-environments "Permalink") CircleCI 為`executors`提供`executors`特定工作的基礎技術. 在 GitLab 中，這是由[Runners](https://docs.gitlab.com/runner/)完成的. 支持以下環境：自我管理的跑步者： * Linux * Windows * macOS GitLab.com 共享跑步者： * Linux * Windows * [Planned: macOS](https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/5720) ### Machine and specific build environments[](#machine-and-specific-build-environments "Permalink") 通過告訴 GitLab 哪些 Runners 應該運行作業， [標簽](../yaml/README.html#tags)可以用于在不同平臺上運行作業. 在特定環境中運行的作業的 CircleCI 示例： ``` jobs: ubuntuJob: machine: image: ubuntu-1604:201903-01 steps: - checkout - run: echo "Hello, $USER!" osxJob: macos: xcode: 11.3.0 steps: - checkout - run: echo "Hello, $USER!" ``` 在 GitLab CI / CD 中使用`tags`進行同一作業的示例： ``` windows job: stage: - build tags: - windows script: - echo Hello, %USERNAME%! osx job: stage: - build tags: - osx script: - echo "Hello, $USER!" ```