Skip to main content
我们经常发布文档更新，此页面的翻译可能仍在进行中。有关最新信息，请访问英文文档。如果此页面上的翻译有问题，请告诉我们。
Enterprise Server 3.1
简体中文
� 
GitHub Actions
Enterprise Server 3.1
简体中文

� 

此版本的 GitHub Enterprise 已停止服务 2022-06-03. 即使针对重大安全问题，也不会发布补丁。 要获得更好的性能、改进的安全性和新功能，请升级到 GitHub Enterprise 的最新版本。 如需升级方面的帮助，请联系 GitHub Enterprise 支持。

从 GitLab CI/CD 迁移到 GitHub Actions

本文内容

GitHub Actions 和 GitLab CI/CD 具有一些相似的配置，这使得迁移到 GitHub Actions 很简单。

注： GitHub 托管的运行器目前在 GitHub Enterprise Server 上不受支持。 您可以在 GitHub 公共路线图 上查看有关未来支持计划的更多信息。

简介

GitLab CI/CD 和 GitHub Actions 都允许您创建能自动构建、测试、发布、发行和部署代� �的工作流程。 GitLab CI/CD 和 GitHub Actions 的工作流程配置有一些相似之处：

  • 工作流程配置文件以 YAML 编写并存储在代� �仓库中。
  • 工作流程包括一项或多项作业。
  • 作业包括一个或多个步骤或单个命令。
  • 作业可以在托管或自托管计算机上运行。

存在一些区别，本指南将说明重要区别，以便您将工作流程迁移到 GitHub Actions。

Jobs

GitLab CI/CD 中的作业非常类似于 GitHub Actions 中的作业。 在这两个系统中，作业具有以下特征：

  • 作业包含一系列按顺序运行的步骤或脚本。
  • 作业可在单独的计算机或单独的容器中运行。
  • 默认情况下作业并行运行，但可以配置为按顺序运行。

可在作业中运行脚本或 shell 命令。 在 GitLab CI/CD 中，使用 script 键指定脚本步骤。 在 GitHub Actions 中，所有脚本都使用 run 键来指定。

下面是每个系统的语法示例：

GitLab CI/CD GitHub Actions 
job1: variables: GIT_CHECKOUT: "true" script: - echo "Run your script here"
 
jobs: job1: steps: - uses: actions/checkout@v2 - run: echo "Run your script here"

运行器

运行器是运行作业的机器。 GitLab CI/CD 和 GitHub Actions 提供托管和自托管的运行器变体。 在 GitLab CI/CD 中，tags 用于在不同的平台上运行作业，而在 GitHub Actions 中，它使用 runs-on 键运行。

下面是每个系统的语法示例：

GitLab CI/CD GitHub Actions 
windows_job: tags: - windows script: - echo Hello, %USERNAME%! linux_job: tags: - linux script: - echo "Hello, $USER!"
 
windows_job: runs-on: windows-latest steps: - run: echo Hello, %USERNAME%! linux_job: runs-on: ubuntu-latest steps: - run: echo "Hello, $USER!"

更多信息请参阅“GitHub Actions 的工作流程语法”。

Docker � 像

GitLab CI/CD 和 GitHub Actions 都支持在 Docker � 像中运行作业。 在 GitLab CI/CD 中，Docker � 像使用 image 键定义，而在 GitHub Actions 中，它使用 container 键定义。

下面是每个系统的语法示例：

GitLab CI/CD GitHub Actions 
my_job: image: node:10.16-jessie
 
jobs: my_job: container: node:10.16-jessie

更多信息请参阅“GitHub Actions 的工作流程语法”。

条件和表达式语法

GitLab CI/CD 使用 rules 确定作业是否在特定条件下运行。 GitHub Actions 使用 if 关键字使作业仅在满足条件时才运行。

下面是每个系统的语法示例：

GitLab CI/CD GitHub Actions 
deploy_prod: stage: deploy script: - echo "Deploy to production server" rules: - if: '$CI_COMMIT_BRANCH == "master"'
 
jobs: deploy_prod: if: contains( github.ref, 'master') runs-on: ubuntu-latest steps: - run: echo "Deploy to production server"

更多信息请参阅“表达式”。

作业之间的依赖关系

