Stefan Prodan

I'm in favour of allowing `no_proxy` to be set in the secret

@timaebi see https://github.com/fluxcd/source-controller/pull/1250

The controller has a exponential backoff mechanism, same as Kubernetes has for image pull errors. Every time it fails, the backoff increase the retry interval and ca go up to...

The controller does a full clone every time, you may want to increase the timeout in the GitRepo.

This would be a breaking change to the bundle API. I'm considering adding `namespaceMetadata` as an optional field that would allow setting both labels and annotations. PS. The current workaround...

We don't know that info until the timeout expires, the pooling is for all resources run in parallel via Kubernetes watchers

The PAT is used to perform Git push operations locally on the machine running the Terraform CLI. The deploy token is stored in a Kubernetes secret and is used by...

I'm not a GitLab user so I have no idea how their providers works, maybe @swade1987 knows.

I suggest switching to [Flux Operator](https://github.com/controlplaneio-fluxcd/flux-operator) which does not require write access to GitLab repos: ```sh terraform apply \ -var flux_version="2.x" \ -var flux_registry="ghcr.io/fluxcd" \ -var git_token="${GITLAB_READONLY_TOKEN}" \ -var git_url="https://gitlab.com/my-group/my-fleet.git"...

I guess the PV is stuck, can you check your cluster and see if that's the case, describing the applied objects with kubectl should tell you.