使用 ACT 在本地开发和测试您的 GitHub 操作工作流
作者：互联网
act是一个命令行实用程序，可模拟 GitHub 操作环境，并允许您在开发人员笔记本电脑上而不是在 GitHub 操作环境中测试 GitHub 操作工作流。例如，您可以使用Mac进行安装。actbrew
壳
1
$ brew install act
在本地运行工作流
act使您能够在本地执行和调试 GitHub 操作工作流，从而在开发过程中提供更快的反馈循环。运行命令行将选取文件夹中的工作流并尝试执行它们。使用可以像以下那样简单：act.github/workflowsact
壳
1
$ act
act使用 Docker 创建与 GitHub Actions 执行环境非常相似的隔离环境。这确保了操作和工作流执行的一致性。如果您没有安装 Docker，则可以使用 Docker Desktop 或使用 Colima，这是一种在 macOS 上运行容器运行时的简单方法。
选手
定义工作流时，您可以在执行步骤时根据特定的虚拟机/环境指定运行器。
亚姆
1
jobs:
2
Build:
3
runs-on: ubuntu-latest
4
steps:
5
...
默认情况下， 在指定运行器时具有到特定 Docker 映像的映射。首次运行时，它会要求您为 .您可以从 3 种可映射到的基础映像类型中进行选择：actubuntu-latestactubuntu-latestubuntu-latest
最新的DZone参考卡
GitOps for Kubernetes
微码头工人镜像（节点：16-破坏者-苗条)
Medium Docker Image （catthehacker/ubuntu：act-latest)
大型 Docker Image （catthehacker/ubuntu：full-latest）
如果您对您选择的那个不满意，请不要担心。您始终可以通过更改用户主目录中的以下文件来更改默认选择。~/.actrc
大型 Docker 映像约为 18GB！！因此，我最初选择了中型映像，因为它应该包含大多数常用的系统依赖项。我很快就知道它包含相当多的库，但是当我尝试运行基于 Java + Maven 的项目时，我了解到它不包含 Apache Maven，而 GitHub 上的普通 Ubuntu-latest 确实包含它。
[CI/Build] Run Main Build
[CI/Build] docker exec cmd=[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/2] user= workdir=
| /var/run/act/workflow/2: line 2: mvn: command not found
[CI/Build] Failure - Main Build
[CI/Build] exitcode '127': command not found, please refer to https://github.com/nektos/act/issues/107 for more information
我不想切换到 18GB 的 docker 镜像来运行 Maven，所以我最终找到了 Jamez Perkins 的现有镜像。它只是获取原始行为图像并将Maven版本3.x添加到其中。您可以通过提供平台参数轻松指定使用自定义映像运行工作流。
壳
1
$ act -P ubuntu-latest=quay.io/jamezp/act-maven
使用该图像后，我的工作流运行没有任何错误。
使用多个作业/阶段
GitHub 操作工作流通常由一个或多个作业组成，这些作业将工作流的不同阶段分开。例如，您可能有一个生成、测试和部署阶段。
生成、测试和部署
通常，在生成作业中生成应用程序，并在部署作业中使用生成的项目。作业可以在不同的运行器上运行，因此在 GitHub 操作环境中，您可能会使用上传/下载工件操作，该操作将使用集中式存储在不同运行器之间共享工件。使用和共享项目时，需要具体说明需要存储项目的位置。为此，可以提供名为 的特定参数。act--artifact-server-path
壳
1
$ act -P ubuntu-latest=quay.io/jamezp/act-maven \
2
--artifact-server-path /tmp/act-artifacts
使用机密
最佳做法始终是将机密与工作流定义分开，并仅从特定机密存储中引用它们。使用 GitHub 操作时，可以将机密存储在内置的机密管理功能中。
要为操作提供密钥，您可以使用上下文访问您在存储库中创建的密钥。secrets
亚姆
1
jobs:
2
staticanalysis:
3
runs-on: ubuntu-latest
4
steps:
5
- uses: actions/checkout@v3
6
with:
7
# Disabling shallow clone is recommended for improving relevancy of reporting
8
fetch-depth: 0
9
- name: SonarQube Scan
10
uses: sonarsource/sonarqube-scan-action@master
11
env:
12
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
13
SONAR_HOST_URL: ${{ secrets.SONAR_URL }}
act没有可以指定机密的 UI，因此在测试工作流时，需要从命令行显式提供这些值或将它们存储在 .env 格式的文件中。如果只有几个密钥，则可以通过使用 -s 选项从命令行提供密钥来轻松添加它们。
壳
1
$ act -s SONAR_TOKEN=somevalue
2
$ act --secret-file my.secrets
使用环境变量
与机密类似，您有时会在工作流中使用环境变量。对于单个环境变量，您可以使用，或者如果您有一组环境变量，则可以创建一个文件，并通过提供参数从 CLI 提供对该文件的引用。--env myenv=foodotenv--env-file
壳
1
$ act --env-file my.env
该文件基于一个简单的标准文件格式，其中包含一组由新行划分的键值对。.env
纯文本
1
MY_ENV_VAR=MY_ENV_VAR_VALUE
2
MY_2ND_ENV_VAR="my 2nd env var value"
事件模拟
事件是工作流的基本组成部分。工作流将由于 GitHub 中发生的某些特定事件（例如推送、创建拉取请求等）而启动。使用 ，可以模拟此类事件以触发工作流。可以将事件作为参数提供。act
壳
1
$ act pull_request
事件通常比简单的字符串更复杂，因此，如果要具体化，可以提供对事件有效负载的引用：
1
$ act --eventpath pull_request.json
2
{
3
"pull_request": {
4
"head": {
5
"ref": "sample-head-ref"
6
},
7
"base": {
8
"ref": "sample-base-ref"
9
}
10
}
11
}
通过从命令行提供事件，可以测试不同的方案并观察工作流如何响应这些事件。
壳
1
$ brew install act
在本地运行工作流
act使您能够在本地执行和调试 GitHub 操作工作流，从而在开发过程中提供更快的反馈循环。运行命令行将选取文件夹中的工作流并尝试执行它们。使用可以像以下那样简单：act.github/workflowsact
壳
1
$ act
act使用 Docker 创建与 GitHub Actions 执行环境非常相似的隔离环境。这确保了操作和工作流执行的一致性。如果您没有安装 Docker，则可以使用 Docker Desktop 或使用 Colima，这是一种在 macOS 上运行容器运行时的简单方法。
选手
定义工作流时，您可以在执行步骤时根据特定的虚拟机/环境指定运行器。
亚姆
1
jobs:
2
Build:
3
runs-on: ubuntu-latest
4
steps:
5
...
默认情况下， 在指定运行器时具有到特定 Docker 映像的映射。首次运行时，它会要求您为 .您可以从 3 种可映射到的基础映像类型中进行选择：actubuntu-latestactubuntu-latestubuntu-latest
最新的DZone参考卡
GitOps for Kubernetes
微码头工人镜像（节点：16-破坏者-苗条)
Medium Docker Image （catthehacker/ubuntu：act-latest)
大型 Docker Image （catthehacker/ubuntu：full-latest）
如果您对您选择的那个不满意，请不要担心。您始终可以通过更改用户主目录中的以下文件来更改默认选择。~/.actrc
大型 Docker 映像约为 18GB！！因此，我最初选择了中型映像，因为它应该包含大多数常用的系统依赖项。我很快就知道它包含相当多的库，但是当我尝试运行基于 Java + Maven 的项目时，我了解到它不包含 Apache Maven，而 GitHub 上的普通 Ubuntu-latest 确实包含它。
[CI/Build] Run Main Build
[CI/Build] docker exec cmd=[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/2] user= workdir=
| /var/run/act/workflow/2: line 2: mvn: command not found
[CI/Build] Failure - Main Build
[CI/Build] exitcode '127': command not found, please refer to https://github.com/nektos/act/issues/107 for more information
我不想切换到 18GB 的 docker 镜像来运行 Maven，所以我最终找到了 Jamez Perkins 的现有镜像。它只是获取原始行为图像并将Maven版本3.x添加到其中。您可以通过提供平台参数轻松指定使用自定义映像运行工作流。
壳
1
$ act -P ubuntu-latest=quay.io/jamezp/act-maven
使用该图像后，我的工作流运行没有任何错误。
使用多个作业/阶段
GitHub 操作工作流通常由一个或多个作业组成，这些作业将工作流的不同阶段分开。例如，您可能有一个生成、测试和部署阶段。
生成、测试和部署
通常，在生成作业中生成应用程序，并在部署作业中使用生成的项目。作业可以在不同的运行器上运行，因此在 GitHub 操作环境中，您可能会使用上传/下载工件操作，该操作将使用集中式存储在不同运行器之间共享工件。使用和共享项目时，需要具体说明需要存储项目的位置。为此，可以提供名为 的特定参数。act--artifact-server-path
壳
1
$ act -P ubuntu-latest=quay.io/jamezp/act-maven \
2
--artifact-server-path /tmp/act-artifacts
使用机密
最佳做法始终是将机密与工作流定义分开，并仅从特定机密存储中引用它们。使用 GitHub 操作时，可以将机密存储在内置的机密管理功能中。
要为操作提供密钥，您可以使用上下文访问您在存储库中创建的密钥。secrets
亚姆
1
jobs:
2
staticanalysis:
3
runs-on: ubuntu-latest
4
steps:
5
- uses: actions/checkout@v3
6
with:
7
# Disabling shallow clone is recommended for improving relevancy of reporting
8
fetch-depth: 0
9
- name: SonarQube Scan
10
uses: sonarsource/sonarqube-scan-action@master
11
env:
12
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
13
SONAR_HOST_URL: ${{ secrets.SONAR_URL }}
act没有可以指定机密的 UI，因此在测试工作流时，需要从命令行显式提供这些值或将它们存储在 .env 格式的文件中。如果只有几个密钥，则可以通过使用 -s 选项从命令行提供密钥来轻松添加它们。
壳
1
$ act -s SONAR_TOKEN=somevalue
2
$ act --secret-file my.secrets
使用环境变量
与机密类似，您有时会在工作流中使用环境变量。对于单个环境变量，您可以使用，或者如果您有一组环境变量，则可以创建一个文件，并通过提供参数从 CLI 提供对该文件的引用。--env myenv=foodotenv--env-file
壳
1
$ act --env-file my.env
该文件基于一个简单的标准文件格式，其中包含一组由新行划分的键值对。.env
纯文本
1
MY_ENV_VAR=MY_ENV_VAR_VALUE
2
MY_2ND_ENV_VAR="my 2nd env var value"
事件模拟
事件是工作流的基本组成部分。工作流将由于 GitHub 中发生的某些特定事件（例如推送、创建拉取请求等）而启动。使用 ，可以模拟此类事件以触发工作流。可以将事件作为参数提供。act
壳
1
$ act pull_request
事件通常比简单的字符串更复杂，因此，如果要具体化，可以提供对事件有效负载的引用：
1
$ act --eventpath pull_request.json
2
{
3
"pull_request": {
4
"head": {
5
"ref": "sample-head-ref"
6
},
7
"base": {
8
"ref": "sample-base-ref"
9
}
10
}
11
}
通过从命令行提供事件，可以测试不同的方案并观察工作流如何响应这些事件。