GitLab CI/CD 和 GitHub Actions 允许您为作业设置依赖项。 在这两个系统中，默认情况下作业并行运行，但 GitHub Actions 中的作业依赖项可以用 needs 键明确指定。 GitLab CI/CD 还具有 stages 的概念，其中作业分阶段同时运行，但下一阶段将在前一阶段的所有作业完成时开始。 您可以使用 needs 键在 GitHub Actions 中重新创建此情景。

下面是每个系统的语法示例： 工作流程首先同时运行两个名为 build_a 和 build_b 的作业， 当这些作业完成后，另一个名为 test_ab 的作业将运行。 最后，test_ab 完成后，depl_ab 作业运行。

GitLab CI/CD GitHub Actions 
stages: - build - test - deploy build_a: stage: build script: - echo "This job will run first." build_b: stage: build script: - echo "This job will run first, in parallel with build_a." test_ab: stage: test script: - echo "This job will run after build_a and build_b have finished." deploy_ab: stage: deploy script: - echo "This job will run after test_ab is complete"
 
jobs: build_a: runs-on: ubuntu-latest steps: - run: echo "This job will be run first." build_b: runs-on: ubuntu-latest steps: - run: echo "This job will be run first, in parallel with build_a" test_ab: runs-on: ubuntu-latest needs: [build_a,build_b] steps: - run: echo "This job will run after build_a and build_b have finished" deploy_ab: runs-on: ubuntu-latest needs: [test_ab] steps: - run: echo "This job will run after test_ab is complete"

更多信息请参阅“GitHub Actions 的工作流程语法”。

预定工作流程

GitLab CI/CD 和 GitHub Actions 允许您以特定的间隔运行工作流程。 在 GitLab CI/CD 中，管道计划使用 UI 配置，而在 GitHub Actions 中，您可以使用 "on" 键在预定的间隔时间触发工作流程。

更多信息请参阅“触发工作流程的事件”。

变量和机密

GitLab CI/CD 和 GitHub Actions 支持在管道或工作流程配置文件中设置环境变量，并使用 GitLab 或 GitHub Enterprise Server UI 创建密� �。

更多信息请参阅“环境变量”和“使用� 密密� �”。

缓存

GitLab CI/CD 和 GitHub Actions 在配置文件中提供了手动缓存工作流程文件的方法。

GitHub Actions caching is only available for repositories hosted on GitHub.com or GitHub Enterprise Server 3.5 and later. 更多信息请参阅“缓存依赖项以� 快工作流程”。

构件

GitLab CI/CD 和 GitHub Actions 都可以上� 作业创建的文件和目录作为构件。 在 GitHub Actions 中，构件可用于在多个作业中保留数据。

下面是每个系统的语法示例：

GitLab CI/CD GitHub Actions 
script: artifacts: paths: - math-homework.txt
 
- name: Upload math result for job 1 uses: actions/upload-artifact@v2 with: name: homework path: math-homework.txt

更多信息请参阅“将工作流程存储为构件”。

数据库和服务容器

这两个系统都允许您包括用于数据库、缓存或其他依赖项的其他容器。

在 GitLab CI/CD 中，作业的容器使用 image 键指定，而 GitHub Actions 使用 container 键指定。 在这两个系统中，使用 services 键指定附� 服务容器。

下面是每个系统的语法示例：

GitLab CI/CD GitHub Actions 
container-job: variables: POSTGRES_PASSWORD: postgres # The hostname used to communicate with the # PostgreSQL service container POSTGRES_HOST: postgres # The default PostgreSQL port POSTGRES_PORT: 5432 image: node:10.18-jessie services: - postgres script: # Performs a clean installation of all dependencies # in the `package.json` file - npm ci # Runs a script that creates a PostgreSQL client, # populates the client with data, and retrieves data - node client.js tags: - docker
 
jobs: container-job: runs-on: ubuntu-latest container: node:10.18-jessie services: postgres: image: postgres env: POSTGRES_PASSWORD: postgres steps: - name: Check out repository code uses: actions/checkout@v2 # Performs a clean installation of all dependencies # in the `package.json` file - name: Install dependencies run: npm ci - name: Connect to PostgreSQL # Runs a script that creates a PostgreSQL client, # populates the client with data, and retrieves data run: node client.js env: # The hostname used to communicate with the # PostgreSQL service container POSTGRES_HOST: postgres # The default PostgreSQL port POSTGRES_PORT: 5432

更多信息请参阅“关于服务容器”。