forgejo/docs/content/doc/usage/actions/faq.zh-cn.md

8.3 KiB
Raw Blame History

date title slug weight draft toc menu
2023-05-24T15:00:00+08:00 Gitea Actions常见问题解答 faq 100 false false
sidebar
parent name weight identifier
actions 常见问题 100 actions-faq

Gitea Actions常见问题解答

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

目录

{{< toc >}}

为什么默认情况下不启用Actions

我们知道为整个实例和每个仓库启用Actions可能很麻烦但并不是每个人都喜欢或需要此功能。 在我们认为Gitea Actions值得被特别对待之前我们认为还需要做更多的工作来改进它。

是否可以在我的实例中默认启用新仓库的Actions

是的当您为实例启用Actions时您可以选择默认启用actions单元以适用于所有新仓库。

[repository]
DEFAULT_REPO_UNITS = ...,repo.actions

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

您可以使用github.xyzGitea将正常工作。 如前所述Gitea Actions的设计是与GitHub Actions兼容的。 然而,我们建议在工作流文件中使用gitea.xyz以防止在工作流文件中出现不同类型的密钥因为您在Gitea上使用此工作流而不是GitHub。 不过,这完全是可选的,因为目前这两个选项的效果是相同的。

是否可以为特定用户而不是组织注册Runner

目前还不可以。 从技术上讲是可以实现的,但我们需要讨论是否有必要。

使用actions/checkout@v3等Actions时Job容器会从何处下载脚本

您可能知道GitHub上有成千上万个Actions市场。 然而,当您编写uses: actions/checkout@v3时,它实际上默认从gitea.com/actions/checkout下载脚本而不是从GitHub下载。 这是github.com/actions/checkout的镜像,但无法将它们全部镜像。 这就是为什么在尝试使用尚未镜像的某些Actions时可能会遇到失败的原因。

好消息是您可以指定要从任何位置使用Actions的URL前缀。 这是Gitea Actions中的额外语法。 例如:

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

注意,https://http://前缀是必需的!

另外如果您希望您的Runner默认从GitHub或您自己的Gitea实例下载Actions可以通过设置 [actions].DEFAULT_ACTIONS_URL进行配置。 参见配置速查表

这是与GitHub Actions的一个区别但它应该允许用户以更灵活的方式运行Actions。

如何限制Runner的权限

Runner仅具有连接到您的Gitea实例的权限。 当任何Runner接收到要运行的Job时它将临时获得与Job关联的仓库的有限权限。 如果您想为Runner提供更多权限允许它访问更多私有仓库或外部系统您可以向其传递密钥

对于 Actions 的细粒度权限控制是一项复杂的工作。 在未来我们将添加更多选项以使Gitea更可配置例如允许对仓库进行更多写访问或对同一组织中的所有仓库进行读访问。

如何避免被黑客攻击?

有两种可能的攻击类型未知的Runner窃取您的仓库中的代码或密钥或恶意脚本控制您的Runner。

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

后者要复杂一些。 如果您为公司使用私有的Gitea实例您可能不需要担心安全问题因为您信任您的同事并且可以追究他们的责任。

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

  • 我们仅为 "gitea" 组织注册Runner因此我们的Runner不会执行来自其他仓库的Job。
  • 我们的Runner始终在隔离容器中运行Job。虽然可以直接在主机上进行这样的操作但出于安全考虑我们选择不这样做。
  • 对于 fork 的拉取请求需要获得批准才能运行Actions。参见#22803
  • 如果有人在gitea.com为其仓库或组织注册自己的Runner我们不会反对只是不会在我们的组织中使用它。然而他们应该注意确保该Runner不被他们不认识的其他用户使用。

act runner支持哪些操作系统

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

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

例如在大多数情况下Windows上没有可用的bash而act尝试默认使用bash运行脚本。 因此您需要在工作流文件中将默认shell指定为powershell,参考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 并不支持这种方式。 如上所述,我们将标签映射到环境:

  • ubuntuubuntu:22.04
  • centoscentos:8

但我们需要将标签组映射到环境,例如:

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

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

目前act runner尝试匹配标签中的每一个并使用找到的第一个匹配项。

代理标签和自定义标签对于Runner有什么区别

labels

代理标签是由Runner在注册过程中向Gitea实例报告的。 而自定义标签则是由Gitea的管理员或组织或仓库的所有者手动添加的取决于Runner所属的级别

然而,目前这方面的设计还有待改进,因为它目前存在一些不完善之处。 您可以向已注册的Runner添加自定义标签比如 centos这意味着该Runner将接收具有runs-on: centos的Job。 然而Runner可能不知道要使用哪个环境来执行该标签导致它使用默认镜像或导致逻辑死胡同。 这个默认值可能与用户的期望不符。 参见runtime.go#L71

与此同时如果您想更改Runner的标签我们建议您重新注册Runner。

Gitea Actions runner会有更多的实现吗

虽然我们希望提供更多的选择但由于我们有限的人力资源act runner将是唯一受支持的官方Runner。 然而无论您如何决定Gitea 和act runner都是完全开源的所以任何人都可以创建一个新的/更好的实现。 我们支持您的选择,无论您如何决定。 如果您选择分支act runner来创建自己的版本请在您认为您的更改对其他人也有帮助的情况下贡献这些更改。