fix(deploy): skip kubectl flag validation for configs with no deploy section

[aniskhan001]

What changed

When using skaffold apply with a multi-config project where a dependency config has no deploy section (e.g. it only provides resourceSelector), the default deployer would incorrectly treat the zero-value KubectlFlags{} as conflicting with the parent config's kubectl flags (e.g. --server-side).

Root Cause

In getDefaultDeployer, validateKubectlFlags was called for every pipeline config regardless of whether d.KubectlDeploy was nil. A nil KubectlDeploy produced a zero-value KubectlFlags{} that did not contain the parent's flags, causing a false conflict error.

Fix

Moved the validateKubectlFlags call and the DefaultNamespace conflict check inside the existing if d.KubectlDeploy != nil block. Configs without a kubectl deploy section are now skipped entirely.

Testing

• Added regression test: TestGetDefaultDeployer/parent_config_with_kubectl_flags_and_dependency_config_with_no_deploy_section_should_not_conflict in pkg/skaffold/runner/deployer_test.go
• All existing TestGetDefaultDeployer subtests pass

Fixes #10071

[gemini-code-assist]

Code Review

This pull request resolves an issue where dependency configurations without a deploy section were incorrectly treated as having conflicting kubectl deploy flags. The fix refactors getDefaultDeployer to only process kubectl flags and namespaces when d.KubectlDeploy is not nil, and includes a regression test. Feedback on the changes suggests a performance optimization in deployer.go to reference &d.KubectlDeploy.Flags directly, which avoids copying the struct to a block-local variable and prevents unnecessary heap allocations.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.