内部允许的 API

internal/allowed 端点评估用户是否有权限对 Git 仓库执行某些操作。它会执行多项检查，例如：

• 确保分支或标签名称是可接受的。
• 用户是否有执行该操作的权限。

端点定义

内部 API 端点定义在 lib/api/internal， 而 /allowed 路径位于 lib/api/internal/base.rb。

使用端点

当你执行以下操作时，会调用 internal/allowed：

• 推送到仓库。
• 通过 GitLab 用户界面对仓库执行操作，例如 应用建议或使用 GitLab IDE。

通常由 Gitaly 调用此端点。它仅被应用程序内部（其他部分）调用，而不是被 API 的外部用户调用。

推送检查

internal/allowed 流程的关键部分是对 EE::Gitlab::Checks::PushRuleCheck 的调用，它可以执行以下检查：

• EE::Gitlab::Checks::PushRules::CommitCheck
• EE::Gitlab::Checks::PushRules::TagCheck
• EE::Gitlab::Checks::PushRules::BranchCheck

递归调用

internal/allowed 调用的一些 Gitaly RPC 接着自身也会调用回 internal/allowed。这些调用现在与原始请求相关联。 Gitaly 依赖 Rails 应用程序进行授权，并且自身不维护权限模型。

这些调用在日志中的显示方式与初始请求不同。{example}

由于此端点可以被递归调用，此端点的性能缓慢可能导致指数级的性能影响。本文档实际上改编自 对其性能的调查。

已知的性能问题

Refs

Git 仓库中 refs 的数量 对在其上调用的 git 命令性能有显著影响。Gitaly RPC 也受到类似影响。某些 git 命令会扫描所有 refs， 对这些命令的速度造成显著影响。

在 internal/allowed 端点上，RPC 调用的递归性质意味着 ref 计数对性能有指数级影响。

环境 refs

过期的环境 refs 是 refs 过多导致性能问题的常见例子。在繁忙的仓库中，过期的环境 refs 可能达到数万个， 因为它们不会被自动清理。

悬空 refs

悬空 refs 的创建是为了防止对象池中的对象被意外删除。 大量这些 refs 的存在可能具有潜在的性能影响。 关于此问题的现有讨论，请参阅 gitaly#1900。此问题 似乎比过期的环境 refs 影响较小。

池化仓库

在 GitLab 上创建 fork 时，会创建一个中央池化仓库，并将 fork 与其链接。 这个池化仓库通过存储与其他 fork 共通的数据来防止数据重复。 然而，池化仓库的清理方式与标准仓库不同，更容易受到 refs 问题的影响。

功能标志

并行推送检查

这个实验性功能标志使端点能够同时运行多个 RPC， 将总体时间减少约一半。这种时间节省是通过线程实现的， 在大规模使用时可能有潜在的副作用。在 GitLab.com 上，此功能标志 仅对 gitlab-org/gitlab 和 gitlab-com/www-gitlab-com 项目启用。 没有它，这些项目通常会超时请求到此端点。当此功能 部署到整个 GitLab.com 时，一些推送失败，可能是由于耗尽了 数据库连接池等资源。

只有在遇到超时时才应启用此功能标志， 并且仅针对特定项目启用。