Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Skaffold doesn't track default namespace when not explicitly provided #6242

Closed
nkubala opened this issue Jul 19, 2021 · 2 comments · Fixed by #6241
Closed

Skaffold doesn't track default namespace when not explicitly provided #6242

nkubala opened this issue Jul 19, 2021 · 2 comments · Fixed by #6241
Assignees
Labels
kind/bug Something isn't working priority/p0 Highest priority. We are actively looking at delivering it.

Comments

@nkubala
Copy link
Contributor

nkubala commented Jul 19, 2021

Expected behavior

Skaffold does normal logging, port forwarding, syncing, etc. when deploying to a default namespace (aka no namespace provided)

Actual behavior

If no namespace is provided, Skaffold does not track the default namespace. As a result, any component that relies on a PodSelector to retrieve its resources to operate on does not function. This seems to only apply to kustomize and helm projects, not kubectl.

Information

  • Skaffold version: v1.28.0

Steps to reproduce the behavior

Run skaffold dev in our examples/getting-started-kustomize.

More Info

#6170 moved the tracking of the deployed namespaces into the Deployer object. However, it inadvertently removed some pre-processing logic to retrieve the initial namespaces when creating the Deployer. Since the empty string ("") is interpreted as the "default" namespace when deploying to Kubernetes, this meant that all projects deploying to this namespace were not being considered for logging, port forwarding, or any other component that uses a podSelector to retrieve its resources.

@nkubala nkubala self-assigned this Jul 19, 2021
@nkubala nkubala added kind/bug Something isn't working priority/p0 Highest priority. We are actively looking at delivering it. labels Jul 19, 2021
@briandealwis briandealwis reopened this Jul 20, 2021
@briandealwis
Copy link
Member

Re-opening: will close once v1.28.1 is released.

@nkubala
Copy link
Contributor Author

nkubala commented Jul 20, 2021

v1.28.1 has now been published. Closing this issue now

@nkubala nkubala closed this as completed Jul 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working priority/p0 Highest priority. We are actively looking at delivering it.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants