赋能如何在整个企业中发挥作用
Code Quality 在三个层级进行控制，因此，您可以决定赋予组织和存储库多大的自主权：
- 企业： 企业所有者必须先为企业启用 Code Quality。 在这样做之前，组织所有者无法启用它。
- 组织： 组织所有者通过授予对所有存储库、所选列表或与筛选器匹配的存储库的访问权限来控制哪些存储库已启用 Code Quality 或禁用。 它们还可以强制实施这些设置，以便存储库管理员无法更改这些设置。
- 存储库： 除非组织级别强制实施，否则存储库管理员可以为单个存储库启用或禁用 Code Quality 存储库。
在存储库中启用 Code Quality 后，CodeQL 分析将通过 GitHub Actions 运行，并在拉取请求和默认分支中显示发现结果。 开发人员可以查看其拉取请求中的质量检查和批注。
组织级存储库访问权限
在组织级别，你可以通过单个Code Quality设置来控制****。 此设置确定已启用哪些存储库，以及哪些存储库已 Code Quality 禁用：启用所选内容中的存储库，并且禁用所选内容之外的存储库。
重要
更改 存储库访问 设置可以同时在多个存储库中启用 和 禁用 Code Quality 。 例如，如果启用 Code Quality 与筛选器匹配的存储库，则禁用与筛选器不匹配的任何存储库。 在应用更改之前，对话框会显示已启用和禁用的存储库总数以及计费影响。
存储库访问选项
每次只能应用以下选项中的一项。
| 选项 | 行为 |
|---|---|
| 无存储库 | |
| Code Quality禁用组织中所有当前和将来的存储库。 | |
| 让存储库决定 | 组织既不能启用或禁用 Code Quality。 存储库管理员选择是否为其自己的存储库启用它。 无法强制执行此选项。 |
| 所有存储库 | 为所有当前和将来的存储库启用 Code Quality 。 |
| 所选存储库 | 为你选择的特定存储库列表启用 Code Quality。 未选择的存储库处于禁用状态，并且不会自动启用新存储库。 最适用于试点或例外情况。 |
| 匹配筛选器 | 为符合你定义的筛选条件的存储库启用 Code Quality，当前及未来均适用。 禁用不匹配的存储库。 请参阅 筛选存储库。 |
筛选存储库
选择 “匹配筛选器”时，会创建一个动态筛选器，该筛选器会自动 Code Quality 启用与条件匹配的现有和将来的存储库。 这对于大规模持续治理非常有用。
可以筛选以下条件的任意组合：
- 可见性： 存储库是公开、私有还是内部。 适用于广泛的策略，例如为所有专用存储库启用 Code Quality 。
- 分叉状态： 存储库是否为分支。 在不希望分叉占用分析资源时，这会很有用。
- 自定义属性： 存储库是否具有特定的自定义属性值。 例如，可以将具有属性的
team:platform存储库作为目标。
筛选器中的所有条件都结合在一起 AND，因此存储库必须与要启用的每个条件匹配。 还可以排除与特定条件匹配的存储库。
强制执行访问控制
默认情况下，存储库管理员可以更改 Code Quality 其自己的存储库的设置。 若要防止出现这种情况，请启用 “强制实施访问”。
强制执行会锁定由您的 存储库访问 选项设定的启用和禁用状态，因此存储库管理员无法覆盖这些设置。 这样可以提高整个组织的一致性，但可降低单个存储库管理员的灵活性。
- 强制措施适用于你选择的大多数 存储库访问 选项，包括 “无存储库”（强制 Code Quality 禁用）。
- 使用 由存储库自行决定 时，无法进行强制实施，因为该选项本就有意将选择权留给存储库管理员。
规划部署
由于单个 存储库访问 设置更改可以一次跨多个存储库启用 Code Quality ，并且每个分析都会占用 GitHub Actions 几分钟时间，因此需要分阶段而不是一次性推出。 规划时，权衡一些事项：
- 成本和容量。 在广泛启用GitHub Actions之前，请确认你的运行器能够承受额外的Code Quality负载。
- 强制执行程度。 强制执行可确保覆盖范围一致，并阻止仓库管理员选择退出，但这也会使他们失去灵活性。 离开它后，团队可以选择在其自己的时间线上加入。
- 何时展开。 从一个具有代表性的小型试点组开始，确认分析运行顺利，开发人员信任调查结果，然后扩大选择或筛选器以涵盖更多存储库。
有关分步推出过程，包括在强制实施之前在评估模式下试点质量阈值，请参阅 大规模部署GitHub Code Quality。