Gitlab Agent not working across projects

Replace this template with your information

Describe your question in as much detail as possible:

  • What are you seeing, and how does that differ from what you expect to see?
    My usecase is that I want to have one agent only to run pipelines for all my projects. The hierrachy is GROUP > SUBGROUP[1…n] > projects. I have placed my config.yaml in group/subgroup1/config_repo. My .gitlab-ci.yaml is placed in group/subgroup1/my_repo

I registered the Gitlab agent successfully in the project group/subgroup1/config_repo and I can see it accepted the configurations.

I followed the official documentation for authorizing the agent to work with another project and met the only condition I could see, i.e.

“The Kubernetes projects must be in the same group hierarchy as the project where the agent’s configuration is.”

When I run the pipeline in group/subgroup1/my_repo, it returns this error.

But when I register an agent in the repo, it works as expected. Not sure what am doing wrong.

Also, am I supposed to register runners when I am using an agent?

  • What version are you on? Are you using self-managed or

  • Add the CI configuration from .gitlab-ci.yml and other configuration if relevant (e.g. docker-compose.yml)


    name: bitnami/kubectl:latest
    entrypoint: [""]
  - kubectl config get-contexts
  - kubectl config use-context group/subgroup1/config_repo:my_agent
  - kubectl get pods -A 


  # This agent is accessible from CI jobs in projects in these groups
  - id: oltranz-team/notification-domain/slackbot
    level: debug
  • What troubleshooting steps have you already taken? Can you link to any docs or other resources so we know where you have been?
  1. GitLab Kubernetes Agent CI tunnel at the group level - demo - YouTube
  2. Using a GitLab CI/CD workflow for Kubernetes | GitLab

cc: @dnsmichi please assist if possible

Can I get some assistance. Issue still unresolved

I’m having the same issue where I cannot access an agent from another project

+1, having the same issue… went through all documentation as well all youtube materials and did not work. Is there any update?

@andrew-musoke, have you solved the issue? If so, how?

Thanks a lot! :slight_smile:

Same problem here

@jurbano3 @JustDoItSascha I have not been able to fix this and not received any Gitlab support. If you could ping someone useful, that would help.

hi @andrew-musoke @JustDoItSascha !

I’ve got the same problem as you! I was able to make it work by move my project that contains the agent’s config.yaml to the root group level from the subgroup.

Hi @andrew-musoke, @itaprak, @JustDoItSascha ,

Starting that I have this Gitlab setup:

  • group/subgroup/project-api
  • group/subgroup/project-ui

I solved it using the following configuration:

Project group/subgroup/project-api.

I placed the following configuration


  - id: group/subgroup/project-api
    default_namespace: project-api-prod
    - glob: '/**/*.{yaml,yml,json}'
  # Provide access by project
    - id: group/subgroup/project-ui
      default_namespace: project-ui-prod
  # This agent is accessible from CI jobs in projects in these groups
    - id: group/subgroup
      default_namespace: project-ui-prod

Using it from project-ui.

Using it from outside let’s say project-ui you call it gitlab-ci.yaml and pointing the context to:
group/subgroup/project-api and selecting the agent you have access to it in this case agent-deploy

So in your project-ui CI/CD pipeline will look like the example below.

  stage: deploy-prod
    name: bitnami/kubectl:latest
    entrypoint: ['']
    - kubectl config use-context group/subgroup/project-api:agent-deploy
    - kubectl .....
    - kubectl .....

@jurbano3’s set up worked for me as well. The main issue I imagine the OP was posting about were limitations with the GitLab K8s Agent itself. Mainly this statement (pulled from Gitlab docs)

The Kubernetes projects must be in the same group hierarchy as the project where the agent’s configuration is.
You can install additional agents into the same cluster to accommodate additional hierarchies.

Happy to hear that @deybhayden ! :slight_smile: