壳
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. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。