{{< details >}}

  • Tier: 基础版, 专业版, 旗舰版
  • Offering: JihuLab.com, 私有化部署

{{< /details >}}

如果您正在从 GitHub Actions 迁移到 极狐GitLab CI/CD，您可以创建 CI/CD 流水线以复制和增强您的 GitHub Action 工作流。

关键相似点和差异

GitHub Actions 和 极狐GitLab CI/CD 都用于生成流水线，以自动化构建、测试和部署代码。两者共享的相似点包括：

  • CI/CD 功能可以直接访问存储在项目仓库中的代码。
  • 流水线配置使用 YAML 编写并存储在项目仓库中。
  • 流水线是可配置的，可以在不同阶段运行。
  • 每个作业可以使用不同的容器镜像。

此外，二者之间还有一些重要的差异：

  • GitHub 有一个用于下载第三方操作的市场，可能需要额外的支持或许可证。
  • 极狐GitLab 私有化部署支持水平和垂直扩展，而 GitHub Enterprise Server 仅支持垂直扩展。
  • 极狐GitLab 在内部维护和支持所有功能，某些第三方集成可以通过模板访问。
  • 极狐GitLab 提供内置的容器注册表。
  • 极狐GitLab 具有原生的 Kubernetes 部署支持。
  • 极狐GitLab 提供细粒度的安全策略。

功能和概念比较

GitHub 的许多功能和概念在 极狐GitLab 中有对应的功能。

配置文件

GitHub Actions 可以使用工作流 YAML 文件进行配置。极狐GitLab CI/CD 默认使用 .gitlab-ci.yml YAML 文件。

例如，在 GitHub Actions workflow 文件中：

on: [push]
jobs:
  hello:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello World"

等效的 极狐GitLab CI/CD .gitlab-ci.yml 文件为：

stages:
  - hello

hello:
  stage: hello
  script:
    - echo "Hello World"

GitHub Actions 工作流语法

GitHub Actions 配置在 workflow YAML 文件中使用特定的关键字定义。极狐GitLab CI/CD 具有类似的功能，通常也使用 YAML 关键字进行配置。

GitHub 极狐GitLab 解释
env variables env 定义在工作流、作业或步骤中设置的变量。极狐GitLab 使用 variables 来定义CI/CD 变量，可以在全局或作业级别进行定义。变量也可以在 UI 中添加。
jobs stages jobs 将所有在工作流中运行的作业组合在一起。极狐GitLab 使用 stages 将作业组合在一起。
on 不适用 on 定义何时触发工作流。极狐GitLab 与 Git 紧密集成，因此不需要 SCM 轮询选项进行触发配置，但如果需要，可以对每个作业进行配置。
run 不适用 在作业中执行的命令。极狐GitLab 使用 YAML 数组在 script 关键字下，一条命令一个条目。
runs-on tags runs-on 定义作业必须运行的 GitHub runner。极狐GitLab 使用 tags 选择 runner。
steps script steps 将在作业中运行的所有步骤组合在一起。极狐GitLab 使用 script 将在作业中运行的所有命令组合在一起。
uses include uses 定义要添加到 step 的 GitHub Action。极狐GitLab 使用 include 从其他文件中添加配置到作业。

常见配置

本节介绍常用的 CI/CD 配置，展示如何从 GitHub Actions 转换到 极狐GitLab CI/CD。

GitHub Action 工作流生成自动化的 CI/CD 作业，当发生某些事件时触发，例如推送新的提交。GitHub Action 工作流是在仓库根目录的 .github/workflows 目录中定义的 YAML 文件。极狐GitLab 的等效配置文件为 .gitlab-ci.yml，也位于仓库的根目录。

作业

作业是一组按顺序运行的命令，以实现特定结果，例如构建容器或部署到生产环境。

例如，这个 GitHub Actions workflow 构建一个容器，然后部署到生产环境。作业按顺序运行，因为 deploy 作业依赖于 build 作业：

on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    container: golang:alpine
    steps:
      - run: apk update
      - run: go build -o bin/hello
      - uses: actions/upload-artifact@v3
        with:
          name: hello
          path: bin/hello
          retention-days: 7
  deploy:
    if: contains( github.ref, 'staging')
    runs-on: ubuntu-latest
    container: golang:alpine
    steps:
      - uses: actions/download-artifact@v3
        with:
          name: hello
      - run: echo "Deploying to Staging"
      - run: scp bin/hello remoteuser@remotehost:/remote/directory

