ArgoCD - fix UI gripes

[LPLabrys99]

Summary

As a regular user of ArgoCD, there are some issues with the UI which cause a lot of wasted time and annoyance. It would be nice if these issues could be fixed or addressed in some way in a future version.

Motivation

To save UI users time and streamline the experience.

Proposal

Apologies if this EP sounds a bit short, I had typed a much longer version with screenshots and Chrome crashed before I could submit it.

Cannot specify cluster name and URL

Ever since it was possible I have been using the cluster name to specify deploy destination instead of URL. I don't set the URL at all, however it seems that when interacting with ArgoCD apps through some mediums (e.g. helm chart, via CLI, or API) both the URL and and name are being set concurrently. This happens and is persisted in the etcd data, and then when I edit application parameters in the UI, ArgoCD rejects the change because the cluster name and URL have both been set.

If it is possible for ArgoCD to work with the name and URL set, then why can't the UI accept this? If only one is showing in the UI, then maybe the UI should only try to persist the one which is showing? The only solution I've found is to go to the destination tab, switch to URL, save, switch to name again and save again before going back to the parameters view and editing again. It's very annoying especially if you've spent some time editing your parameters already.

Large charts

When working with larger charts that take a long time to compile, the ArgoCD UI will reject the changes if the chart does not compile within a set timeout period (around 5-10s). This is problematic for larger charts that include CRDs, or when using plugins that can cause the chart to take longer to compile. There is a workaround that you can do - use kubectl edit ... to edit the ArgoCD app in etcd directly and the change is accepted instantly.

It would be nice if the cluster administrator could configure the timeout time. It would be even better if the ArgoCD UI accepted the change without waiting for the chart to compile and just put an alert on the UI later if there was a compilation failure (already a feature of the current UI, and this is the current behaviour if issues come up using the kubectl method).

Expand / contract values.yaml view

If you use helm chart templating you probably have some larger values.yaml files in your apps. By default the view of this file is squashed to be only a few lines wide in ArgoCD, so you cannot see the whole file without expanding the view. When out of the edit view, ArgoCD gives you an arrow that you can click to expand the values.yaml file and show the entire content. When you click the edit button to go into edit mode, if the values.yaml view has been expanded, it will collapse itself so that it is tiny again, and in the edit view the 1 click expansion element is not there - instead you have to align the cursor over the corner of the values.yaml file editor and drag the textbox to expand to see the whole file. It sounds minor but when working with large values.yaml files it often takes longer to do this than it does to edit the value. Also there is the added annoyance of the position in the viewport moving, so if you just spent time locating the value you need to change in view mode, you will have to do it again when in edit mode. If ArgoCD rejects your changes for any of the reasons above, you will get to enjoy doing this several times.

I think it would be much better if the values.yaml could remain in the same dimenions and position when switching between view and edit mode. Also it would be convenient if the values.yaml view could auto-expand to view the entire content without having to expand the view manually.

Resource deletion

When you delete resources in the UI you get a big yellow alert box prompting that deleting resources is dangerous and asking you to type the resource name back to the app. While this is useful to stop newbies from making mistakes, it can take up a lot of time for more experienced/regular users. It would be nice if there was a simple checkbox acceptance + delete type selection instead of having to type the full resource name. Also it would be nice if the level of confirmation required could be configured at application or deployment level by an application administrator.

[crenshaw-dev]

@LPLabrys99 can you break these into individual issues? That'll help keep the conversation threads issue-specific.