Add tests that kube types added as CRDs show the expected columns - Githubissues

kcp-dev / kcp

Kubernetes-like control planes for form-factors and use-cases beyond Kubernetes and container workloads.

https://kcp.io

Apache License 2.0

2.38k stars 383 forks source link

Add tests that kube types added as CRDs show the expected columns #1003

Closed ncdc closed 5 months ago

ncdc commented 2 years ago

We have custom code that makes sure that when CRDs are added for built-in kube types (deployments, services, pods, etc.), kubectl get <resource> returns the same columns as the user expects, by replacing the CRD table converter with the go code for the printers for the internal built-in types. We should add tests that ensure we don't regress.

Example - deployments - if we regress:

NAME    AGE
kuard   104m

This is what's expected:

NAME    READY   UP-TO-DATE   AVAILABLE   AGE
kuard   0/1     1            0           3s

These can be both API and CLI tests.

cc @kasturinarra

kasturinarra commented 2 years ago

ACK & we will add these tests, thanks !!

kasturinarra commented 2 years ago

Added a test case in polarion and here is the link for the same https://polarion.engineering.redhat.com/polarion/#/project/OSE/workitem?id=OCP-50878

kasturinarra commented 2 years ago

@ncdc one question for the API tests would you want me to test the CRD additionalPrinterColumns ??

oc get crd catalogsources.operators.coreos.com -o yaml ...

additionalPrinterColumns:
- description: The pretty name of the catalog jsonPath: .spec.displayName name: Display type: string
- description: The type of the catalog jsonPath: .spec.sourceType name: Type type: string
- description: The publisher of the catalog jsonPath: .spec.publisher name: Publisher type: string
- jsonPath: .metadata.creationTimestamp name: Age type: date

ncdc commented 2 years ago

It's fine to test them, but it's not related to this code/issue

kasturinarra commented 2 years ago

It's fine to test them, but it's not related to this code/issue

okay, i have added CLI test in polarion to ensure we get all the right columns , but how do we cover the api test ?

ncdc commented 2 years ago

For all built in Kubernetes types that someone could import as a CRD, verify that kubectl get output between kcp & kube matches.

kasturinarra commented 2 years ago

For all built in Kubernetes types that someone could import as a CRD, verify that kubectl get output between kcp & kube matches.

ah, okay, thanks !!

kcp-ci-bot commented 7 months ago

Issues go stale after 90d of inactivity. After a furter 30 days, they will turn rotten. Mark the issue as fresh with /remove-lifecycle stale.

If this issue is safe to close now please do so with /close.

/lifecycle stale

kcp-ci-bot commented 6 months ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

kcp-ci-bot commented 5 months ago

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

/close

kcp-ci-bot commented 5 months ago

@kcp-ci-bot: Closing this issue.

In response to [this](https://github.com/kcp-dev/kcp/issues/1003#issuecomment-2162422824): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.