Add early cluster validation to prevent wasted build time in func deploy

[RayyanSeliya]

Changes

• 🐛 Add early cluster validation to prevent wasted build time in func deploy
• 🧹 Improve error messages for cluster connection failures with actionable guidance

What Changed

func deploy now validates Kubernetes cluster connectivity before starting the container build process, preventing wasted time when the cluster is inaccessible.

Before:

• Built container image first (2-5 minutes)
• Then failed with confusing errors like "invalid run-image" or "context canceled"
• Different errors depending on whether --build=false was used

After:

• Validates cluster connection immediately (< 5 seconds)
• Fails fast with clear, specific error messages
• Consistent behavior regardless of build flags
• Provides actionable guidance for each error type

Implementation

Added 2-layer error handling:

• Layer 1 (pkg/functions/errors.go): Technical errors (ErrInvalidKubeconfig, ErrClusterNotAccessible)
• Layer 2 (cmd/deploy.go): User-friendly CLI messages with examples

Detects three distinct error scenarios:

1. Invalid kubeconfig file path
2. Empty/no cluster configuration
3. Cluster unreachable (network, auth, down, etc.)

Testing

Tested all combinations:

• ✅ Invalid KUBECONFIG path (with/without build flags)
• ✅ Empty kubeconfig (with/without build flags)
• ✅ Unreachable cluster (with/without build flags)
• ✅ Cluster stopped after configuration (network error)
• ✅ Valid cluster with kind (success path)
• ✅ Unit tests pass (TestDeploy_ConfigPrecedence, etc.)

/kind bug

Fixes #3116

Release Note

`func deploy` now validates cluster connectivity before building, providing immediate feedback with clear error messages instead of wasting time on builds that will fail deployment.

[knative-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: RayyanSeliya
Once this PR has been reviewed and has the lgtm label, please assign jrangelramos for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[knative-prow]

Hi @RayyanSeliya. Thanks for your PR.

I'm waiting for a github.com member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[codecov]

Codecov Report

❌ Patch coverage is 26.13636% with 65 lines in your changes missing coverage. Please review.
✅ Project coverage is 59.15%. Comparing base (5093bfb) to head (02c38ab).
⚠️ Report is 11 commits behind head on main.

Files with missing lines	Patch %	Lines
cmd/deploy.go	26.13%	63 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3117      +/-   ##
==========================================
+ Coverage   58.33%   59.15%   +0.81%     
==========================================
  Files         134      134              
  Lines       17364    17512     +148     
==========================================
+ Hits        10130    10359     +229     
+ Misses       6293     6184     -109     
- Partials      941      969      +28     

Flag	Coverage Δ
e2e-tests	40.43% <12.50%> (+1.48%)	⬆️
integration-tests	54.04% <26.13%> (+1.84%)	⬆️
unit-tests	46.16% <26.13%> (-0.06%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gauron99]

/ok-to-test

[matejvasek]

I would prefer if we called our k8s.NewKubernetesClientset() and checked the err return value.
Also I do not like making the code "test aware". Could we think of something better?

[RayyanSeliya]

Thxs for the feedback @matejvasek ! I've updated it to use k8s.NewKubernetesClientset() and check the error as you suggested. The /testdata/ check follows Go's convention for test fixtures , it catches cases where tests use stale kubeconfig paths. The .example.com check skips API calls for test/example clusters (RFC 2606 reserved domain).

[gauron99]

Im not much of a fan of this implementation... its still "test aware" as Matej said - with those literal strings and constants. Also there has to be some better way to implement this 🤔
Maybe as a method of client Instance (in pkg/functions/client.go) ? Instance has its method "CurrentState" or "State" or "Available" or something like this?
@lkingland @matejvasek

[RayyanSeliya]

Im not much of a fan of this implementation... its still "test aware" as Matej said - with those literal strings and constants. Also there has to be some better way to implement this 🤔 Maybe as a method of client Instance (in pkg/functions/client.go) ? Instance has its method "CurrentState" or "State" or "Available" or something like this? @lkingland @matejvasek

@gauron99 Good point about the client architecture! I checked pkg/functions/client.go and saw it already has methods like Deploy(), Build(), etc.

I'm thinking we could add:

func (c *Client) ClusterAvailable(ctx context.Context) error

Then just call it before building. Tests would naturally skip it since they use NewTestClient() with mocks.

The challenge is timing - we currently validate before creating the client (line 423 vs line 462 in cmd/deploy.go's runDeploy()). We'd need to either:

1. Create the client earlier, or
2. Make it a standalone function like functions.ValidateCluster()

Which direction makes more sense for the existing code? Don't want to refactor the way which is not feasible ..!

@lkingland @matejvasek