Tatsuhiro Tsujikawa 9abcedf467 Restore the ability to kubectl apply --prune without -n flag ... Before https://github.com/kubernetes/kubernetes/pull/83084, `kubectl apply --prune` can prune resources in all namespaces specified in config files. After that PR got merged, only a single namespace is considered for pruning. It is OK if namespace is explicitly specified by --namespace option, but what the PR does is use the default namespace (or from kubeconfig) if not overridden by command line flag. That breaks the existing usage of `kubectl apply --prune` without --namespace option. If --namespace is not used, there is no error, and no one notices this issue unless they actually check that pruning happens. This issue also prevents resources in multiple namespaces in config file from being pruned. kubectl 1.16 does not have this bug. Let's see the difference between kubectl 1.16 and kubectl 1.17. Suppose the following config file: ```yaml apiVersion: v1 kind: ConfigMap metadata: creationTimestamp: null name: foo namespace: a labels: pl: foo data: foo: bar Kubernetes-commit: 4e644d0b4842c851b18d846d1ce56ef5c73204a1		2020-03-27 01:11:36 +00:00
..
apply.go	Even with build error, kubectl apply should apply all valid resources	2020-04-03 19:50:25 -07:00
apply_edit_last_applied.go	Move pkg/kubectl/cmd/{command} to staging	2019-08-01 11:01:40 -07:00
apply_set_last_applied.go	Use --dry-run=client,server in kubectl.	2020-01-30 20:23:33 -05:00
apply_test.go	Support DryRun in cli-runtime REST Helper.	2019-12-18 22:00:34 -05:00
apply_view_last_applied.go	Move pkg/kubectl/cmd/{command} to staging	2019-08-01 11:01:40 -07:00
patcher.go	Ensure diff doesn't persist patches	2020-04-02 17:14:17 -04:00
prune.go	Restore the ability to kubectl apply --prune without -n flag	2020-03-27 01:11:36 +00:00