-
Notifications
You must be signed in to change notification settings - Fork 194
OTA-1010: Add a new version of GetImplicitlyEnabledCapabilities #1133
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
base: main
Are you sure you want to change the base?
OTA-1010: Add a new version of GetImplicitlyEnabledCapabilities #1133
Conversation
@hongkailiu: This pull request references OTA-1010 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.19.0" version, but no target version was set. 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 openshift-eng/jira-lifecycle-plugin repository. |
fd5df0e
to
bb6b61b
Compare
@hongkailiu: This pull request references OTA-1010 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.19.0" version, but no target version was set. 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 openshift-eng/jira-lifecycle-plugin repository. |
@hongkailiu: This pull request references OTA-1010 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.19.0" version, but no target version was set. 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 openshift-eng/jira-lifecycle-plugin repository. |
@hongkailiu: This pull request references OTA-1010 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.19.0" version, but no target version was set. 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 openshift-eng/jira-lifecycle-plugin repository. |
bb6b61b
to
eb37012
Compare
eb37012
to
79916aa
Compare
/hold Will rebase after #1159 gets in. |
/test images |
79916aa
to
c4bb400
Compare
/retest-required |
c4bb400
to
9cdc271
Compare
/retest-required |
/test okd-scos-e2e-aws-ovn |
1 similar comment
/test okd-scos-e2e-aws-ovn |
@hongkailiu: The following test failed, say
Full PR test history. Your PR dashboard. 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-sigs/prow repository. I understand the commands that are listed here. |
/uncc |
// In other words, whether, or not the cluster version operator reconcile that manifest on the cluster. | ||
// The two sets of manifests are respectively from the release that is currently running on the cluster and | ||
// from the release that the cluster is updated to. | ||
func GetImplicitlyEnabledCapabilities( |
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.
How do we test this implementation is:
- Correct?
- Equivalent to the deleted
GetImplicitlyEnabledCapabilities
?
For (1) I assume that we'll need tests once we lift it to o/library-go so why not write them right away?
For (2) I wonder if if would be proper to keep the old implementation for a while, implement a test that shows that the two implementations are equivalent (same inputs -> same outputs) and only delete the code (and the equivalence test) once the o/library-go implementation fully settles?
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.
For (2): There are tests for it already.
func TestGetImplicitlyEnabledCapabilities(t *testing.T) { |
At least, from those tests point of view, they are equivalent.
For (1):
I moved over the unit tests from (2) to https://github.com/openshift/library-go/pull/1908/files with modifications
- to fit the new function signature (added a new arg
manifestInclusionConfiguration
), and - to avoid copying testdata/payloadcapabilitytest there and convincing
o/lib
approvers that it OK to do it .
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.
Ah okay, we have tests on the payload-level GetImplicitlyEnabledCapabilities
which calls the new function, good!
then
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hongkailiu, petr-muller 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 |
Add a new version of
GetImplicitlyEnabledCapabilities
that is going to be lifted to library-go.At the moment, we keep the function here temporarily to ensure it works for CVO.
We should also keep it in mind once it goes to library-go, the function should be also usable for oc-cli, e.g., the extract command.