gitlab ci 不支持直接按用户名或邮箱限制触发权限，但可通过角色控制、分支保护、触发器隔离和 rules 条件规则组合实现精准限制：设置流水线变量最低角色为 maintainer/owner；保护 main 分支并限定部署 job 仅在该分支运行；使用专用触发器项目代理高权限操作；或用 rules 结合 $gitlab_user_email 动态判断提交人。
GitLab CI 本身不提供“按具体用户名或邮箱限制触发权限”的直接开关，但可以通过角色控制、分支保护、触发器隔离和条件规则组合实现精准限制。核心思路是：**不让非授权人具备触发流水线的权限路径**。
用项目角色 + 流水线变量最低权限控制
这是最直接、官方支持的方式，适用于希望按角色分级管控的场景：
- 进入项目 → 设置 → CI/CD → 变量 → 展开“流水线变量最低角色”
- 选择 maintainer（维护者）或 owner（所有者）——这样开发者角色用户即使手动运行流水线，也无法传入自定义变量（如
DEPLOY_ENV=prod），从而阻断关键操作 - 注意：该设置不影响预定义变量（如
CI_COMMIT_BRANCH），也不影响已配置的定时流水线或推送自动触发，只约束“带变量的手动触发”和 API 触发时的变量覆盖能力
用受保护分支 + only/except 精确匹配触发源
把高权限操作绑定到特定分支，并严格保护该分支：
- 将部署类 job 写在
.gitlab-ci.yml中，用only: [main]或rules:明确限定仅在main分支运行 - 在项目设置 → 仓库 → 受保护分支中，将
main设为“仅 Maintainer 可合并/推送” - 这样，普通开发者无法向
main推送代码，也就无法通过推送触发部署流水线；而维护者推送后自动触发，无需额外操作
用专用触发器项目做权限代理
适合需要更细粒度（比如只允许张三触发生产部署）或跨项目统一管控的场景：
- 新建一个空项目（如
ci-trigger-prod），仅授予指定人员（如运维组）Maintainer 权限 - 在该项目中配置流水线触发器（设置 → CI/CD → 流水线触发器），获取专属 token
- 在目标项目的
.gitlab-ci.yml中，用trigger:调用该触发器，并配合rules判断$CI_TRIGGERED_BY或$CI_PIPELINE_SOURCE - 实际触发动作由权限受限的“触发器项目”完成，主项目只需响应合法调用，不暴露任何直接触发入口
用 rules 结合预定义变量动态判断提交人
适用于需根据 Git 提交者身份差异化执行的轻量级控制：
- 在 job 的
rules中引用$CI_COMMIT_AUTHOR_EMAIL或$GITLAB_USER_EMAIL - 例如：
- if: '$GITLAB_USER_EMAIL == "ops@company.com"'，只允许该邮箱用户触发该 job - 注意：
$GITLAB_USER_EMAIL仅在 Web UI 手动运行、MR 合并、API 触发等上下文中可用；推送触发时不可用，需搭配其他机制
