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
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?
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).