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!" ```