205.md

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