常见问题

此页面包含一些关于 Gitea Actions 的常见问题和解答。

是否可以默认情况下为我自己的实例禁用新仓库的 Actions？

是的，当您为实例启用 Actions 时，可以选择默认情况下为所有新仓库启用 actions 组件。

[repository]
; remove repo.actions will not enable actions for newly created repositories.
DEFAULT_REPO_UNITS = ...,repo.actions

在工作流文件中，我们应该使用 ${{ github.xyz }} 还是 ${{ gitea.xyz }}？

您可以使用 github.xyz，Gitea 可以正常工作。如前所述，Gitea Actions 旨在与 GitHub Actions 兼容。但是，我们建议您使用 gitea.xyz，以防 Gitea 添加了 GitHub 没有的功能，从而避免在您的工作流文件中出现不同类型的密钥（并且因为您在 Gitea 上使用此工作流，而不是在 GitHub 上）。不过，这完全是可选的，因为这两个选项目前具有相同的效果。

当使用诸如 actions/checkout@v4 之类的 actions 时，runner 将从哪里下载脚本？

GitHub 上有数万个 actions 脚本，当您编写 uses: actions/checkout@v4 时，它默认情况下会从 github.com/actions/checkout 下载脚本。但是，如果您想从其他地方（例如 gitea.com）而不是 GitHub 使用 actions 该怎么办？

好消息是您可以指定 URL 前缀以从任何地方使用 actions。这是 Gitea Actions 中的一种额外语法。例如

• uses: https://gitea.com/xxx/xxx@xxx
• uses: https://github.com/xxx/xxx@xxx
• uses: http://your_gitea_instance.com/xxx@xxx

请注意，https:// 或 http:// 前缀是必需的！

这是与 GitHub Actions 的区别之一，GitHub Actions 仅支持来自 GitHub 的 actions 脚本。但这应该允许用户在运行 Actions 的方式上拥有更大的灵活性。

或者，如果您希望您的 runner 默认情况下从您自己的 Gitea 实例下载 actions，您可以通过设置 [actions].DEFAULT_ACTIONS_URL 来配置它。请参阅 配置速查表。

如何限制 runner 的权限？

Runner 除了连接到您的 Gitea 实例之外没有其他权限。当任何 runner 接收到要运行的作业时，它将暂时获得与该作业关联的仓库的有限权限。如果您想授予 runner 更多权限，使其能够访问更多私有仓库或外部系统，您可以将 密钥 传递给它。

对 Actions 进行细化的权限控制是一项复杂的工作。将来，我们将向 Gitea 添加更多选项以使其更具可配置性，例如允许对仓库进行更多写入访问或对同一组织中的所有仓库进行读取访问。

如何避免被黑客攻击？

存在两种可能的攻击类型：未知 runner 窃取您仓库中的代码或密钥，或者恶意脚本控制您的 runner。

避免前者意味着不允许您不认识的人为您的仓库、组织或实例注册 runner。

后者稍微复杂一些。如果您正在为您的公司使用私有 Gitea 实例，则可能无需担心安全性，因为您信任您的同事并且可以追究他们的责任。

对于公共实例，情况略有不同。以下是我们在 gitea.com 上的做法

• 我们只为“gitea”组织注册 runner，因此我们的 runner 不会执行来自其他仓库的作业。
• 我们的 runner 始终在隔离的容器中运行作业。虽然可以直接在主机上执行此操作，但为了提高安全性，我们选择不这样做。
• 要为 fork 拉取请求运行 actions，需要批准。请参阅 #22803。
• 如果有人在 gitea.com 上为其仓库或组织注册了自己的 runner，我们不反对，也不会在我们的组织中使用它。但是，他们应该注意确保该 runner 未被他们不认识的其他用户使用。

act runner 支持哪些操作系统？

它在 Linux、macOS 和 Windows 上运行良好。虽然理论上支持其他操作系统，但它们需要进一步测试。

