Add new setting for grouping CRD in UI menu

[snaquekiller]

This pull request introduces a new feature for managing Custom Resource Definitions (CRDs) in the preferences UI and sidebar. It includes changes to add support for grouping CRDs, validate JSON configurations, and improve error handling in sidebar item registration. The most important changes are grouped into themes: CRD Preferences, Sidebar Enhancements, and Error Handling.

CRD Preferences:

• Added navigateToCrdPreferencesInjectable to enable navigation to CRD preferences. (packages/core/src/features/preferences/common/navigate-to-crd-preferences.injectable.ts)
• Introduced crdGroupPreferenceBlockInjectable and CrdGroup component to allow users to define custom CRD groups in JSON format, with validation and formatting functionality. (packages/core/src/features/preferences/renderer/preference-items/crd/crd-group/crd-group-preference-block.injectable.ts, packages/core/src/features/preferences/renderer/preference-items/crd/crd-group/crd-group.tsx) [1] [2]
• Added CRD preference page and tab injectables to structure the preferences UI. (packages/core/src/features/preferences/renderer/preference-items/crd/crd-preference-page.injectable.tsx, packages/core/src/features/preferences/renderer/preference-items/crd/crd-preference-tab.injectable.ts) [1] [2]
• Updated userPreferenceDescriptorsInjectable and userPreferencesPersistentStorageInjectable to store and retrieve CRD group preferences. (packages/core/src/features/user-preferences/common/preference-descriptors.injectable.ts, packages/core/src/features/user-preferences/common/storage.injectable.ts) [1] [2] [3]

Examples

Sidebar Enhancements:

• Enhanced groups-sidebar-items-computed.injectable.ts to support hierarchical grouping of CRDs based on user-defined JSON configurations, including top-level and sub-level groups. (packages/core/src/renderer/components/custom-resource-definitions/groups-sidebar-items-computed.injectable.ts) [1] [2] [3]
• Improved sidebar item generation logic to handle CRD grouping and added zero-width spaces in titles for better line breaks. (packages/core/src/renderer/components/custom-resource-definitions/groups-sidebar-items-computed.injectable.ts)

Error Handling:

• Updated groups-sidebar-items-registrator.injectable.ts to wrap reactions in try/catch blocks, ensuring errors in sidebar item computation or registration do not propagate. (packages/core/src/renderer/components/custom-resource-definitions/groups-sidebar-items-registrator.injectable.ts)

[dex4er]

I won't lie: it seems to me overcomplicated. I really don't want to create any JSON file (btw, why JSON if all ecosystem is YAML-based) for grouping of menus, then catching all edge cases (too long strings, broken schemas, weird characters, 10 more edge cases) then editing it for all my CRDs (now 77, will be more probably).

I mean: it looks like some hack rather than friendly solution.

What I would really need is maybe some automating grouping it by predefined set of labels/annotations? I see we eventually could have some heuristic and use first found label/annotation like, ie.:

• helm.toolkit.fluxcd.io/name
• app.kubernetes.io/part-of
• app.kubernetes.io/name
• meta.helm.sh/release-name
• kustomize.toolkit.fluxcd.io/name

Some UI when I can build the menu also would be welcomed but still: like is too short to spend it on building menu for 77 resources, IMO.

[dex4er]

Another possibility maybe: just a simple YAML with Regexp/substring/suffix? Why I need to list all CRDs one-by-one if simple rule could catch them all and 1st is winning. Ie:

AWS: 
- amazonaws.com
- aws
KEDA:
- keda.sh
External Secrets:
- external-secrets.io
FluxCD:
- fluxcd.controlplane.io
- fluxcd.io
Karpenter:
- karpenter.sh
Kyverno:
- kyverno.io
- wgpolicyk8s.io
Kubernetes:
- k8s.io
Prometheus:
- monitoring.coreos.com

Simple, effective, we can provide default configuration for 1000 of them in our main repo or provide a canonical list to download/refresh and it can be a default with option to add or override by user for some unknown CDRs.

[snaquekiller]

I can convert it to yaml that not a problem for me and accept regex that ok for me i thought about it but didn't think if we need it or not.
Having something too simple will not help for our use-case. For the moment if you don't put it on the json it's will not change the way the crd is display.
For you to understand actually we use it with this json :

