我的问题有点复杂，所以我试着准确地描述它:
我们在GitLab项目a中有一个ci模板，它包含在项目b中。只要我是管道的触发器，它就可以正常工作。但是当触发器是项目B的令牌用户(由我们创建)时，会出现无效的yaml错误。
给你一些视角:
如果你向B的主分支提交，自动合并的任务应该将master合并到develop中。这就触发了一个新的开发管道，它可以做自己的事情。不幸的是，开发上的新管道失败了，因为令牌是触发器，它无法访问模板。
类似的事情也发生在我们的版本控制任务中。作业进行一个提交和一个带有新版本号的标记，这会触发一个管道，该管道失败并出现相同的错误。奇怪的是，我们用工作流规则过滤了这个提交，所以它一开始不应该触发一个管道，但是它触发了并且失败了。
另一方面
如果我在项目B的yml中声明ci逻辑(即不包括模板)，工作流过滤器工作，版本控制提交不会触发管道，自动合并在开发中触发管道，并且它运行完美。
我想到的是，当项目B的令牌触发某些东西时，它会查看yml文件，该文件在第一行中包含，并且由于它无法访问项目A，因此它立即失败。我们的目标是在其他项目中使用项目A的模板。不给其他项目自己的令牌用户授予权限应该是可能的，对吧?
提前感谢，
大卫
我们的目标是在其他项目中使用项目A的模板。不给其他项目自己的令牌用户授予权限应该是可能的，对吧?
文件导入和类似的东西是在每个用户级别上处理的(PAT也作为个人用户处理)。因此，如果ProjectB中的触发器是一个没有访问ProjectA权限的用户，那么CI定义就不能被导入，并且它会失败。
TL:博士;你需要确保:a)项目a是公开的b)触发器对ProjectA有显式访问
我建议您为CI模板创建一个可公开访问的存储库，通过传递all来泛化它们值使用环境变量(以便您向"公共视图"暴露尽可能少的信息);)，然后在不同的项目中导入这些模板。
如果您是自托管私有的，但可公开访问的GitLab实例(只有员工有帐户，但可从互联网访问)，您可以创建一个"内部"。存储库而不是"public"一。
这将使任何登录的人都可以访问存储库(包括PAT)，而不是其他人(因此没有公共访问)。