这个示例：

  • 使用 golang:alpine 容器镜像。
  • 运行用于构建代码的作业。
    • 将构建的可执行文件存储为产物。
  • 运行第二个作业以部署到 staging，还包括：
    • 需要构建作业成功后才能运行。
    • 需要提交目标分支为 staging。
    • 使用构建的可执行文件产物。

等效的 极狐GitLab CI/CD .gitlab-ci.yml 文件为：

default:
  image: golang:alpine

stages:
  - build
  - deploy

build-job:
  stage: build
  script:
    - apk update
    - go build -o bin/hello
  artifacts:
    paths:
      - bin/hello
    expire_in: 1 week

deploy-job:
  stage: deploy
  script:
    - echo "Deploying to Staging"
    - scp bin/hello remoteuser@remotehost:/remote/directory
  rules:
    - if: $CI_COMMIT_BRANCH == 'staging'

并行

在 GitHub 和 极狐GitLab 中，作业默认是并行运行的。

例如，在 GitHub Actions workflow 文件中：

on: [push]
jobs:
  python-version:
    runs-on: ubuntu-latest
    container: python:latest
    steps:
      - run: python --version
  java-version:
    if: contains( github.ref, 'staging')
    runs-on: ubuntu-latest
    container: openjdk:latest
    steps:
      - run: java -version

这个示例使用不同的容器镜像并行运行 Python 作业和 Java 作业。Java 作业仅在 staging 分支发生变更时运行。

等效的 极狐GitLab CI/CD .gitlab-ci.yml 文件为：

python-version:
  image: python:latest
  script:
    - python --version

java-version:
  image: openjdk:latest
  rules:
    - if: $CI_COMMIT_BRANCH == 'staging'
  script:
    - java -version

在这种情况下，不需要额外配置来使作业并行运行。作业默认是并行运行的，每个作业在不同的 runner 上运行，假设有足够的 runner 来运行所有作业。Java 作业设置为仅在 staging 分支发生变更时运行。

矩阵

在极狐GitLab 和 GitHub 中，您可以使用矩阵在单个流水线中并行多次运行作业，但每个作业实例使用不同的变量值。

例如，在 GitHub Actions workflow 文件中：

on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Building $PLATFORM for $ARCH"
    strategy:
      matrix:
        platform: [linux, mac, windows]
        arch: [x64, x86]
  test:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Testing $PLATFORM for $ARCH"
    strategy:
      matrix:
        platform: [linux, mac, windows]
        arch: [x64, x86]
  deploy:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying $PLATFORM for $ARCH"
    strategy:
      matrix:
        platform: [linux, mac, windows]
        arch: [x64, x86]

等效的 极狐GitLab CI/CD .gitlab-ci.yml 文件为：

stages:
  - build
  - test
  - deploy

.parallel-hidden-job:
  parallel:
    matrix:
      - PLATFORM: [linux, mac, windows]
        ARCH: [x64, x86]

build-job:
  extends: .parallel-hidden-job
  stage: build
  script:
    - echo "Building $PLATFORM for $ARCH"

test-job:
  extends: .parallel-hidden-job
  stage: test
  script:
    - echo "Testing $PLATFORM for $ARCH"

deploy-job:
  extends: .parallel-hidden-job
  stage: deploy
  script:
    - echo "Deploying $PLATFORM for $ARCH"

触发器

GitHub Actions 需要为您的工作流添加触发器。极狐GitLab 与 Git 紧密集成，因此不需要 SCM 轮询选项进行触发配置，但如果需要，可以对每个作业进行配置。

GitHub Actions 配置示例：

on:
  push:
    branches:
      - main

等效的 极狐GitLab CI/CD 配置为：

rules:
  - if: '$CI_COMMIT_BRANCH == main'

流水线也可以通过 使用 Cron 语法进行调度。

容器镜像

使用 极狐GitLab，您可以通过使用 image 关键字 在单独的、隔离的 Docker 容器中运行您的 CI/CD 作业。

例如，在 GitHub Actions workflow 文件中：

jobs:
  update:
    runs-on: ubuntu-latest
    container: alpine:latest
    steps:
      - run: apk update

在这个示例中，apk update 命令在 alpine:latest 容器中运行。

等效的 极狐GitLab CI/CD .gitlab-ci.yml 文件为：

update-job:
  image: alpine:latest
  script:
    - apk update

极狐GitLab 为每个项目提供一个 容器注册表 来托管容器镜像。容器镜像可以直接从 极狐GitLab CI/CD 流水线构建和存储。

例如：

stages:
  - build

build-image:
  stage: build
  variables:
    IMAGE: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $IMAGE .
    - docker push $IMAGE

