如何限制 GitLab CI/CD Runner 只在特定分支运行，并锁定 .gitlab-ci.yml 防止修改？

Question

现在，任何人只要在我的项目中创建一个分支并添加.gitlab-ci.yml文件，就可以使用runner在我的服务器上执行命令。我该如何做才能让只有主人或所有者可以上传CI配置文件并对其进行更改？

我正在使用运行在bash上的https://gitlab.com/gitlab-org/gitlab-ci-multi-runner。

- CausingUnderflowsEverywhere

---

这个功能请求听起来非常合理。特别是现在gitlab-ci支持部署。您考虑过在这里提出吗？ - Matthew

Answer 1

GitLab Runner并非专为此场景设计，因此您无法这样做。相反，您可以创建一个新项目，只包含您的.gitlab-ci.yml文件，并配置它以拉取原始存储库。从那里，您可以使用存储库执行所有其他操作。

- Fairy

---

抱歉，我不明白这是如何工作的。你能解释一下吗？（将推送到项目A = 做什么的CI）就像我的CI文件所做的那样，新项目是做什么的？ - CausingUnderflowsEverywhere

@CausingUnderflowsEverywhere 你有两个仓库。仓库A是原始仓库，没有启用任何runner和CI文件。仓库B是你的“Runner仓库”，在那里你只有CI文件。在那个文件中，你git pull仓库A并做所有其他想做的事情。这样，你就能锁定CI文件，同时拥有所有权利。真正实现这一点的方法没有其他途径。 - Fairy

嗯，每次我想运行CI时都需要手动推送，这完全不是自动化的，所以它毫无用处。谢谢你的提示。如果我是独自工作，那么这将是一个很好的选择，但事实是，正如我在问题中所述，我正在与其他人合作。对于我来说，监视某人是否将某些内容推送到repo A以便我将其推送到repo B以激活CI是不可行的，因为这将不会显示在repo A的合并请求中。我可以使用Webhooks等，但那样我甚至不会使用你的解决方法，而是将CI放在由Webhook激活的某些代码中。 - CausingUnderflowsEverywhere

这在仓库端是自动化的，当然；它不会神奇地响应本地提交。这不好吗？推送是“如此cvs”，但它是一个可靠的触发器和门卫，用于更频繁地成为昂贵测试装置的东西。 - user2066657

Answer 2

Gitlab现在支持将.gitlab-ci.yml文件移动到存储库之外的其他位置。只有具有管理员存储库访问权限的人才能更改此设置，这使得对于存储库的大多数用户来说，只读管道是理想的选择。

- KMZ