Repository: helm/helm
File: pkg/release/util/kind_sorter.go (Go)

Code before:
	"StorageClass",
	"PersistentVolume",
	"PersistentVolumeClaim",
	"CustomResourceDefinition",
	"ClusterRole",
	"ClusterRoleList",
	"ClusterRoleBinding",
	"ClusterRoleBindingList",
	"Role",
	"RoleList",
	"RoleBinding",
	"RoleBindingList",
	"Service",
	"DaemonSet",
	"Pod",
	"ReplicationController",
	"ReplicaSet",
	"Deployment",
	"HorizontalPodAutoscaler",
	"StatefulSet",
	"Job",
	"CronJob",
	"IngressClass",
	"Ingress",
	"APIService",
	"MutatingWebhookConfiguration",
	"ValidatingWebhookConfiguration",
}

// UninstallOrder is the order in which manifests should be uninstalled (by Kind).
//
// Those occurring earlier in the list get uninstalled before those occurring later in the list.
var UninstallOrder KindSortOrder = []string{
	"ValidatingWebhookConfiguration",
	"MutatingWebhookConfiguration",
	"APIService",
	"Ingress",
	"IngressClass",
	"Service",
	"CronJob",
	"Job",
	"StatefulSet",
	"HorizontalPodAutoscaler",
	"Deployment",
	"ReplicaSet",
	"ReplicationController",
	"Pod",
	"DaemonSet",
	"RoleBindingList",
	"RoleBinding",
	"RoleList",

Review comment (suggestion):
For my [OpenTelemetry use cases](https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-operator), I’d like to request to adjust the order of operations slightly.

- **Lines 67-69:**  
  ```yaml
  ValidatingWebhookConfiguration
  MutatingWebhookConfiguration
  APIService
  ```  
- **Lines 76-78:**  
  ```yaml
  APIService
  MutatingWebhookConfiguration
  ValidatingWebhookConfiguration
  ```  

For example, when an incoming request interacts with my webhooks, the workflow looks kind of like this sequence:  

```
Request -> APIService -> ValidatingWebhook -> MutatingWebhook -> API Server
```
For example, when creating a new pod:  
1. The request reaches **APIService v1alpha1.opentelemetry.io**.  
2. The **ValidatingWebhook** determines whether the pod should be mutated.  
3. If allowed, the **MutatingWebhook** mutates the request for observability instrumentation purposes.
4. The pod request then proceeds through normal Kubernetes processing for creating a pod.  

Code after:
	"StorageClass",
	"PersistentVolume",
	"PersistentVolumeClaim",
	"CustomResourceDefinition",
	"ClusterRole",
	"ClusterRoleList",
	"ClusterRoleBinding",
	"ClusterRoleBindingList",
	"Role",
	"RoleList",
	"RoleBinding",
	"RoleBindingList",
	"Service",
	"DaemonSet",
	"Pod",
	"ReplicationController",
	"ReplicaSet",
	"Deployment",
	"HorizontalPodAutoscaler",
	"StatefulSet",
	"Job",
	"CronJob",
	"IngressClass",
	"Ingress",
	"APIService",
	"MutatingWebhookConfiguration",
	"ValidatingWebhookConfiguration",
}

// UninstallOrder is the order in which manifests should be uninstalled (by Kind).
//
// Those occurring earlier in the list get uninstalled before those occurring later in the list.
var UninstallOrder KindSortOrder = []string{
	// For uninstall, we remove validation before mutation to ensure webhooks don't block removal
	"ValidatingWebhookConfiguration",
	"MutatingWebhookConfiguration",
	"APIService",
	"Ingress",
	"IngressClass",
	"Service",
	"CronJob",
	"Job",
	"StatefulSet",
	"HorizontalPodAutoscaler",
	"Deployment",
	"ReplicaSet",
	"ReplicationController",
	"Pod",
	"DaemonSet",
	"RoleBindingList",
	"RoleBinding",