变量

在 极狐GitLab 中，我们使用 variables 关键字在运行时定义不同的 CI/CD 变量。当您需要在流水线中重用配置数据时使用变量。您可以全局或为每个作业定义变量。

例如，在 GitHub Actions workflow 文件中：

env:
  NAME: "fern"

jobs:
  english:
    runs-on: ubuntu-latest
    env:
      Greeting: "hello"
    steps:
      - run: echo "$GREETING $NAME"
  spanish:
    runs-on: ubuntu-latest
    env:
      Greeting: "hola"
    steps:
      - run: echo "$GREETING $NAME"

在这个示例中，变量为作业提供不同的输出。

等效的 极狐GitLab CI/CD .gitlab-ci.yml 文件为：

default:
  image: ubuntu-latest

variables:
  NAME: "fern"

english:
  variables:
    GREETING: "hello"
  script:
    - echo "$GREETING $NAME"

spanish:
  variables:
    GREETING: "hola"
  script:
    - echo "$GREETING $NAME"

变量也可以通过 极狐GitLab UI 在 CI/CD 设置中进行设置，您可以 保护 或 掩盖 变量。掩盖的变量在作业日志中是隐藏的，而保护的变量只能在受保护分支或标签的流水线中访问。

例如，在 GitHub Actions workflow 文件中：

jobs:
  login:
    runs-on: ubuntu-latest
    env:
      AWS_ACCESS_KEY: ${{ secrets.AWS_ACCESS_KEY }}
    steps:
      - run: my-login-script.sh "$AWS_ACCESS_KEY"

如果 AWS_ACCESS_KEY 变量在 极狐GitLab 项目设置中定义，则等效的 极狐GitLab CI/CD .gitlab-ci.yml 文件为：

login:
  script:
    - my-login-script.sh $AWS_ACCESS_KEY

此外，GitHub Actions 提供内置的变量，其中包含与流水线和仓库相关的数据。

条件

当一个新的流水线启动时，极狐GitLab 会检查流水线配置以确定哪些作业应该在该流水线中运行。您可以使用 rules 关键字 配置作业，决定是否根据变量状态或流水线类型运行。

例如，在 GitHub Actions workflow 文件中：

jobs:
  deploy_staging:
    if: contains( github.ref, 'staging')
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploy to staging server"

等效的 极狐GitLab CI/CD .gitlab-ci.yml 文件为：

deploy_staging:
  stage: deploy
  script:
    - echo "Deploy to staging server"
  rules:
    - if: '$CI_COMMIT_BRANCH == staging'

Runners

Runners 是执行作业的服务。如果您正在使用 JihuLab.com，您可以使用 实例 runner 集群 来运行作业，而无需配置自己的私有化部署 runner。

关于 runners 的一些关键细节：

  • Runners 可以被 配置 为共享给整个实例、群组或专用于单个项目。
  • 您可以使用 tags 关键字 进行更细粒度的控制，并将 runners 与特定作业关联。例如，您可以为需要专用、更强大的或特定硬件的作业使用标签。
  • 极狐GitLab 具有 runners 自动扩展功能。使用自动扩展仅在需要时配置 runners，并在不需要时缩减。

例如，在 GitHub Actions workflow 文件中：

linux_job:
  runs-on: ubuntu-latest
  steps:
    - run: echo "Hello, $USER"

windows_job:
  runs-on: windows-latest
  steps:
    - run: echo "Hello, %USERNAME%"

等效的 极狐GitLab CI/CD .gitlab-ci.yml 文件为：

linux_job:
  stage: build
  tags:
    - linux-runners
  script:
    - echo "Hello, $USER"

windows_job:
  stage: build
  tags:
    - windows-runners
  script:
    - echo "Hello, %USERNAME%"

产物

在 极狐GitLab 中，任何作业都可以使用 artifacts 关键字定义一组在作业完成时存储的产物。产物 是可以在后续作业中使用的文件。

例如，在 GitHub Actions workflow 文件中：

on: [push]
jobs:
  generate_cat:
    steps:
      - run: touch cat.txt
      - run: echo "meow" > cat.txt
      - uses: actions/upload-artifact@v3
        with:
          name: cat
          path: cat.txt
          retention-days: 7
  use_cat:
    needs: [generate_cat]
    steps:
      - uses: actions/download-artifact@v3
        with:
          name: cat
      - run: cat cat.txt

等效的 极狐GitLab CI/CD .gitlab-ci.yml 文件为：

stage:
  - generate
  - use

