❌ Preview Environment deleted from Bunnyshell

Available commands (reply to this comment):

• 🚀 /bns:deploy to deploy the environment

Codecov Report

Attention: Patch coverage is 28.00000% with 18 lines in your changes missing coverage. Please review.

Please upload report for BASE (master@7ab5015). Learn more about missing BASE report.
Report is 376 commits behind head on master.

@@            Coverage Diff            @@
##             master   #20374   +/-   ##
=========================================
  Coverage          ?   55.98%           
=========================================
  Files             ?      322           
  Lines             ?    44772           
  Branches          ?        0           
=========================================
  Hits              ?    25067           
  Misses            ?    17105           
  Partials          ?     2600           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

nice work 👍

Thanks @reggie-k for the in-depth review!

May fix #8314 #6043

Forked from: #9496

Huge thanks and credit to initial contributor @ls0f

Great, long time waiting for the feature

on what version this feature is available? I can see that it's already on master branch

@dodistyo , it will be part of 2.14

currently, the feature should be available in the image tag latest, right? @pasha-codefresh

Update:
I have tried it using latest image. adding cluster with the cli using --proxy-url argument works perfectly.
But the cluster addition using secret is not working, got failed status and timeout. or sometimes stuck at unknown status.

Yeah @dodistyo i it should work under latest tag. I will take a look why it may happens

I'm on version v2.14.5+f463a94 and this doesn't seem to work here:

1. It's not easy to add configs if a different proxy configuration needs to be used for the argocd-server from the current client (but this can be worked around).
2. My config in the cluster secret looks correct, but when accessing the cluster the proxy isn't used (as I can tell from my socks proxy logs. My config:
   {
   "bearerToken": "",
   "tlsClientConfig": {
   "insecure": false
   },
   "proxyUrl": "socks5://172.24.20.194:1080"
   }

I also confirmed that access using the given proxyUrl is actually working ...
Any ideas?

Have you tried to debug it by exec to the argocd server pod? @guhilling

Have you tried to debug it by exec to the argocd server pod? @guhilling

@dodistyo Sorry for the late reply. Was quite busy last week. I just checked but have no clue how the argocd-server would actually access the "other" cluster? Any proposal? I made sure that the proxy server is actually reachable from the namespace/cluster ...

@guhilling Try to exec pod argocd-application-controller sts
Have a look at this docs: https://argo-cd.readthedocs.io/en/latest/user-guide/commands/argocd_admin_cluster_kubeconfig/

make sure the generated kubeconfig has the correct format.

if the format is incorrect, adjust accordingly

@dodistyo the generated kubeconfig is actually missing the certificate data But I also get a "timeout" error when looking at the state of the cluster (trying to access the remote cluster version).
So the i/o timeout seems to show that proxy connection or network doesn't work as expected. OTHO when creating a debug pod from the argocd namespace and using the generated kubeconfig (with --insecure...) everything works nice. Any more ideas? btw. Can I configure the certificate data when creating the cluster with "argocd cluster add"?

how did you generate the kubeconfig? usually the certificate is already there when we generate the kubeconfig. also, what kind of kubernetes cluster do you run?
you don't need to create debug pod in namespace argocd actually, you can directly run kubectl in the argocd-application-controller, before running kubectl, don't forget to export envar KUBECONFIG=path-to-kubeconfig.

I added the certificate and the kubeconfig generated by "argocd admin cluster kubeconfig" looks good now (contains inline certificate and correct proxy-url).
Some context: running on openshift/okd, I configured ovn-kubernetes cni to use host routing (and I also made sure routing is correct). My sts image is quay.io/argoproj/argocd@sha256:19608c266cc41e4986d9b1c2b79ea4c42bb9430269eefc5005e9d65be4d22868, no kubectl binary in the sts pod
output of "argocd version":
argocd: v2.14.5+f463a94
BuildDate: 2025-03-11T04:57:25Z
GitCommit: f463a94
GitTreeState: clean
GoVersion: go1.24.1
Compiler: gc
Platform: darwin/arm64
argocd-server: v2.14.5+f463a94
BuildDate: 2025-03-11T04:57:25Z
GitCommit: f463a94
GitTreeState: clean
GoVersion: go1.24.1
Compiler: gc
Platform: darwin/arm64
Kustomize Version: v5.6.0 2025-01-14T15:08:34Z
Helm Version: v3.17.2+gcc0bbbd
Kubectl Version: v0.31.0
Jsonnet Version: v0.20.0
Any help greatly appreciated!

I forgot that i was running custom argocd image, i might added the kubectl when building the image. now since you're successfully generate the kubeconfig, you might try to deploy debug pod with kubectl installed. and try to connect to the cluster with the generated kubeconfig.

Made sure it works using:

• generated kubeconfig (argocd admin cluster kubeconfig)
• debug pod for "default-application-controller-0" (called my argocd custom resource "default")
• kubectl from container image quay.io/openshift/origin-cli:4.18.0
  No clue why the same kubeconfig won't be used by argo. But I'm sure the proxy url is ignored as my proxy (danted) is configured to show connection requests and it logs nothing.

I'm experiencing an issue when trying to add multiple GKE clusters to ArgoCD. Currently, ArgoCD uses the Kubernetes API URL as the unique identifier for clusters. However, in our GKE setup, all clusters use the same API IP address format (https://x.x.x.x) even though they're in separate VPCs.

This creates a conflict in ArgoCD that prevents us from adding multiple clusters, as they all appear to have the same identifier.

It would be extremely useful if ArgoCD could support alternative cluster identification mechanisms or allow custom identifiers to be assigned, rather than relying solely on the API server URL as the unique identifier.