管理仓库的 GitHub Actions 设置

关于仓库的 GitHub Actions 权限

默认情况下，GitHub Actions 在所有仓库和组织中均已启用。您可以选择禁用 GitHub Actions，或将其限制为组织内的 actions 和可复用工作流。如需了解更多关于 GitHub Actions 的信息，请参阅编写工作流。

您可以为仓库启用 GitHub Actions。启用后，工作流可以运行位于您仓库以及任何其他公共仓库中的 actions 和可复用工作流。您也可以完全禁用仓库的 GitHub Actions。禁用后，仓库中将不再运行任何工作流。

或者，您可以在仓库中启用 GitHub Actions，但限制工作流能够运行的 actions 和可复用工作流。

管理仓库的 GitHub Actions 权限

您可以禁用仓库的 GitHub Actions，或设置策略来配置仓库中可使用的 actions 与可复用工作流。

注意

如果您的组织有覆盖性的策略，或受企业的覆盖性策略管理，您可能无法管理这些设置。有关更多信息，请参阅组织的 GitHub Actions 禁用或限制或企业的 GitHub Actions 策略强制执行。

在 GitHub 上，导航至仓库的主页面。
在仓库名称下，点击设置。如果您看不到 “Settings” 选项卡，请选择下拉菜单，然后点击 Settings。
在左侧边栏，点击操作，然后点击通用。
在“Actions 权限”下，选择一个选项。

如果您选择 Allow OWNER，并选择 non-OWNER，actions 和 reusable workflows，则组织内的 actions 和可复用工作流被允许，并提供额外的选项以允许运行其他特定的 actions 和可复用工作流。有关更多信息，请参阅允许运行选定的 actions 和可复用工作流。

当您仅允许组织内的 actions 和可复用工作流时，策略会阻止所有由 GitHub 编写的 actions 访问。例如，actions/checkout 将不可用。

启用 Require actions to be pinned to a full-length commit SHA 后，所有使用的 actions 必须固定到完整的提交 SHA，包括组织内的 actions 和 GitHub 编写的 actions。可复用工作流仍可通过标签引用。有关详细信息，请参阅安全使用参考。
点击保存。

允许运行选定的 actions 和可复用工作流

当您选择 Allow OWNER，并选择 non-OWNER，actions 和 reusable workflows 时，允许本地的 actions 与可复用工作流，并提供额外的选项以允许运行其他特定的 actions 与可复用工作流。

注意

Allow actions created by GitHub: 您可以允许所有由 GitHub 创建的 actions 被工作流使用。这些 actions 位于 actions 与 github 组织中。详情请参阅 actions 与 github 组织。
Allow Marketplace actions by verified creators: 您可以允许所有经验证创作者在 GitHub Marketplace 上的 actions 被工作流使用。当 GitHub 验证了该 action 的创作者为合作伙伴组织时，徽章会显示在 GitHub Marketplace 中该 action 的旁边。
Allow or block specified actions and reusable workflows: 您可以限制工作流仅使用特定组织和仓库中的 actions 与可复用工作流。指定的 actions 最多可设置 1000 条。

若要限制对特定标签或提交 SHA（对应某个 action 或可复用工作流）的访问，请使用工作流中选择该 action 或可复用工作流时相同的语法。
- 对于 action，语法为 OWNER/REPOSITORY@TAG-OR-SHA。例如，使用 actions/javascript-action@v1.0.1 选择标签，或使用 actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f 选择 SHA。详情请参阅在工作流中使用预写构建块。
- 对于可复用工作流，语法为 OWNER/REPOSITORY/PATH/FILENAME@TAG-OR-SHA。例如 octo-org/another-repo/.github/workflows/workflow.yml@v1。详情请参阅复用工作流。
您可以使用 * 通配符匹配模式。例如，要允许所有以 space-org 开头的组织中的 actions 与可复用工作流，可指定 space-org*/*。要允许所有仓库名以 octocat 开头的 actions 与可复用工作流，可使用 */octocat**@*。有关使用 * 通配符的更多信息，请参阅 GitHub Actions 的工作流语法。

使用 , 分隔不同的模式。例如，若要同时允许 octocat 与 octokit 组织中的所有 actions 与可复用工作流，可指定 octocat/*, octokit/*。

使用 ! 前缀来阻止模式。例如，若要允许 space-org 组织中的所有 actions 与可复用工作流，但阻止特定的 space-org/action，可指定 space-org/*, !space-org/action@*。默认情况下，仅列表中指定的 actions 与可复用工作流被允许。若要在允许全部的同时阻止特定 actions，可使用 *, !space-org/action@*。

本步骤演示如何将特定的 actions 与可复用工作流添加到列表中。

在 GitHub 上，导航至仓库的主页面。
在仓库名称下，点击设置。如果您看不到 “Settings” 选项卡，请选择下拉菜单，然后点击 Settings。
在左侧边栏，点击操作，然后点击通用。
在 “Actions 权限” 下，选择 Allow OWNER，并选择 non-OWNER，actions 和 reusable workflows，然后将您需要的 actions 添加到列表中。
点击保存。

控制公共仓库中 forks 对工作流的更改

任何人都可以 fork 公共仓库，然后提交提议更改仓库 GitHub Actions 工作流的拉取请求。虽然来自 forks 的工作流无法访问敏感数据（如 secrets），但如果被用于恶意目的，仍会给维护者带来困扰。

为防止此类情况，来自某些外部贡献者的公共仓库的拉取请求中的工作流不会自动运行，可能需要先获得批准。根据 “Approval for running fork pull request workflows from contributors” 设置，公共仓库的拉取请求工作流在以下情况下不会自动运行并可能需要批准：

拉取请求是由 创建的用户 根据所选策略需要批准。
拉取请求事件是由 触发的用户 根据所选策略需要批准。

默认情况下，所有首次贡献者都需要批准才能运行工作流。

由 pull_request_target 事件触发的工作流在基分支的上下文中运行。由于基分支被视为受信任，使用此事件触发的工作流始终会运行，不受批准设置影响。有关 pull_request_target 事件的更多信息，请参阅触发工作流的事件。

警告

这些工作流批准策略旨在限制能够在 GitHub 托管的运行器上执行工作流的用户集合，以防止意外的资源与计算消耗。如果您使用自托管运行器，恶意的用户控制代码将在用户能够在批准策略中绕过批准或拉取请求已获批准时自动执行。您必须考虑在自身基础设施中运行此类代码的风险，并且无论采用何种批准设置，都应审阅并遵循自托管运行器的安全建议。参阅安全使用参考。

您可以使用下面的步骤为仓库配置此行为。修改此设置会覆盖组织或企业层面的配置。

在 GitHub 上，导航至仓库的主页面。
在仓库名称下，点击设置。如果您看不到 “Settings” 选项卡，请选择下拉菜单，然后点击 Settings。
在左侧边栏，点击操作，然后点击通用。
在 Approval for running fork pull request workflows from contributors 下，选择需要在其拉取请求运行工作流前获得批准的用户子集。系统会检查拉取请求作者和触发工作流的拉取请求事件的执行者，以判断是否需要批准。如果需要批准，拥有仓库写权限的用户必须批准该拉取请求工作流才能运行。参阅批准来自 forks 的工作流运行。

警告

当仅对首次贡献者（前两个设置）要求批准时，曾有任何提交或拉取请求合并到仓库的用户将不再需要批准。恶意用户可通过让维护者接受其一次拼写错误或其他无害的修改来满足此条件，无论是其自己提交的拉取请求还是他人提交的拉取请求。
- Require approval for first-time contributors who are new to GitHub。仅对在 GitHub 上全新且从未有任何提交或拉取请求合并到此仓库的用户要求批准。
- Require approval for first-time contributors。仅对从未在此仓库有任何提交或拉取请求合并的用户要求批准。
- Require approval for all external contributors。所有不是此仓库成员或所有者且也不是组织成员的用户，都需要批准才能运行工作流。
点击保存以应用设置。

有关此策略适用的工作流运行批准的更多信息，请参阅批准来自 forks 的工作流运行。

为私有仓库的 forks 启用工作流

如果您依赖于私有仓库的 forks，可配置政策来控制用户如何在 pull_request 事件上运行工作流。此功能仅对私有仓库可用，您可以为组织或仓库配置这些政策设置。

如果组织已禁用该政策，则无法在仓库层面启用。

Run workflows from fork pull requests - 允许用户在 fork 的拉取请求中运行工作流，使用仅具只读权限的 GITHUB_TOKEN，且不可访问 secrets。
Send write tokens to workflows from pull requests - 允许来自 forks 的拉取请求使用具写权限的 GITHUB_TOKEN。
Send secrets to workflows from pull requests - 将所有 secrets 公开给该拉取请求。
Require approval for fork pull request workflows - 来自没有写权限的协作者的 fork 拉取请求工作流在执行前需要拥有写权限的人员批准。

为私有仓库配置 fork 政策

在 GitHub 上，导航至仓库的主页面。
在仓库名称下，点击设置。如果您看不到 “Settings” 选项卡，请选择下拉菜单，然后点击 Settings。
在左侧边栏，点击操作，然后点击通用。
在 Fork pull request workflows 下，选择您的选项。
点击保存以应用设置。

设置仓库的 `GITHUB_TOKEN` 权限

您可以设置 GITHUB_TOKEN 的默认权限。有关 GITHUB_TOKEN 的更多信息，请参阅在工作流中使用 GITHUB_TOKEN 进行身份验证。您可以将默认权限设为受限集合，或使用更宽松的设置。

默认权限也可以在组织设置中配置。如果您的仓库属于组织，且组织已选择更严格的默认权限，则您在仓库设置中只能看到相同的受限选项，宽松选项将被禁用。

拥有写权限的任何人都可以通过编辑工作流文件中的 permissions 键来修改 GITHUB_TOKEN 的权限，按需添加或移除访问权限。详情请参阅 permissions。

配置默认 `GITHUB_TOKEN` 权限

默认情况下，在个人账户中创建的新仓库，GITHUB_TOKEN 仅对 contents 与 packages 范围具有读取权限。如果在组织中创建新仓库，则继承组织设置中的配置。

在 GitHub 上，导航至仓库的主页面。
在仓库名称下，点击设置。如果您看不到 “Settings” 选项卡，请选择下拉菜单，然后点击 Settings。
在左侧边栏，点击操作，然后点击通用。
在 “Workflow permissions” 下，选择是让 GITHUB_TOKEN 拥有所有权限的读写访问（宽松设置），还是仅对 contents 与 packages 具备只读访问（受限设置）。
点击保存以应用设置。

防止 GitHub Actions 创建或批准拉取请求

您可以选择允许或阻止 GitHub Actions 工作流创建或批准拉取请求。

默认情况下，在个人账户中新建仓库时，工作流不被允许创建或批准拉取请求。如果在组织中创建新仓库，则继承组织设置的配置。

在 GitHub 上，导航至仓库的主页面。
在仓库名称下，点击设置。如果您看不到 “Settings” 选项卡，请选择下拉菜单，然后点击 Settings。
在左侧边栏，点击操作，然后点击通用。
在 “Workflow permissions” 中，使用 Allow GitHub Actions to create and approve pull requests 设置来决定 GITHUB_TOKEN 是否可以创建和批准拉取请求。
点击保存以应用设置。

允许访问私有仓库中的组件

私人仓库中的 actions 与可复用工作流可以与同一用户或组织拥有的其他私有仓库共享。有关私有仓库的更多信息，请参阅仓库概述。

您可以使用以下步骤配置是否允许外部访问私有仓库中的 actions 与可复用工作流。更多信息，请参阅从私有仓库共享 actions 与工作流与与组织共享 actions 与工作流。此外，您也可以使用 REST API 设置或获取访问级别的详细信息，参考获取仓库外工作流访问级别的 REST API 与设置仓库外工作流访问级别的 REST API。

管理私有仓库的访问权限

在 GitHub 上，导航至私有仓库的主页。
在仓库名称下，点击设置。
在左侧边栏，点击操作，然后点击通用。
在 Access 下，选择一种访问设置。
- Not accessible - 其他仓库的工作流无法访问此仓库。
- Accessible from repositories owned by 'USER NAME' user - 与同一用户拥有的其他仓库（仅限私有仓库）的工作流可以访问此仓库中的 actions 与可复用工作流。
点击保存以应用设置。

在组织中管理私有仓库的访问

在 GitHub 上，导航至私有仓库的主页。
在仓库名称下，点击设置。
在左侧边栏，点击操作，然后点击通用。
在 Access 下，选择一种访问设置。
- Not accessible - 其他仓库的工作流无法访问此仓库。
- Accessible from repositories in the 'ORGANIZATION NAME' organization - 属于该组织的其他私有仓库的工作流可以访问此仓库中的 actions 与可复用工作流。
点击保存以应用设置。

配置仓库的缓存设置

您可以为仓库配置缓存保留和大小设置。此功能为可选，并仅对已提供付款方式、GitHub Pro、GitHub Team 或 GitHub Enterprise Cloud 计划的用户开放。

如果您的仓库所属的组织已配置缓存设置，您可以将限制配置至组织设定的最大值；如果是个人拥有的仓库，则可以配置至全局最大值。

在 GitHub 上，导航至仓库的主页面。
在仓库名称下，点击设置。如果您看不到 “Settings” 选项卡，请选择下拉菜单，然后点击 Settings。
在左侧边栏，点击操作，然后点击通用。
在 “Cache settings” 部分，配置以下设置：
- Cache retention：缓存在自动删除前保留的天数，默认 7 天。公开仓库可配置至 90 天，私有或内部仓库可配置至 365 天（或截至组织设定的上限）。
- Cache size eviction limit：仓库中全部缓存的最大总大小，默认 10 GB。每个仓库最高可配置至 10,000 GB（或截至组织设定的上限）。当超过此上限时，较旧的缓存将被驱逐以腾出空间。
点击保存以应用设置。

有关缓存驱逐的更多信息，请参阅依赖缓存参考。

配置仓库中 GitHub Actions 构件和日志的保留期限

您可以为仓库中的 GitHub Actions 构件和日志设置保留期限。

默认情况下，工作流生成的构件和日志文件会保留 90 天，然后自动删除。您可以根据仓库类型调整保留期限。

对于公开仓库：保留期限可在 1 天至 90 天之间进行更改。
对于私有仓库：保留期限可在 1 天至 400 天之间进行更改。

自定义保留期限仅适用于新生成的构件和日志文件，不会追溯已存在的对象。受管理的仓库和组织的最大保留期限不得超过管理组织或企业设定的上限。

您还可以为工作流创建的特定构件定义自定义保留期限。详情请参阅移除工作流构件。

为仓库设置构件和日志的保留期限

在 GitHub 上，导航至仓库的主页面。
在仓库名称下，点击设置。如果您看不到 “Settings” 选项卡，请选择下拉菜单，然后点击 Settings。
在左侧边栏，点击操作，然后点击通用。
在 Artifact and log retention 下，输入新的数值。
点击 Save 以应用更改。

本文内容