Proposal: Add support for arbitrary application tiles

[carsonoid]

Summary

Add support for customized tiles in an application via a CRD. This issue continues the logical "phase 2" of #3487

Motivation

In may case, the Argo application is the jumping off point for a service. It would be nice to make it easy to add more context and data on the page without having to tie it to a Kubernetes resource.

Proposal

Right now individual resources have the ability to generate links in an Application dashboard via annotations.

However, there are often links that aren't specifically related to dashboards and rather just belong to the app itself. Things like monitoring dashboards or documentation.

It would be really nice to be able to provide these kinds of links and extra data on a dashboard via CRD. The CRDs here effectively act as a simple data source for the UI.

I think it would make sense for these extra tiles to show up above or below the main "app" tile.

apiVersion: argoproj.io/v1alpha1
kind: ArgoCDInterfaceTile
metadata:
  name: my-svc-dashboard
spec:
  link:
    text: Grafana Dashboard
    url: http://my-grafana.com/pre-generated-link
    color: light-red
    text-color: black
    # image would be optional
    image:
      source:
        # emojiName is mutually exclusive with url. You should be able to give it a text
        # name for an emoji and the dashboard will attempt to render it, but render nothing if it doesn't
        # match a known emoji name
        # another option might be to use something like fontawesome to provide this kind of imaging
        emojiName: heavy_exclamation_mark

        # url is mutually exclusive with emojiName. It is the full url
        # to the the image source and will be hot-linked
        # url: http://my-image-source.com/images/dashboard.png

Low effort mock-up:

[crenshaw-dev]

I like this, potentially as a part of UI Extensions support. Except I think I'd want the extensions framework to provide a "node" hook to add something to the UI, and leave it up to the extension code to decide what resource defines that node (e.g. it could simply be a ConfigMap which is annotated to not show up in the normal resource tree).

@zachaller you might find this interesting.

[zachaller]

Yea @crenshaw-dev I think this is one extra data point for our UI v2 extensions framework it would support things like the and more.

[nkkowa]

Something like this could also be useful, perhaps cleaner than putting it alongside the resources:

In our case we have our application manifests in a separate repo than the application source code, and would like to be able to link to the source code from ArgoCD directly.