Hey there!
On gitlab.com, Cloud Agents authenticate git with a per-project access token (the project_..._bot user), which GitLab scopes to that single project by design. repositoryDependencies only controls which repos get cloned into the agent’s VM (each with its own per-project token for the clone); it doesn’t change the identity that pushes your branch or that your pipeline runs as. And there’s currently no way to point Cloud Agents at a group-level service account on gitlab.com, so you haven’t misconfigured anything.
The pipeline failure itself is really a GitLab platform constraint. include: project: requires the user that triggers the pipeline to be a member of the included project, and GitLab doesn’t allow a project access token bot to be added to other projects (tracked upstream at gitlab-org/gitlab#361993). So the bot-created pipeline can’t read the template in project B, even though both live in the same group.
To unblock today:
- Re-run the pipeline as yourself (a manual “Run pipeline” or an empty commit), so it resolves the
include:with your own membership. Reliable, though manual. - If you want to keep it automated, the GitLab-side option is to stop relying on the MR author’s permissions for the cross-project import. For example, fetch the shared config at job runtime using a group access/deploy token stored as a CI/CD variable, rather than a native
include: project:. Happy to dig into your specific setup if that’s useful.
One thing worth flagging: GitLab’s CI_JOB_TOKEN allowlist isn’t used for include: resolution, so allowlisting the project there won’t fix the template import specifically.
On your actual ask (letting the Cloud Agent operate as a specific service account): that’s a reasonable request, and for this exact cross-project include: case a service account is genuinely the right shape (GitLab recommends it for this too). It’s come up from other GitLab teams, and there’s an open thread discussing the team-level service account idea here: Gitlab integration requires unreasonable access for teams. Adding your use case there helps us gauge demand and prioritize.