{
	"Kyverno": [
		{
			"Core": [
				"kyverno.io"
			]
		},
		{
			"Policies": [
				"policies.kyverno.io"
			]
		},
		{
			"Reports": [
				"reports.kyverno.io"
			]
		}
	],
	"FluxCD": [
		{
			"Core": [
				"kustomize.toolkit.fluxcd.io"
			]
		},
		{
			"Image Policies": [
				"image.toolkit.fluxcd.io"
			]
		},
		{
			"Source Control": [
				"helm.toolkit.fluxcd.io",
				"source.toolkit.fluxcd.io"
			]
		},
		{
			"Notifications": [
				"notification.toolkit.fluxcd.io"
			]
		}
	],
	"Cast AI": [
		{
			"Autoscaling": [
				"autoscaling.cast.ai"
			]
		},
		{
			"Gate Keeper": [
				"config.gatekeeper.sh",
				"expansion.gatekeeper.sh",
				"externaldata.gatekeeper.sh",
				"mutations.gatekeeper.sh",
				"status.gatekeeper.sh",
				"syncset.gatekeeper.sh",
				"templates.gatekeeper.sh"
			]
		},
		{
			"Policies": [
				"wgpolicyk8s.io"
			]
		}
	],
	"KEDA": [
		{
			"Core": [
				"keda.sh"
			]
		},
		{
			"Events": [
				"eventing.keda.sh"
			]
		}
	],
	"CSI": [
		{
			"Secrets": [
				"secrets-store.csi.x-k8s.io"
				]
			},
		{
			"Volume Snaphost": [
				"snapshot.storage.k8s.io"
			]
		}
	],
	"Cert Manager": [
		{
			"Core": [
				"cert-manager.io"
			]
		},
		{
			"ACME": [
				"acme.cert-manager.io"
			]
		}
	],
	"Cluster API": [
		{
			"Addons": [
				"addons.cluster.x-k8s.io"
			]
		},
		{
			"Cluster": [
				"clusterctl.cluster.x-k8s.io",
				"cluster.x-k8s.io"
			]
		},
		{
			"IPAM": [
				"ipam.cluster.x-k8s.io"
			]
		},
		{
			"Runtime": [
				"runtime.cluster.x-k8s.io"
			]
		}
	],
	"Victoria Metrics": [
		{
			"Core": [
				"operator.victoriametrics.com"
			]
		},
		{
			"Monitoring": [
				"monitoring.coreos.com"
			]
		}
	],
	"Other": [
		{
			"APISIX": [
				"apisix.apache.org"
			]
		},
		{
			"CollectorD": [
				"collectord.io"
			]
		},
		{
			"Kubecost": [
				"kubecost.com"
			]
		},
		{
			"LinkerD": [
				"linkerd.io",
				"policy.linkerd.io"
			]
		},
		{
			"Microsoft Defender": [
				"defender.microsoft.com"
			]
		},
		{
			"Redis": [
				"redis.redis.opstreelabs.in"
			]
		},
		{
			"Service Mesh Interface": [
				"split.smi-spec.io"
			]
		},
		{
			"Trivy": [
				"aquasecurity.github.io"
			]
		}
	]
}

[dex4er]

OK, let's focus on a very simple example. I have a fresh cluster with following CRDs:

1. I don't want to spend more than 0,5 minute for preparing a new menu.
2. I can use something default and this default can be provided in Freelens ready -> the best solution
3. I can make my own menu but I don't want to type too much then I prefer grouping everything into one menu except maybe something important to me then I don't want to list them all 17 one-by-one.
4. JSON is no-go for me as it is for machines, not humans.
5. Less is more. With 100 different CDRs I don't want to scroll 2 screens to find the correct menu.

Then I imagine I can group it that way (ie.)

1. Flux
   a. Packages (I can combine Kustomization and Helm Releases together)
   b. Sources
   c. Images
   d. Others (notifications and operator and anything that is not explicitly in other groups)

I miss in your proposition:

1. YAML as an obvious solution
2. Catch-all rule, as I don't want to list explicitly every single CDR that belongs to "others" in top menu or submenu
3. Built-in configuration that could be provided by-default for all users of Freelens.
4. Merging/overriding users settings with default settings as what I really need is to not prepare own menu: it should be already prepared by Freelens.

[snaquekiller]

1 -2- i agree to create a default configuration it's always cool to have it. We just need to create a good grouping. I don't necessary have enought exemple/list of crd for creating everything myself.
3 - i will add the regex possibility too
4 - i will change it to read yaml that ok for me, i will work on it tomorrow or during this week.

For the catch-all rule what do you want ?

• by default what i have done for the moment is if i have not catch it with my configuration i let the interface by default. what we want in end ?

The other thing is what do we want for the order, alphabeticaly ? same as the yaml ?

I will work on it during this week. maybe some collegue will help in their free time

[dex4er]

Hi, thanks!

Take your time. This is a cool feature we can have, and I respect your time.

I try to define the best specification that could be useful for everybody: flexible but with good defaults for everyone who doesn't want to build own menus.

We can build something to start based on our experience and the list of what we already use. I think the menu should just ignore empty entries so we could provide ie. hierarchy for FluxCD that would be just silently ignored if you have ie. Argo and don't use FluxCD at all.

Yes, YAML and JSON have ordered lists then we should honor this ordering as well. As the maps are ordered, we do not need to hide submenu in the list (menu:{submenu:[items]} is better than menu:[{submenu:[items]}]).

YAML parser accepts JSON in 100% then you can provide your config in JSON format too if you prefer.

Eventually, we can have 2 lists: one system list (default or optional default) and user's list. Quite similar concept to what I have in VScode:

Then the best case is that I do not need to edit the file because everything is ready for me.

If I will merge system menu with user menu I can make changes:

1. Delete system entry by defining null. Ie. I want to hide "aws" menu:

AWS: ~

2. Add CRDs missing is system menu:

Super Secret:
- supersecret.operator.io

3. Add extra submenu to existing or move entries between:

Proposed system (just an example):

FluxCD:
  Kustomization:
  - kustomize.toolkit.fluxcd.io
  Helm:
  - helm.toolkit.fluxcd.io
  Sources:
  - source.toolkit.fluxcd.io
  Images:
  - image.toolkit.fluxcd.io
  Notifications:
  - notification.toolkit.fluxcd.io
  Operator:
  - fluxcd.controlplane.io
  Others:
  - fluxcd.io

Now I think charts and repositories should be in Helm menu rather than in sources:

FluxCD:
  Helm:
  - helmcharts.source.toolkit.fluxcd.io
  - helmrepositories.source.toolkit.fluxcd.io

That's it: first, more detailed matching rule is winning: charts and repositories goes from Sources to Helm menu.

4. Hiding submenu:

FluxCD:
  Operator: ~

5. Resetting the system menu or submenu.

FluxCD:
  Helm:
  - ~ # ignore existing submenu, add others
  - helmrepositories.source.toolkit.fluxcd.io

or

FluxCD:
  ~: ~ # ignore everything in FluxCD, build my new menu
  Helm:
  - helmrepositories.source.toolkit.fluxcd.io

5. Catch all:

FluxCD:
  Others:
  - fluxcd.io
Others:
  - ""

We do not need to implement regexp. Simply matching the substring is good enough.

We build the full string based on a pluralized, lowercase resource name + URL without version:

• HelmRelease = helmreleases.helm.toolkit.fluxcd.io
• Kustomization = kustomizations.kustomize.toolkit.fluxcd.io
• HelmRepository = helmrepositories.source.toolkit.fluxcd.io

Then rules ie.:

• helmreleases.helm.toolkit.fluxcd.io matches: HelmRelease
• helm.toolkit.fluxcd.io matches: HelmRelease and others with this ending
• fluxcd.io matches: HelmRelease, Kustomization, HelmRepository and all others with this ending
• "" matches: everything

The first match with more dots in the rule should win.

I don't see place here for regexp really as it will make the syntax more complex and other edge cases about quoting parameters, YAML/JSON unfriendliness, etc.

In future, we can have some React view that will parse the config, present it, and after editing,g it'll save it back to YAML/JSON. It is exactly the same as VScode config editor which generates JSON in the end.

[snaquekiller]

Hello Hello after a lot of try and test on my way i have some new work :

This pull request introduces enhancements to the extension registration process, updates custom resource sidebar handling, and adds a new "CRDs" tab in preferences. The changes focus on improving state management, updating test snapshots, and enhancing the user interface.

Extension Registration Enhancements:

• Added a previousInjectablesMap to track the previous state of injectables for each registrator, ensuring proper state management during updates. (packages/core/src/extensions/extension-loader/extension/extension.injectable.ts) [1] [2]
• Updated the injectableDifferencingRegistrator to differencingRegistrator for better clarity and consistency. (packages/core/src/extensions/extension-loader/extension/extension.injectable.ts)

Custom Resource Sidebar Updates:

• Updated test IDs and labels in snapshots to reflect the new naming convention for custom resource groups and resources (e.g., "some.group.com" to "some-resources.some.group.com"). (packages/core/src/features/cluster/__snapshots__/custom-resources-in-sidebar.test.tsx.snap) [1] [2] [3]
• Modified tests to validate the updated sidebar structure and naming. (packages/core/src/features/cluster/custom-resources-in-sidebar.test.tsx) [1] [2] [3] [4] [5]

Preferences UI Enhancements:

• Added a new "CRDs" tab to the preferences UI, including updates to multiple test snapshots to reflect this addition. (packages/core/src/features/helm-charts/__snapshots__/add-custom-helm-repository-in-preferences.test.ts.snap) [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

i still need to test that everything work well and there is no case i forgot to test . but it's seem to work well on my side for the moment

If you have a list for the default configuration :) could be good .

[snaquekiller]

@dex4er any suggestion ? comment about it

[snaquekiller]

@dex4er hello hello what can do to merge it ?

Thanks

[jan-mrm]

Very cool feature, looking forward to trying it out 🙂 thanks for your effort @snaquekiller 👍

[snaquekiller]

Very cool feature, looking forward to trying it out 🙂 thanks for your effort @snaquekiller 👍

thanks but there no reply from dexer how to merge it and what he want more :'(

[jan-mrm]

Hey @dex4er, not to be impatient, but do you have some time again to review this PR once again or at least give any feedback about the status, by any chance? 🙂 Sorry if this counts as being annoying. Just some short feedback would be very cool. much appreciated 👍

[robertobandini]

Hi @snaquekiller!

I personally just saw this PR now and wanted to thank you so much for your work regardless.
If you'd like, we're talking about it here:
#713 (comment)

[juv]

This looks great! How can I try it out to give feedback?

[robertobandini]

This looks great! How can I try it out to give feedback?

Hi @juv and thank you about your interest in Freelens!
Take a look also to this: #713
If the PR is not merged in the main branch of this repo you can clone it and try it by building Freelens from the source:
https://github.com/freelensapp/freelens/wiki/Development