## Summary On a GitLab instance served under a relative URL root (for example `https://gitlab.example.com/gitlab`), agentk builds the project path of a Flux `GitRepository` from the whole path of `spec.url`. The repository URL `https://gitlab.example.com/gitlab/some-org/some-repo.git` becomes the project path `gitlab/some-org/some-repo`, which agentk writes to the `Receiver` project annotation and sends to kas in `ReconcileProjects`. Push events carry `Project.FullPath`, which is `some-org/some-repo`. kas compares the two with an exact set lookup, so it never forwards a push for that project, and Flux reconciles only on its polling interval. Nothing reports an error: the host check in agentk compares hostnames only, so it passes. I am opening an issue rather than a merge request because where the fix belongs is a design choice for you to make (see "Possible fixes"). The impact is low: only installations with a relative URL root are affected, and Flux still reconciles on its own interval. ## Steps to reproduce 1. Run GitLab under a relative URL root, for example `external_url "https://gitlab.example.com/gitlab"` in Omnibus, or `global.appConfig.relativeUrlRoot: /gitlab` in the Helm chart. 2. Connect an agent with the Flux module enabled, and create a `GitRepository` with `spec.url: https://gitlab.example.com/gitlab/some-org/some-repo.git`, where `some-org/some-repo` is a public project or the agent's configuration project: kas only notifies an agent about pushes to those ([`gitops.md#L104-105`](https://gitlab.com/gitlab-org/gitlab/-/blob/c817c766a3eb8b5403aa6354334604dce06454e2/doc/user/clusters/agent/gitops.md#L104-105)). 3. Push to `some-org/some-repo`. I reproduced it at unit level, not on a running instance, on `master` at d8846cbfe1e49d37c98c1abaa3c8d1f4606de3bd, with a test in `internal/module/flux/agentk` modelled on `TestGitRepositoryController_SuccessfullyCreateReceiverAndSecretForGitRepository`. It runs `reconcile` for the `GitRepository` above and captures the project annotation of the applied `Receiver`. With the external URL set to either `https://gitlab.example.com` or `https://gitlab.example.com/gitlab`, the assertion fails with: ```text expected: "some-org/some-repo" actual : "gitlab/some-org/some-repo" ``` ## What is the current bug behavior? agentk annotates the `Receiver` with `gitlab/some-org/some-repo`, kas never matches it against push events for `some-org/some-repo`, and Flux gets no notification of pushes. ## What is the expected correct behavior? The project path agentk registers matches the project's full path in GitLab (`some-org/some-repo`), so a push triggers an immediate reconciliation, as it does on an instance without a relative URL root. ## Relevant code - agentk takes the whole URL path as the project path: [`gitrepository_controller.go#L534-546`](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/d8846cbfe1e49d37c98c1abaa3c8d1f4606de3bd/internal/module/flux/agentk/gitrepository_controller.go#L534-546), called at [L319](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/d8846cbfe1e49d37c98c1abaa3c8d1f4606de3bd/internal/module/flux/agentk/gitrepository_controller.go#L319). The host check just before it compares hostnames only ([L314](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/d8846cbfe1e49d37c98c1abaa3c8d1f4606de3bd/internal/module/flux/agentk/gitrepository_controller.go#L314)). - kas matches push events by exact full path and answers with the event's path: [`server.go#L83-85`](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/d8846cbfe1e49d37c98c1abaa3c8d1f4606de3bd/internal/module/flux/server/server.go#L83-85) and [L129](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/d8846cbfe1e49d37c98c1abaa3c8d1f4606de3bd/internal/module/flux/server/server.go#L129). - agentk then looks up receivers by that exact string: [`client.go#L227`](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/d8846cbfe1e49d37c98c1abaa3c8d1f4606de3bd/internal/module/flux/agentk/client.go#L227) and [L242](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/d8846cbfe1e49d37c98c1abaa3c8d1f4606de3bd/internal/module/flux/agentk/client.go#L242). - kas hands its `gitlab.external_url` to agentk unchanged ([`agent_configuration/server/factory.go#L43`](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/d8846cbfe1e49d37c98c1abaa3c8d1f4606de3bd/internal/module/agent_configuration/server/factory.go#L43)). The kascfg docs give that field the format `<scheme>://<domain>:<port>`, with no path ([`kascfg_proto_docs.md#L235`](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/d8846cbfe1e49d37c98c1abaa3c8d1f4606de3bd/pkg/kascfg/kascfg_proto_docs.md#L235)), and the Kubernetes API proxy uses it as the exact allowed `Origin` ([`kubernetes_api/server/factory.go#L94-96`](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/d8846cbfe1e49d37c98c1abaa3c8d1f4606de3bd/internal/module/kubernetes_api/server/factory.go#L94-96), [`proxy.go#L355-356`](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/d8846cbfe1e49d37c98c1abaa3c8d1f4606de3bd/internal/module/kubernetes_api/server/proxy.go#L355-356)). Since !4627 the same docs entry also makes it the issuer AutoFlow expects in token-exchange JWTs, and says to set it whenever `address` is not "the URL GitLab publishes as its own". With a relative URL root, that URL includes the root: the `iss` GitLab puts in token-exchange JWTs is its OpenID Connect issuer ([`token_issuer.rb#L92`](https://gitlab.com/gitlab-org/gitlab/-/blob/c817c766a3eb8b5403aa6354334604dce06454e2/lib/authn/token_exchange/token_issuer.rb#L92)), `Gitlab.config.gitlab.url` ([`doorkeeper_openid_connect.rb#L4`](https://gitlab.com/gitlab-org/gitlab/-/blob/c817c766a3eb8b5403aa6354334604dce06454e2/config/initializers/doorkeeper_openid_connect.rb#L4)), built with `relative_url_root` ([`settings.rb#L77-79`](https://gitlab.com/gitlab-org/gitlab/-/blob/c817c766a3eb8b5403aa6354334604dce06454e2/config/settings.rb#L77-79)). - The two packaged deployments disagree on whether that field carries the root. Omnibus sets it to `scheme://host` and drops the root ([`gitlab_kas.rb#L91`](https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/3f8e88110cb3a819f7b49b890f9372bdbe5584c2/files/gitlab-cookbooks/gitlab-kas/libraries/gitlab_kas.rb#L91)), while it sets `gitlab.address` to the full `external_url` ([L35](https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/3f8e88110cb3a819f7b49b890f9372bdbe5584c2/files/gitlab-cookbooks/gitlab-kas/libraries/gitlab_kas.rb#L35)). The Helm chart sets it to `gitlab.gitlab.url` ([`_default-config.yaml#L20`](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/53e3d35bd446ef30f25cead1b8d8331d4d7ffe5d/charts/gitlab/charts/kas/templates/_default-config.yaml#L20)), which appends `relativeUrlRoot` ([`_helpers.tpl#L55-61`](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/53e3d35bd446ef30f25cead1b8d8331d4d7ffe5d/templates/_helpers.tpl#L55-61)). ## Possible fixes I see three options and would like to know which one you prefer before I send a merge request: 1. agentk strips the path of the external URL it receives from kas from the repository URL path (http and https URLs only; SSH clone URLs have no relative root). I tried this locally: it fixes the case where `gitlab.external_url` carries the root (the Helm chart case), but not the Omnibus default, where agentk never learns the root. It also needs Omnibus to keep the root in `gitlab_kas['gitlab_external_url']`, the kascfg docs to allow a path, and the Kubernetes API proxy to compare the `Origin` header with the origin of that URL rather than with the whole string, since an `Origin` header never carries a path. 2. kas normalizes on its side, given the relative root explicitly (a new kascfg setting; the Omnibus default happens to put it in `gitlab.address`, but that field is the address kas uses for API calls, so I would not rely on it). It strips the root from the paths agentk sends and answers with the path as agentk sent it, because agentk looks up receivers by the exact string it registered. A plain suffix match is not enough on its own, since a top-level group can have the same name as the relative root. agentk does not change, so with the setting in place this also works with the agentk versions already deployed. 3. kas passes the relative root to agentk as its own field in the agent configuration, and agentk strips it as in option 1. This leaves the format of `gitlab.external_url` as it is. Related: #269 (kas on a GitLab with a relative URL root).