List revisions for a given service #194
Conversation
knative-prow-robot
added
the
needs-ok-to-test
|
Hi @navidshaikh. Thanks for your PR. I'm waiting for a knative member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
knative-prow-robot
added
the
size/L
|
/ok-to-test |
|
@navidshaikh: Cannot trigger testing until a trusted user reviews the PR and leaves an 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. |
|
/ok-to-test |
knative-prow-robot
added
ok-to-test
|
The following is the coverage report on pkg/.
|
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: navidshaikh, sixolet The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
knative-prow-robot
added
the
approved
| return err | ||
| } | ||
| listOptions.LabelSelector = labels.Set( | ||
| map[string]string{serving.ConfigurationLabelKey: service}).String() |
There was a problem hiding this comment.
Shouldn't this be serving.ServiceLabelKey ? Don't really see how this is tested in the tests, too ...
There was a problem hiding this comment.
Hmm, I checked an actual revision and both the keys in labels are holding service name
"labels": {
"serving.knative.dev/configuration": "svc1",
"serving.knative.dev/configurationGeneration": "1",
"serving.knative.dev/service": "svc1"
},
@rhuss : I will need to check among 2 labels, which one we should filter against.
in tests here.
There was a problem hiding this comment.
But isn't the service label the authorative answer for which revision belongs to which service and the configuration is just (by accident) named like the service because it has been created implicitely ? Or does the configuration alway be named like the service ? (I don't think so)
* Lists revisions for a given service Fixes knative#127 * Adds unit tests for listing revisions of a service * Adds integration tests for listing revisions of a service * Updates docs for listing revisions of a service * Updates vendor/modules.txt
* Use hack/install.sh from serverless-operator repo - To configure serverless-operator, knative-serving and dependencies. - Unset OPENSHIFT_BUILD_NAMESPACE env var as its used by serverless-operator in its own CI to use the CI built images for k-s-o and k-o-i, client uses pre-built images * Rename install_serverless_operator to install_serverless
* Install netbase with prow * update comment
Fixes #127