generate_cat:
  stage: generate
  script:
    - touch cat.txt
    - echo "meow" > cat.txt
  artifacts:
    paths:
      - cat.txt
    expire_in: 1 week

use_cat:
  stage: use
  script:
    - cat cat.txt

缓存

当一个作业下载一个或多个文件并保存它们以便将来更快访问时，会创建一个 缓存。使用相同缓存的后续作业无需再次下载文件，因此执行速度更快。缓存存储在 runner 上，并在启用 分布式缓存 时上传到 S3。

例如，在 GitHub Actions workflow 文件中：

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - run: echo "This job uses a cache."
    - uses: actions/cache@v3
      with:
        path: binaries/
        key: binaries-cache-$CI_COMMIT_REF_SLUG

等效的 极狐GitLab CI/CD .gitlab-ci.yml 文件为：

cache-job:
  script:
    - echo "This job uses a cache."
  cache:
    key: binaries-cache-$CI_COMMIT_REF_SLUG
    paths:
      - binaries/

模板

在 GitHub 中，Action 是一组需要频繁重复且复杂的任务，保存以便重用而无需重新定义 CI/CD 流水线。在 极狐GitLab 中，等效于一个 Action 的是 include 关键字，它允许您从其他文件添加 CI/CD 流水线，包括 极狐GitLab 内置的模板文件。

GitHub Actions 配置示例：

- uses: hashicorp/setup-terraform@v2.0.3

等效的 极狐GitLab CI/CD 配置为：

include:
  - template: Terraform.gitlab-ci.yml

在这些示例中，setup-terraform GitHub Action 和 Terraform.gitlab-ci.yml 极狐GitLab 模板不是完全匹配的。这两个示例只是为了展示如何重用复杂配置。

安全扫描功能

极狐GitLab 提供多种安全扫描器，可以检测 SLDC 中所有部分的漏洞。您可以通过使用模板将这些功能添加到您的 极狐GitLab CI/CD 流水线中。

例如，要将 SAST 扫描添加到您的流水线，请在 .gitlab-ci.yml 中添加以下内容：

include:
  - template: Jobs/SAST.gitlab-ci.yml

您可以通过使用 CI/CD 变量自定义安全扫描器的行为，例如使用 SAST 扫描器。

密钥管理

特权信息，通常称为“密钥”，是您在 CI/CD 工作流中需要的敏感信息或凭证。您可能会使用密钥来解锁受保护资源或敏感信息，应用于工具、应用程序、容器和云原生环境。

对于 极狐GitLab 中的密钥管理，您可以使用支持的外部服务集成之一。这些服务将密钥安全地存储在您的 极狐GitLab 项目之外，但您必须订阅该服务：

极狐GitLab 还支持 OIDC 认证，用于其他支持 OIDC 的第三方服务。

此外，您可以通过将凭证存储在 CI/CD 变量中来使其在作业中可用，尽管以纯文本存储的密钥容易意外泄露。您应该始终将敏感信息存储在 掩盖 和 保护 的变量中，以减轻一些风险。

此外，切勿在您的 .gitlab-ci.yml 文件中将密钥存储为变量，该文件对所有有项目访问权限的用户都是公开的。敏感信息的存储仅应在项目、群组或实例设置中进行。

查看安全指南，以提高您 CI/CD 变量的安全性。

规划和实施迁移

以下建议步骤列表是在观察能够快速完成迁移的组织后创建的。

创建迁移计划

在开始迁移之前，您应该创建一个迁移计划，为迁移做好准备。

先决条件

在进行任何迁移工作之前，您应该首先：

  1. 熟悉 极狐GitLab。
  2. 设置和配置 极狐GitLab。
  3. 测试您的 极狐GitLab 实例。
    • 确保有 runners 可用，可以使用共享的 JihuLab.com runners 或安装新的 runners。

迁移步骤

  1. 从 GitHub 迁移项目到 极狐GitLab：
  2. 在每个项目中创建 .gitlab-ci.yml。
  3. 将 GitHub Actions 作业迁移到 极狐GitLab CI/CD 作业并配置它们以直接在合并请求中显示结果。
  4. 通过使用 云部署模板、环境 和 极狐GitLab Kubernetes 代理迁移部署作业。
  5. 检查是否有任何 CI/CD 配置可以在不同项目中重用，然后创建和共享 CI/CD 模板
  6. 检查 流水线效率文档，了解如何使您的 极狐GitLab CI/CD 流水线更快、更高效。

如果您有此处未回答的问题，极狐GitLab 社区论坛 可以是一个很好的资源。