gitlab- ci/cd模板访问问题与令牌
我的问题有些复杂，因此我尝试精确地描述它：
我们在Gitlab项目A中有一个CI模板，该模板包括Project B中。只要我是触发器，它的工作正常管道。但是，当触发程序是项目B的令牌用户（由我们创建）时，就会出现无效的YAML错误。
可以给您一些视角：
如果您对B的主分支提交，则自动化工作应将主工作合并为发展。这触发了有关开发的新管道，该管道做自己的事情。不幸的是，有关开发的新管道失败了，因为令牌是触发器，并且无法访问模板。
我们的版本效力也发生了类似的事情。该作业制作了一个提交和带有新版本号的标签，该编号触发了管道，该管道失败了。奇怪的是，我们正在用工作流规则过滤此提交，因此首先不应该触发管道，但是它确实和失败了。
另一方面，：
如果我在项目B的YML中声明CI逻辑（即不包括模板），则工作流过滤器的作品，而版本管理提交不会触发管道，则汽车确实触发了一个在开发上，它运行完美。
我想到的是，当项目B的令牌触发某些内容时，它可以通过YML文件（其中包含在第一行）中进行查看，并且由于它无法访问Project A，因此立即失败。我们的目标是在其他项目中使用项目A的模板。如果没有给其他每个项目的代币用户，就应该有可能在不给其他所有项目的许可方面，对吗？
预先感谢
大卫
My problem is a little complicated, so I try to describe it precisely:
We have a ci template in GitLab Project A, which is included in Project B. It works fine, as long as I am the triggerer of a pipeline. But when the triggerer is project B's token user (created by us), there is an invalid yaml error.
To give you some perspective:
If you make a commit to B's master branch, the automerging job should merge master into develop. This triggers a new pipeline on develop, which does its own things. Unfortunately, the new pipeline on develop fails, because the token was the triggerer, and it hasn't got access to the template.
Similar thing happens with our versioning job. The job makes a commit and a tag with the new version number, which triggers a pipeline, which fails with the same error. Weird thing is that we are filtering this commit out with workflow rules, so it shouldn't trigger a pipeline in the first place, but it does and fails.
On the other hand:
If I declare the ci logic in Project B's yml (i.e. not including the template), the workflow filter works, the versioning commit doesn't trigger a pipeline, the automerge does trigger one on develop and it runs perfectly.
What I have on my mind is that when Project B's token triggers something, it looks through the yml file, which has the including in the first lines, and since it doesn't have access to project A, it fails immediately. Our goal is to use Project A's template in other projects. It should be possible without giving permissions to every other project's own token user, right?
Thanks in advance,
David
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧 - 文件导入以及类似的内容在每个用户级别上处理（PAT也作为单个用户处理）。因此，如果ProjectB中的触发器是无法访问ProjectA的用户，则无法导入CI定义，并且失败。
TL：DR；您需要确保：
a）Projecta是公开的
b）触发器可以明确访问Projecta，
我建议您仅针对CI模板创建一个可公开访问的存储库，通过使用环境变量传递所有值来概括它们（因此您将其作为少量信息传播给公共信息”查看“尽可能），然后只是在不同项目中导入这些模板。
2024-05-15更新
gitlab现在 ci coce 。它们非常好，因为您可以提供“值”，然后将其模板模板不使用环境变量（如果您不关注的话，这可能会引起冲突问题。
它们比仅从另一个存储库中导入文件要复杂得多。由于您需要将它们实际发布到组件注册表，已版本版本等...但是我认为这是值得的，尤其是因为它“有点”“力量”您采用版本控制（这总是一个加号
） > Old
如果您是在自我托管的私人（公开访问gitlab实例）（只有员工有帐户，但可以从互联网上访问），则可以创建“
gitlab.com/ee/user/public_access.html#internal-projects-and-groups“ rel =“ nofollow noreferrer”>内部“储存 登录（包括PAT），没有其他人（因此没有公共访问）。
Well - file importing and stuff like that is handled on per-user level (PAT are also handled as individual users). So if the triggerer in ProjectB is a user that does not have access to ProjectA, then the CI definition can not be imported, and it fails.
TL:DR; you need to make sure that:
a) ProjectA is public
b) Triggerer has explicit access to ProjectA
I would suggest that you create a publicly-accessible repository just for CI templates, generalize them by passing all values using environment variables (so you expose as little information to "public view" as possible) and then just import those templates in different projects.
2024-05-15 update
Gitlab now has CI components. They are very nice as you can provide "values" which are then templated into your CI schema without using environment variables (which can cause clashing problems if you're not paying attention.
They are a bit more complicated than just importing files from another repo as you need to actually publish them to the components registry, have versioned releases, etc... But I think it's worth the effort, especially because it sort of "forces" you to adopt versioning (which is always a plus).
Old
If you are self-hosting a private, but publicly accessible, GitLab instance (only employees have accounts, but is reachable from the internet) you can create an "internal" repository instead of a "public" one.
This will make the repository accessible to anyone that is logged in (including PAT) and no one else (so no public access).