-
Notifications
You must be signed in to change notification settings - Fork 244
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
Fix: Panic when running odo list namespaces without an active Kubernetes context #6367
Fix: Panic when running odo list namespaces without an active Kubernetes context #6367
Conversation
✅ Deploy Preview for odo-docusaurus-preview canceled.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but can you add a simple integration test case for this in cmd_namespace_test
?
I think this should be do-able now that we can put a nocluster
label on Ginkgo tests. Labelling the test spec with this label should make the spec run without an active Kubernetes context.
Signed-off-by: Parthvi Vala <[email protected]>
62044cb
to
c71eb51
Compare
…works even when cluster is inaccessible
/retest |
@@ -86,7 +86,7 @@ func NewCmdBinding(name, fullName string) *cobra.Command { | |||
}, | |||
} | |||
bindingCmd.Flags().String(backend.FLAG_NAME, "", "Name of the Binding to create") | |||
clientset.Add(bindingCmd, clientset.BINDING, clientset.FILESYSTEM) | |||
clientset.Add(bindingCmd, clientset.REMOVE_BINDING, clientset.FILESYSTEM) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not comfortable with this solution. If the problem is to define if KUBERNETES must be nullable or not for a specific command, we need to find a way to specify this directly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Intuitively, I think KUBERNETES and KUBERNETES_NULLABLE should be mutually exclusive, but in cases where both are needed, we could only return an error if KUBERNETES_NULLABLE was not defined. WDYT?
I've tried an alternate solution here which seems to be working fine: 3a88ffe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@valaparthvi Yes, that seems a very good idea to me
3a88ffe
to
7269c0a
Compare
/retest |
Signed-off-by: Parthvi Vala <[email protected]>
7269c0a
to
48bd771
Compare
Kudos, SonarCloud Quality Gate passed!
|
/override OpenShift-Integration-tests/OpenShift-Integration-tests
|
@feloy: Overrode contexts on behalf of feloy: OpenShift-Integration-tests/OpenShift-Integration-tests In response to this:
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/test-infra repository. |
/override ci/prow/v4.11-integration-e2e |
@feloy: Overrode contexts on behalf of feloy: ci/prow/v4.11-integration-e2e In response to this:
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/test-infra repository. |
What type of PR is this:
/kind bug
What does this PR do / why we need it:
Which issue(s) this PR fixes:
Fixes #6316
PR acceptance criteria:
Unit test
Integration test
Documentation
How to test changes / Special notes to the reviewer:
odo list namespace
no longer panics, instead throws an appropriate error.odo remove binding
still works when the cluster is inaccessible. The test for this was failing when a new REMOVE_BINDING dep was not added. Commit f542b22 fixes that.