I tried to replace the project_id with the numeric ID for the project, with or without quotes, but no luck at all.
The weird part, is that the agent configuration and project manifest are in the same repository. If i update the agent config.yaml, then the kubernetes agent properly reload config but still can’t find the project with above error.
Hi, I have exactly the same issue.
I know in release notes it says that kubernetes agent is now available in community edition but maybe it’s not the case for all of it’s functionality? The documentation says that this feature is apparently premium. I have no idea if that’s how it works or is that documentation issue.
In any case the error isn’t very descriptive and the additional debug logs provide no info.
Yep i saw this but version history at top of the page say :
Introduced in GitLab Premium 13.7.
Introduced in GitLab 13.11, the Kubernetes Agent became available on GitLab.com.
Introduced in GitLab 14.0, the resource_inclusions and resource_exclusions attributes were removed and reconcile_timeout, dry_run_strategy, prune, prune_timeout, prune_propagation_policy, and inventory_policy attributes were added.
The ci_access attribute was introduced in GitLab 14.3.
The GitLab Kubernetes Agent was moved to GitLab Free in 14.5.
So my thought was the premium part was a mistake in the documentation, because no other way to use the gitlab agent is documented anywhere.
the worst part, is that you are most probably right, but the error message should say so. And honestly, if they release this agent just to allow us to execute kubectl command, then it does not worth it.
You are trying to use a feature that is currently in Premium.
I guess the issue here is that the error isn’t very descriptive. It says that the project is not found which suggests an issue with the setup. If it’s not possible to move the feature to community edition it would be nice if you could at least make the error more descriptive of what the issue actually is.
You should be able to set up the CI/CD tunnel with GitLab CE. We are in the process of discussing what other features will be available in GitLab Free and what remains Premium.
With the only difference that in the last link, it tells that the GitOps Workflow is Premium only.
I don’t quiet understand what exactly comes with the All Tier Agent, especially considering it cannot even access my manifest repo, so I basically just get to see if the agent is connected with KAS in Gitlab and nothing more?
thanks for the feedback. We’ve discussed the problems from the initial question, and created a follow-up MR to make sure that the quickstart does not suggest to copy configuration when it is not needed to start using the GitLab Agent for Kubernetes. This removes the gitops config block which led to the questions.
There is more documentation work underway to clarify in this MR.
Sorry to bother you again, but how are we supposed to use configure the review, staging and production scopes for the clusters? How are we supposed to configure base domain?
I managed to setup a “Cluster management template project” and install the cert-manager, ingress and runner. But deploying apps with the Auto DevOps feature is broken.
Only the build job is created. I had to manually set the KUBE_INGRESS_BASE_DOMAIN and CI_KUBERNETES_ACTIVE so that the “Deploy” job would be created. But then it deploys the container with no cert-manager and in the “default” k8s namespace.
I really appreciate the help, but it just appears that this is not documented well, and we have to so somehow figure out how to use this setup.