`flux check` Command Fails to Detect Missing Components

Describe the bug

When using flux check, the command does not properly verify the presence of all specified components. This issue occurs when some Flux components are missing but is not detected by flux check, leading it to incorrectly report success.

Steps to reproduce

Bootstrap Flux with the following command:

flux bootstrap github \
  --owner=h3nryc0ding \
  --repository=flux-check-bug \
  --branch=main \
  --path=./clusters/docker-desktop \
  --personal

Run flux check:
```
flux check
```

Delete all but one Flux deployment:

kubectl delete deployments.apps -n flux-system helm-controller
kubectl delete deployments.apps -n flux-system notification-controller
kubectl delete deployments.apps -n flux-system source-controller

Run flux check again:
- Expected: Check should fail due to missing components.
- Actual: Output shows ✔ all checks passed.
Run flux check with specific components:
```
flux check --components helm-controller,notification-controller,source-controller
```
- Expected: Check should fail for missing components specified in the --components argument.
- Actual: Output again shows ✔ all checks passed.

Expected behavior

After deleting some default components, flux check should fail and report missing components. When components are explicitly passed with the --components argument, flux check should verify the presence of each specified component and fail if any are absent.

Screenshots and recordings

No response

OS / Distro

macOS 14.6.1

Flux version

flux: v2.4.0

Flux check

► checking prerequisites
✔ Kubernetes 1.30.2 >=1.28.0-0
► checking version in cluster
✔ distribution: flux-v2.4.0
✔ bootstrapped: true
► checking controllers
✔ kustomize-controller: deployment ready
► ghcr.io/fluxcd/kustomize-controller:v1.4.0
► checking crds
✔ alerts.notification.toolkit.fluxcd.io/v1beta3
✔ buckets.source.toolkit.fluxcd.io/v1
✔ gitrepositories.source.toolkit.fluxcd.io/v1
✔ helmcharts.source.toolkit.fluxcd.io/v1
✔ helmreleases.helm.toolkit.fluxcd.io/v2
✔ helmrepositories.source.toolkit.fluxcd.io/v1
✔ kustomizations.kustomize.toolkit.fluxcd.io/v1
✔ ocirepositories.source.toolkit.fluxcd.io/v1beta2
✔ providers.notification.toolkit.fluxcd.io/v1beta3
✔ receivers.notification.toolkit.fluxcd.io/v1
✔ all checks passed

Git provider

GitHub

Container Registry provider

DockerHub

Additional context

No response

Code of Conduct

I agree to follow this project's Code of Conduct

After reviewing cmd/flux/check.go, I found that while it's possible to provide components as arguments, these arguments don’t appear to be considered during the check execution itself. The specified components are defined but never actually verified within the code logic:

flux2/cmd/flux/check.go

Lines 196 to 225 in 5350425

    
           func componentsCheck(ctx context.Context, kubeClient client.Client) bool { 
        
           	statusChecker, err := status.NewStatusCheckerWithClient(kubeClient, checkArgs.pollInterval, rootArgs.timeout, logger) 
        
           	if err != nil { 
        
           		return false 
        
           	} 
        
           	ok := true 
        
           	selector := client.MatchingLabels{manifestgen.PartOfLabelKey: manifestgen.PartOfLabelValue} 
        
           	var list v1.DeploymentList 
        
           	ns := *kubeconfigArgs.Namespace 
        
           	if err := kubeClient.List(ctx, &list, client.InNamespace(ns), selector); err == nil { 
        
           		if len(list.Items) == 0 { 
        
           			logger.Failuref("no controllers found in the '%s' namespace with the label selector '%s=%s'", 
        
           				ns, manifestgen.PartOfLabelKey, manifestgen.PartOfLabelValue) 
        
           			return false 
        
           		} 
        
           		for _, d := range list.Items { 
        
           			if ref, err := buildComponentObjectRefs(d.Name); err == nil { 
        
           				if err := statusChecker.Assess(ref...); err != nil { 
        
           					ok = false 
        
           				} 
        
           			} 
        
           			for _, c := range d.Spec.Template.Spec.Containers { 
        
           				logger.Actionf(c.Image) 
        
           			} 
        
           		} 
        
           	} 
        
           	return ok 
        
           }

If this is indeed unintended behavior and not by design, I’d be interested in working on a fix for this issue. Please let me know if further investigation is needed or if this could be opened for contribution.

	func componentsCheck(ctx context.Context, kubeClient client.Client) bool {
	statusChecker, err := status.NewStatusCheckerWithClient(kubeClient, checkArgs.pollInterval, rootArgs.timeout, logger)
	if err != nil {
	return false
	}

	ok := true
	selector := client.MatchingLabels{manifestgen.PartOfLabelKey: manifestgen.PartOfLabelValue}
	var list v1.DeploymentList
	ns := *kubeconfigArgs.Namespace
	if err := kubeClient.List(ctx, &list, client.InNamespace(ns), selector); err == nil {
	if len(list.Items) == 0 {
	logger.Failuref("no controllers found in the '%s' namespace with the label selector '%s=%s'",
	ns, manifestgen.PartOfLabelKey, manifestgen.PartOfLabelValue)
	return false
	}

	for _, d := range list.Items {
	if ref, err := buildComponentObjectRefs(d.Name); err == nil {
	if err := statusChecker.Assess(ref...); err != nil {
	ok = false
	}
	}
	for _, c := range d.Spec.Template.Spec.Containers {
	logger.Actionf(c.Image)
	}
	}
	}
	return ok
	}