我的问题有点复杂，所以我尝试准确地描述它：
我们在 GitLab 项目 A 中有一个 ci 模板，它包含在项目 B 中。只要我是管道的触发者，它就可以正常工作。但是当触发者是项目 B 的 token 用户（我们创建的）时，就会出现 invalid yaml 错误。
给你一些观点：
如果您提交到 B 的 master 分支，自动合并作业应该将 master 合并到开发中。这会触发一个新的开发管道，它会做自己的事情。不幸的是，开发上的新管道失败了，因为令牌是触发器，并且它无法访问模板。
我们的版本控制工作也会发生类似的情况。该作业进行提交并使用新版本号进行标记，这会触发管道，该管道会因相同的错误而失败。奇怪的是，我们正在使用工作流规则过滤此提交，因此它一开始就不应该触发管道，但它确实触发了管道并且失败了。
另一方面：
如果我在项目 B 的 yml 中声明 ci 逻辑（即不包括模板），工作流过滤器就会工作，版本控制提交不会触发管道，自动合并会在开发时触发管道，并且运行完美。
我的想法是，当项目 B 的令牌触发某些内容时，它会查看 yml 文件，该文件的第一行包含包含内容，并且由于它无法访问项目 A，因此它会立即失败。我们的目标是在其他项目中使用项目 A 的模板。无需向其他每个项目自己的代币用户授予权限，这应该是可能的，对吗？
提前致谢，
大卫
我们的目标是在其他项目中使用项目 A 的模板。无需向其他每个项目自己的代币用户授予权限，这应该是可能的，对吗？
嗯 - 文件导入和类似的事情是在每个用户级别上处理的（PAT 也作为个人用户处理）。因此，如果 ProjectB 中的触发者是无权访问 ProjectA 的用户，则无法导入 CI 定义，并且会失败。
TL：博士；您需要确保： a) 项目A是公开的 b) Triggerer 可以显式访问 ProjectA
我建议您为 CI 模板创建一个可公开访问的存储库，通过使用环境变量传递 all 值来概括它们（这样您就可以向“公共视图”公开尽可能少的信息），然后将这些模板导入到不同的项目。
2024-05-15更新
Gitlab 现在有 CI 组件。它们非常好，因为您可以提供“值”，然后将其模板化到 CI 模式中，而无需使用环境变量（如果您不注意，这可能会导致冲突问题。
它们比仅仅从另一个存储库导入文件要复杂一些，因为您需要将它们实际发布到组件注册表，进行版本控制等......但我认为这是值得的，特别是因为它有点“强制”您采用版本控制（这始终是一个优点）。
旧
如果您自行托管一个私有但可公开访问的 GitLab 实例（只有员工有帐户，但可以通过互联网访问），您可以创建一个“内部”存储库，而不是“公共”存储库。
这将使任何登录的人（包括 PAT）都可以访问存储库，而其他人则无法访问（因此无法公开访问）。