需要注意的一点是，如果您选择直接在主机上运行作业而不是在作业容器中运行，则操作系统之间的环境差异可能会导致意外故障。

例如，在大多数情况下，Windows 上没有 bash，而 act 尝试默认使用 bash 来运行脚本。因此，您需要在工作流文件中指定 powershell 作为默认 shell，请参阅 defaults.run。

defaults:
  run:
    shell: powershell

为什么要选择 GitHub Actions？为什么不选择与 GitLab CI/CD 兼容的东西？

@lunny 在 实现 actions 的问题 中解释了这一点。此外，Actions 不仅是一个 CI/CD 系统，还是一个自动化工具。

开源世界中也已经实现了大量的 市场 actions。能够重用它们令人兴奋。

如果它在多个标签上运行，例如 runs-on: [label_a, label_b] 该怎么办？

这是一个有效的语法。这意味着它应该在同时具有 label_a **和** label_b 标签的 runner 上运行，请参阅 GitHub Actions 的工作流语法。不幸的是，act runner 的工作方式并非如此。如前所述，我们将标签映射到环境

• ubuntu → ubuntu:22.04
• centos → centos:8

但我们需要将标签组映射到环境，如下所示

• [ubuntu] → ubuntu:22.04
• [with-gpu] → linux:with-gpu
• [ubuntu, with-gpu] → ubuntu:22.04_with-gpu

我们还需要重新设计任务分配给 runner 的方式。具有 ubuntu、centos 或 with-gpu 的 runner 不一定表示它可以接受具有 [centos, with-gpu] 的作业。因此，runner 应该通知 Gitea 实例它只能接受具有 [ubuntu]、[centos]、[with-gpu] 和 [ubuntu, with-gpu] 的作业。这不是一个技术问题，只是在早期设计中被忽视了。请参阅 runtime.go#L65。

目前，act runner 尝试匹配标签中的所有人并使用它找到的第一个匹配项。

runner 的代理标签和自定义标签有什么区别？

代理标签由 runner 在注册期间报告给 Gitea 实例。另一方面，自定义标签由 Gitea 管理员或组织或仓库的所有者手动添加（取决于 runner 的级别）。

然而，此处的设计需要改进，因为它目前存在一些粗糙的地方。您可以为注册的运行器添加自定义标签，例如centos，这意味着该运行器将接收带有runs-on: centos的作业。但是，运行器可能不知道为此标签使用哪个环境，导致它使用默认镜像或导致逻辑死循环。此默认值可能与用户预期不符。请参阅runtime.go#L71。

同时，如果您想更改运行器的标签，建议您重新注册您的运行器。

Gitea Actions 运行器是否会有更多实现？

虽然我们希望提供更多选项，但我们人手有限，这意味着 act 运行器将是唯一官方支持的运行器。但是，Gitea 和 act 运行器都是完全开源的，因此任何人都可以创建新的/更好的实现。我们支持您的选择，无论您如何决定。如果您分叉 act 运行器以创建您自己的版本：如果您认为您的更改也将帮助其他人，请尽可能地贡献更改。

Gitea 支持哪些工作流触发事件？

此表中列出的所有事件都是受支持的事件，并且与 GitHub 兼容。对于仅 GitHub 支持的事件，请参阅 GitHub 的文档。

触发事件	活动类型
创建	不适用
删除	不适用
分支	不适用
gollum	不适用
推送	不适用
问题	opened、edited、closed、reopened、assigned、unassigned、milestoned、demilestoned、labeled、unlabeled
问题评论	created、edited、deleted
拉取请求	opened、edited、closed、reopened、assigned、unassigned、synchronize、labeled、unlabeled
拉取请求审查	submitted、edited
拉取请求审查评论	created、edited
发布	published、edited
注册表包	发布

对于pull_request事件，在GitHub Actions中，ref为refs/pull/:prNumber/merge，它是合并提交预览的引用。但是，Gitea 没有此类引用。因此，Gitea Actions 中的ref为refs/pull/:prNumber/head，它指向拉取请求的头部，而不是合并提交的预览。