关于使用 GitHub Actions Importer 从 Azure DevOps 迁移
以下说明将指导你配置环境以使用 GitHub Actions Importer 将 Azure DevOps 管道迁移到 GitHub Actions。
先决条件
- 具有要转换为 GitHub Actions 工作流的项目和管道的 Azure DevOps 帐户或组织。
- 有权为帐户或组织创建 Azure DevOps personal access token。
- 一个可在其中运行基于 Linux 的容器并可安装所需工具的环境。
-
Docker 已安装并正在运行。
-
已安装 GitHub CLI。
Note
GitHub Actions Importer 容器和 CLI 不需要安装在 CI 平台所在的同一服务器上。
-
限制
使用 GitHub Actions Importer 从 Azure DevOps 迁移到 GitHub Actions 时,存在一些限制:
- GitHub Actions Importer 需要 Azure DevOps API 版本 5.0,可在 Azure DevOps Services 或 Azure DevOps Server 2019 中使用。 较旧版本的 Azure DevOps Server 不兼容。
- 隐式添加到 Azure DevOps 管道的任务(例如签出源代码)可能会作为 GUID 名称添加到 GitHub Actions Importer 审核中。 若要查找 GUID 的友好任务名称,可使用以下 URL:
https://dev.azure.com/:organization/_apis/distributedtask/tasks/:guid
。
手动任务
某些 Azure DevOps 构造必须从 Azure DevOps 手动迁移到 GitHub Actions 配置。 其中包括:
- 组织、存储库和环境机密
- 服务连接,例如 OIDC Connect、GitHub Apps 和 personal access tokens
- 未知任务
- 自托管代理
- 环境
- 预先部署审批
有关手动迁移的详细信息,请参阅“从 Azure Pelines 迁移到 GitHub Actions”。
不支持的任务
GitHub Actions Importer 不支持迁移以下任务:
- 预先部署入口
- 后期部署入口
- 后期部署审批
- 某些资源触发器
安装 GitHub Actions Importer CLI 扩展
-
安装 GitHub Actions Importer CLI 扩展:
Bash gh extension install github/gh-actions-importer
gh extension install github/gh-actions-importer
-
验证是否已安装扩展:
$ gh actions-importer -h Options: -?, -h, --help Show help and usage information Commands: update Update to the latest version of GitHub Actions Importer. version Display the version of GitHub Actions Importer. configure Start an interactive prompt to configure credentials used to authenticate with your CI server(s). audit Plan your CI/CD migration by analyzing your current CI/CD footprint. forecast Forecast GitHub Actions usage from historical pipeline utilization. dry-run Convert a pipeline to a GitHub Actions workflow and output its yaml file. migrate Convert a pipeline to a GitHub Actions workflow and open a pull request with the changes.
配置凭据
configure
CLI 命令用于在使用 Azure DevOps 和 GitHub 时为 GitHub Actions Importer 设置所需的凭据和选项。
-
创建 GitHub personal access token (classic)。 有关详细信息,请参阅“管理个人访问令牌”。
令牌必须具有
workflow
范围。创建令牌后,将其复制并保存在安全的位置供之后使用。
-
创建 Azure DevOps personal access token。 有关详细信息,请参阅 Azure DevOps 文档中的使用 personal access tokens。 令牌必须具有以下范围:
- 代理池:
Read
- 生成:
Read
- 代码:
Read
- 发布:
Read
- 服务连接:
Read
- 任务组:
Read
- 变量组:
Read
创建令牌后,将其复制并保存在安全的位置供之后使用。
- 代理池:
-
在终端中,运行 GitHub Actions Importer
configure
CLI 命令:gh actions-importer configure
configure
命令将提示你输入以下信息:- 对于“正在配置哪些 CI 提供程序?”,请使用箭头键选择
Azure DevOps
,按空格键将其选中,然后按 Enter。 - 对于“Personal access token for GitHub”,输入前面创建的 personal access token (classic) 的值,然后按 Enter。
- 对于“GitHub 实例的基 URL”,输入 GitHub Enterprise Server 实例的 URL,然后按 Enter。
- 对于“Personal access token for Azure DevOps”,请输入前面创建的 Azure DevOps personal access token 的值,然后按 Enter。
- 对于“Azure DevOps 实例的基 URL”,请按 Enter 以接受默认值 (
https://dev.azure.com
)。 - 对于“Azure DevOps 组织名称”,请输入 Azure DevOps 组织的名称,然后按 Enter。
- 对于“Azure DevOps 项目名称”,请输入 Azure DevOps 项目的名称,然后按 Enter。
configure
命令的示例如下所示:$ gh actions-importer configure ✔ Which CI providers are you configuring?: Azure DevOps Enter the following values (leave empty to omit): ✔ Personal access token for GitHub: *************** ✔ Base url of the GitHub instance: https://github.com ✔ Personal access token for Azure DevOps: *************** ✔ Base url of the Azure DevOps instance: https://dev.azure.com ✔ Azure DevOps organization name: :organization ✔ Azure DevOps project name: :project Environment variables successfully updated.
- 对于“正在配置哪些 CI 提供程序?”,请使用箭头键选择
-
在终端中,运行 GitHub Actions Importer
update
CLI 命令以连接到 GitHub Packages Container registry,并确保容器映像已更新到最新版本:gh actions-importer update
命令的输出应类似于以下内容:
Updating ghcr.io/actions-importer/cli:latest... ghcr.io/actions-importer/cli:latest up-to-date
对 Azure DevOps 执行审核
可以使用 audit
命令获取 Azure DevOps 组织中所有项目的概要视图。
audit
命令执行以下步骤:
- 提取 Azure DevOps 组织中定义的所有项目。
- 将每个管道转换为其等效的 GitHub Actions 工作流。
- 生成一个报告,汇总使用 GitHub Actions Importer 进行迁移的完成程度和复杂性。
运行审核命令
若要对 Azure DevOps 组织执行审核,请在终端中运行以下命令:
gh actions-importer audit azure-devops --output-dir tmp/audit
检查审核结果
指定的输出目录中的文件包含审核结果。 有关审核结果的摘要,请参阅 audit_summary.md
文件。
审核摘要包含以下部分。
管道
“管道”部分包含有关由 GitHub Actions Importer 完成的转换率的概要统计信息。
下面列出了“管道”部分中可能出现的一些关键术语:
- “成功”管道已将所有管道构造和单个项目自动转换为其 GitHub Actions 等效项。
- “部分成功”管道已转换所有管道构造,但有一些单个项目未自动转换为其 GitHub Actions 等效项。
- “不受支持”管道是 GitHub Actions Importer 不支持的定义类型。
- “失败”管道在转换时遇到错误。 这可能是以下三个原因之一造成的:
- 该管道最初配置错误且无效。
- GitHub Actions Importer 在转换它时遇到内部错误。
- 网络响应失败,导致管道无法访问,这通常是由于凭据无效所致。
生成步骤
“生成步骤”部分概述了跨所有管道使用的各个生成步骤,以及由 GitHub Actions Importer 自动转换的生成步骤数。
下面列出了“生成步骤”部分中可能出现的一些关键术语:
- “已知”生成步骤是自动转换为等效操作的步骤。
- “未知”生成步骤是未自动转换为等效操作的步骤。
- “不受支持”生成步骤是满足以下任一条件的步骤:
- 从根本上不受 GitHub Actions 支持。
- 以与 GitHub Actions 不兼容的方式进行配置。
- “操作”是转换后的工作流中使用的操作的列表。 这对于以下情况可能很重要:
- 如果使用 GitHub Enterprise Server,收集要同步到实例的操作列表。
- 定义所使用的操作的组织级允许列表。 此操作列表是安全或合规性团队可能需要审查的操作的综合列表。
手动任务
“手动任务”部分概述了 GitHub Actions Importer 无法自动完成且必须由你手动完成的任务。
下面列出了“手动任务”部分中可能出现的一些关键术语:
- “机密”是在转换后的管道中使用的存储库或组织级机密。 必须在 GitHub Actions 中手动创建这些机密,才能使这些管道正常运行。 有关详细信息,请参阅“在 GitHub Actions 中使用机密”。
- “自托管运行器”是指在转换后的管道中引用的运行器(不是 GitHub 托管的运行器)的标签。 需要手动定义这些运行器,才能使这些管道正常运行。
文件
审核报告的最后一部分提供审核期间写入磁盘的所有文件的清单。
每个管道文件都包含审核中的各种文件,包括:
- GitHub 中定义的原始管道。
- 用于转换管道的任何网络响应。
- 转换后的工作流文件。
- 可用于排查管道转换失败问题的堆栈跟踪。
此外,workflow_usage.csv
文件包含一个以逗号分隔的列表,其中列出了每个成功转换的管道所使用的所有操作、机密和运行器。 这有助于确定哪些工作流使用哪些操作、机密或运行器,并且可用于进行安全评审。
预测可能的 GitHub Actions 使用情况
可以使用 forecast
命令通过计算 Azure DevOps 中已完成管道运行的指标来预测可能的 GitHub Actions 使用情况。
运行预测命令
若要预测可能的 GitHub Actions 使用情况,请在终端中运行以下命令。 默认情况下,GitHub Actions Importer 在预测报告中包括过去七天的信息。
gh actions-importer forecast azure-devops --output-dir tmp/forecast_reports
检查预测报告
指定的输出目录中的 forecast_report.md
文件包含预测结果。
下面列出了预测报告中可能出现的一些关键术语:
-
“作业计数”是已完成作业的总数。
-
“管道计数”是使用的独立管道数。
-
“执行时间”指的是运行器在一项作业中所用的时间。 此指标可用于帮助计划 GitHub 托管的运行器的成本。
此指标与你应在 GitHub Actions 中花费的成本相关。 这会因这些分钟所使用的硬件而异。 可以使用 GitHub Actions 定价计算器来估算成本。
-
“队列时间”指标用于描述等待运行器可用于执行作业的时间。
-
“并发作业”指标用于描述在任何给定时间运行的作业数量。 此指标可用于定义应配置的运行器数。
此外,这些指标是针对 Azure DevOps 中的每个运行器队列定义的。 这在混合使用托管/自承载运行器或者高规格/低规格的计算机时特别有用,这样就可以查看特定于不同类型运行器的指标。
执行试运行迁移
可以使用 dry-run
命令将 Azure DevOps 管道转换为等效的 GitHub Actions 工作流。 试运行在指定目录中创建输出文件,但不打开拉取请求来迁移管道。
如果有任何 GitHub Actions Importer 无法自动转换的内容,例如未知生成步骤或部分成功管道,你可能需要创建自定义转换器来进一步自定义转换过程。 有关详细信息,请参阅“使用自定义转换器扩展 GitHub Actions 导入工具”。
为生成管道运行试运行命令
若要执行将 Azure DevOps 生成管道迁移到 GitHub Actions 的试运行,请在终端中运行以下命令,将 pipeline_id
替换为要转换的管道的 ID。
gh actions-importer dry-run azure-devops pipeline --pipeline-id :pipeline_id --output-dir tmp/dry-run
可以在指定的输出目录中查看试运行日志和转换后的工作流文件。
为发布管道运行试运行命令
若要执行将 Azure DevOps 发布管道迁移到 GitHub Actions 的试运行,请在终端中运行以下命令,将 pipeline_id
替换为要转换的管道的 ID。
gh actions-importer dry-run azure-devops release --pipeline-id :pipeline_id --output-dir tmp/dry-run
可以在指定的输出目录中查看试运行日志和转换后的工作流文件。
执行生产迁移
可以使用 migrate
命令转换 Azure DevOps 管道,并使用等效的 GitHub Actions 工作流打开拉取请求。
为生成管道运行迁移命令
若要将 Azure DevOps 生成管道迁移到 GitHub Actions,请在终端中运行以下命令,将 target-url
值替换为 GitHub 存储库的 URL,并将 pipeline_id
替换为要转换的管道的 ID。
gh actions-importer migrate azure-devops pipeline --pipeline-id :pipeline_id --target-url https://github.com/octo-org/octo-repo --output-dir tmp/migrate
命令的输出包括将转换后的工作流添加到存储库的拉取请求的 URL。 成功输出的示例类似于以下内容:
$ gh actions-importer migrate azure-devops pipeline --target-url https://github.com/octo-org/octo-repo --output-dir tmp/migrate --azure-devops-project my-azure-devops-project
[2022-08-20 22:08:20] Logs: 'tmp/migrate/log/actions-importer-20220916-014033.log'
[2022-08-20 22:08:20] Pull request: 'https://github.com/octo-org/octo-repo/pull/1'
为发布管道运行迁移命令
若要将 Azure DevOps 发布管道迁移到 GitHub Actions,请在终端中运行以下命令,将 target-url
值替换为 GitHub 存储库的 URL,并将 pipeline_id
替换为要转换的管道的 ID。
gh actions-importer migrate azure-devops release --pipeline-id :pipeline_id --target-url https://github.com/octo-org/octo-repo --output-dir tmp/migrate
命令的输出包括将转换后的工作流添加到存储库的拉取请求的 URL。 成功输出的示例类似于以下内容:
$ gh actions-importer migrate azure-devops release --target-url https://github.com/octo-org/octo-repo --output-dir tmp/migrate --azure-devops-project my-azure-devops-project
[2022-08-20 22:08:20] Logs: 'tmp/migrate/log/actions-importer-20220916-014033.log'
[2022-08-20 22:08:20] Pull request: 'https://github.com/octo-org/octo-repo/pull/1'
检查拉取请求
migrate
命令成功运行的输出包含一个指向新拉取请求的链接,此拉取请求将转换后的工作流添加到存储库。
拉取请求的一些重要元素包括:
- 在拉取请求说明中,有一个名为“手动步骤”的部分,其中列出了在完成将管道迁移到 GitHub Actions 之前必须手动完成的步骤。 例如,此部分可能会提供创建工作流中使用的任何机密。
- 转换后的工作流文件。 选择拉取请求中的“已更改的文件”选项卡,查看将添加到 GitHub Enterprise Server 存储库的工作流文件。
检查完拉取请求后,可以将其合并以将工作流添加到 GitHub Enterprise Server 存储库。
参考
本部分包含使用 GitHub Actions Importer 从 Azure DevOps 迁移时涉及的环境变量、可选参数和支持的语法的参考信息。
配置环境变量
GitHub Actions Importer 使用环境变量进行身份验证配置。 这些变量在使用 configure
命令执行配置过程时设置。 有关详细信息,请参阅“配置凭据”部分。
GitHub Actions Importer 使用以下环境变量连接到 Azure DevOps 实例:
GITHUB_ACCESS_TOKEN
:用于通过转换后的工作流创建拉取请求的 personal access token (classic)(需要workflow
范围)。GITHUB_INSTANCE_URL
:目标 GitHub 实例的 URL(例如https://github.com
)。AZURE_DEVOPS_ACCESS_TOKEN
:用于向 Azure DevOps 实例进行身份验证的 personal access token。 此令牌需要以下范围:- 生成:
Read
- 代理池:
Read
- 代码:
Read
- 发布:
Read
- 服务连接:
Read
- 任务组:
Read
- 变量组:
Read
- 生成:
AZURE_DEVOPS_PROJECT
:迁移管道时要使用的项目名或 GUID。 如果要对所有项目执行审核,可选此项。AZURE_DEVOPS_ORGANIZATION
:Azure DevOps 实例的组织名称。AZURE_DEVOPS_INSTANCE_URL
:Azure DevOps 实例的 URL,例如https://dev.azure.com
。
这些环境变量可以在 GitHub Actions Importer 运行时加载的 .env.local
文件中指定。
可选自变量
有一些可选参数可以结合 GitHub Actions Importer 子命令使用来自定义迁移。
--source-file-path
可以将 --source-file-path
参数与 forecast
、dry-run
或 migrate
子命令结合使用。
默认情况下,GitHub Actions Importer 从源代码管理中提取管道内容。 --source-file-path
参数指示 GitHub Actions Importer 改用指定的源文件路径。
例如:
gh actions-importer dry-run azure-devops pipeline --output-dir ./output/ --source-file-path ./path/to/azure_devops/pipeline.yml
--config-file-path
可以将 --config-file-path
参数与 audit
、dry-run
和 migrate
子命令结合使用。
默认情况下,GitHub Actions Importer 从源代码管理中提取管道内容。 --config-file-path
参数指示 GitHub Actions Importer 改用指定的源文件。
--config-file-path
参数还可用于指定应将已转换的可重用工作流或复合操作迁移到哪个存储库。
“审核”示例
在此示例中,GitHub Actions Importer 使用指定的 YAML 配置文件作为源文件来执行审核。
gh actions-importer audit azure-devops pipeline --output-dir ./output/ --config-file-path ./path/to/azure_devops/config.yml
若要使用配置文件审核 Azure DevOps 实例,该配置文件必须采用以下格式,并且每个 repository_slug
值都必须是唯一的:
source_files:
- repository_slug: azdo-project/1
path: file.yml
- repository_slug: azdo-project/2
paths: path.yml
可通过组合 Azure DevOps 组织名称、项目名称和管道 ID 来生成管道的 repository_slug
。 例如,my-organization-name/my-project-name/42
。
试运行示例
在此示例中,GitHub Actions Importer 使用指定的 YAML 配置文件作为源文件来执行试运行。
通过匹配配置文件中的 repository_slug
与 --azure-devops-organization
和 --azure-devops-project
选项的值来选择管道。 然后,使用 path
拉取指定的源文件。
gh actions-importer dry-run azure-devops pipeline --output-dir ./output/ --config-file-path ./path/to/azure_devops/config.yml
指定已转换的可重用工作流和复合操作的存储库
GitHub Actions Importer 使用提供给 --config-file-path
参数的 YAML 文件来确定将已转换的可重用工作流和复合操作迁移到的存储库。
首先,应在不使用 --config-file-path
参数的情况下运行审核:
gh actions-importer audit azure-devops --output-dir ./output/
此命令的输出将包含名为 config.yml
的文件,其中包含由 GitHub Actions Importer 转换的所有可重用工作流和复合操作的列表。 例如,config.yml
文件可能包含以下内容:
reusable_workflows:
- name: my-reusable-workflow.yml
target_url: https://github.com/octo-org/octo-repo
ref: main
composite_actions:
- name: my-composite-action.yml
target_url: https://github.com/octo-org/octo-repo
ref: main
可以使用此文件指定应将可重用工作流或复合操作添加到哪个存储库和参考。 然后,可以使用 --config-file-path
参数将 config.yml
文件提供给 GitHub Actions Importer。 例如,可以在运行 migrate
命令时使用此文件,为配置文件中定义的每个唯一存储库打开拉取请求:
gh actions-importer migrate azure-devops pipeline --config-file-path config.yml --target-url https://github.com/my-org/my-repo
Azure DevOps 管道支持的语法
下表显示了 GitHub Actions Importer 当前能够转换的属性类型。
Azure Pipelines | GitHub Actions | 状态 |
---|---|---|
condition |
| 支持 |
container |
| 支持 |
continuousIntegration |
| 支持 |
作业 (job) |
| 支持 |
pullRequest |
| 支持 |
阶段 (stage) |
| 支持 |
steps |
| 支持 |
strategy |
| 支持 |
timeoutInMinutes |
| 支持 |
variables |
| 支持 |
手动部署 |
| 部分支持 |
pool |
| 部分支持 |
services |
| 部分支持 |
strategy |
| 部分支持 |
触发器 |
| 部分支持 |
pullRequest |
| 不支持 |
schedules |
| 不支持 |
触发器 |
| 不支持 |
有关支持的 Azure DevOps 任务的详细信息,请参阅 github/gh-actions-importer
存储库。
环境变量映射
GitHub Actions Importer 使用下表中的映射将默认 Azure DevOps 环境变量转换为 GitHub Actions 中最接近的等效项。
Azure Pipelines | GitHub Actions |
---|---|
$(Agent.BuildDirectory) | ${{ runner.workspace }} |
$(Agent.HomeDirectory) | ${{ env.HOME }} |
$(Agent.JobName) | ${{ github.job }} |
$(Agent.OS) | ${{ runner.os }} |
$(Agent.ReleaseDirectory) | ${{ github.workspace}} |
$(Agent.RootDirectory) | ${{ github.workspace }} |
$(Agent.ToolsDirectory) | ${{ runner.tool_cache }} |
$(Agent.WorkFolder) | ${{ github.workspace }} |
$(Build.ArtifactStagingDirectory) | ${{ runner.temp }} |
$(Build.BinariesDirectory) | ${{ github.workspace }} |
$(Build.BuildId) | ${{ github.run_id }} |
$(Build.BuildNumber) | ${{ github.run_number }} |
$(Build.DefinitionId) | ${{ github.workflow }} |
$(Build.DefinitionName) | ${{ github.workflow }} |
$(Build.PullRequest.TargetBranch) | ${{ github.base_ref }} |
$(Build.PullRequest.TargetBranch.Name) | ${{ github.base_ref }} |
$(Build.QueuedBy) | ${{ github.actor }} |
$(Build.Reason) | ${{ github.event_name }} |
$(Build.Repository.LocalPath) | ${{ github.workspace }} |
$(Build.Repository.Name) | ${{ github.repository }} |
$(Build.Repository.Provider) | GitHub |
$(Build.Repository.Uri) | ${{ github.server.url }}/${{ github.repository }} |
$(Build.RequestedFor) | ${{ github.actor }} |
$(Build.SourceBranch) | ${{ github.ref }} |
$(Build.SourceBranchName) | ${{ github.ref }} |
$(Build.SourceVersion) | ${{ github.sha }} |
$(Build.SourcesDirectory) | ${{ github.workspace }} |
$(Build.StagingDirectory) | ${{ runner.temp }} |
$(Pipeline.Workspace) | ${{ runner.workspace }} |
$(Release.DefinitionEnvironmentId) | ${{ github.job }} |
$(Release.DefinitionId) | ${{ github.workflow }} |
$(Release.DefinitionName) | ${{ github.workflow }} |
$(Release.Deployment.RequestedFor) | ${{ github.actor }} |
$(Release.DeploymentID) | ${{ github.run_id }} |
$(Release.EnvironmentId) | ${{ github.job }} |
$(Release.EnvironmentName) | ${{ github.job }} |
$(Release.Reason) | ${{ github.event_name }} |
$(Release.RequestedFor) | ${{ github.actor }} |
$(System.ArtifactsDirectory) | ${{ github.workspace }} |
$(System.DefaultWorkingDirectory) | ${{ github.workspace }} |
$(System.HostType) | build |
$(System.JobId) | ${{ github.job }} |
$(System.JobName) | ${{ github.job }} |
$(System.PullRequest.PullRequestId) | ${{ github.event.number }} |
$(System.PullRequest.PullRequestNumber) | ${{ github.event.number }} |
$(System.PullRequest.SourceBranch) | ${{ github.ref }} |
$(System.PullRequest.SourceRepositoryUri) | ${{ github.server.url }}/${{ github.repository }} |
$(System.PullRequest.TargetBranch) | ${{ github.event.base.ref }} |
$(System.PullRequest.TargetBranchName) | ${{ github.event.base.ref }} |
$(System.StageAttempt) | ${{ github.run_number }} |
$(System.TeamFoundationCollectionUri) | ${{ github.server.url }}/${{ github.repository }} |
$(System.WorkFolder) | ${{ github.workspace }} |
模板
可使用 GitHub Actions Importer 转换 Azure DevOps 模板。
限制
GitHub Actions Importer 能够转换 Azure DevOps 模板,但存在一些限制。
stages
、deployments
和jobs
键下使用的 Azure DevOps 模板可转换为 GitHub Actions 中的可重用工作流。 有关详细信息,请参阅“重新使用工作流”。steps
键下使用的 Azure DevOps 模板可转换为复合操作。 有关详细信息,请参阅“创建组合操作”。- 如果你当前具有引用其他作业模板的作业模板,GitHub Actions Importer 会将这些模板转换为可重用工作流。 由于可重用工作流不能引用其他可重用工作流,因此在 GitHub Actions 中,这是无效的语法。 必须手动更正嵌套的可重用工作流。
- 如果模板引用外部 Azure DevOps 组织或 GitHub 存储库,则必须使用
--credentials-file
选项提供凭据才能访问此模板。 有关详细信息,请参阅“补充参数和设置”。 - 可使用
each
表达式动态生成 YAML,但包含以下注意事项:- 不支持嵌套的
each
块,因此也不支持父each
块。 each
和包含的if
条件在转换时进行评估,因为 GitHub Actions 不支持这种插入方式。- 不支持
elseif
块。 如果需要此功能,则必须手动更正它们。 - 支持嵌套的
if
块,但不支持在if
条件下嵌套的if/elseif/else
块。 - 不支持使用预定义的 Azure DevOps 变量的
if
块。
- 不支持嵌套的
支持的模板
GitHub Actions Importer 支持下表中列出的模板。
Azure Pipelines | GitHub Actions | 状态 |
---|---|---|
从模板扩展 | Reusable workflow | 支持 |
作业模板 | Reusable workflow | 支持 |
阶段模板 | Reusable workflow | 支持 |
步骤模板 | Composite action | 支持 |
经典编辑器中的任务组 | 多种多样 | 支持 |
其他 Azure DevOps 组织、项目或存储库中的模板 | 多种多样 | 支持 |
GitHub 存储库中的模板 | 多种多样 | 支持 |
变量模板 | env | 支持 |
有条件插入 | 作业/步骤中的 if 条件 | 部分支持 |
迭代插入 | 不适用 | 部分支持 |
带参数的模板 | 多种多样 | 部分支持 |
模板文件路径名称
GitHub Actions Importer 可以提取文件名中包含变量、参数和迭代表达式的相对或动态文件路径的模板。 但是,必须设置默认值。
变量文件路径名示例
# File: azure-pipelines.yml
variables:
- template: 'templates/vars.yml'
steps:
- template: "./templates/$"
# File: templates/vars.yml
variables:
one: 'simple_step.yml'
参数文件路径名示例
parameters:
- name: template
type: string
default: simple_step.yml
steps:
- template: "./templates/${{ parameters.template }}"
迭代文件路径名示例
parameters:
- name: steps
type: object
default:
- build_step
- release_step
steps:
- ${{ each step in parameters.steps }}:
- template: "$-variables.yml"
模板参数
GitHub Actions Importer 支持下表中列出的参数。
Azure Pipelines | GitHub Actions | 状态 |
---|---|---|
string | inputs.string | 支持 |
数字 | inputs.number | 支持 |
boolean | inputs.boolean | 支持 |
object | 带 fromJSON 表达式的 inputs.string | 部分支持 |
步骤 | step | 部分支持 |
stepList | step | 部分支持 |
作业 (job) | job | 部分支持 |
jobList | job | 部分支持 |
部署 | job | 部分支持 |
deploymentList | job | 部分支持 |
阶段 (stage) | job | 部分支持 |
stageList | job | 部分支持 |
Note
如果在模板步骤的开头或结尾使用这些步骤,则 step
键下使用的具有此参数类型的模板将仅被序列化为复合操作。 具有此参数类型的 stage
、deployment
和 job
键下使用的模板不会转换为可重用工作流,而会被序列化为独立的工作流。
法律通告
部分内容改编自 MIT 许可证下的 https://github.com/github/gh-actions-importer/ :
MIT License
Copyright (c) 2022 GitHub
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.