Add script to verify feature gates cleanup #131712
Conversation
|
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The 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. |
|
Hi @simoncampion. Thanks for your PR. I'm waiting for a kubernetes 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-sigs/prow repository. |
|
/sig api-machinery |
|
thank you @simoncampion for raising the PR! |
Feature gate code that has been locked to default at version X.Y can be cleaned up at version X.Y+4. This commit adds a script that verifies that such unnecessary feature gate code was cleaned up. It is intended to be run as a release-blocking test.
d062aad to
b5bc58c
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: simoncampion The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Makes sense 👍 I removed the logic in the script and instead implemented the check in |
| @@ -266,6 +291,52 @@ func verifyFeatureRemoval(featureList []featureInfo, baseFeatureList []featureIn | |||
| return nil | |||
| } | |||
|
|
|||
| // getFeaturesAndVerifyCleanup gets the feature list from the code base and verifies that | |||
| // no feature gates need to be cleaned up. | |||
| func getFeaturesAndVerifyCleanup(rootPath string) error { | |||
There was a problem hiding this comment.
since this command will only be run in CI, I think we can just use the yaml file to get features.
There was a problem hiding this comment.
I see. I changed it to get features from the YAML file.
|
/ok-to-test |
|
/retest |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Feature gate code that has been locked to default at version X.Y is required to stay in the code base until version X.Y+3 for version emulation, but can be cleaned up afterwards. This commit adds a script checking whether any feature gates require cleanup. It is intended to be run as a release-blocking test.
Which issue(s) this PR fixes:
Fixes #130759
Special notes for your reviewer:
There are a few things I need your input on:
Are there defined requirements for feature gate cleanup across major versions? Currently, the script errors if the current major version differs from the major version at which a feature gate was locked.
The issue requires that this script is run in a release-blocking test. So, we need to run
make verify WHAT=featuregates-cleanupin release pipelines. Should I open a PR to add a new job here once this PR is merged? I'm unsure that's the right place because all jobs there are E2E tests.The script depends on
yq. As far as I see, some but not all CI images includeyq. Is it okay to depend onyq? If not, it'd be possible to do the YAML parsing in pure Bash, but that'd be brittle and hard to maintain. Instead, in that case, I'd suggest I rewrite the script in Python, or add the logic to the existingcompatibility_lifecycletool, like this:Thanks for your help!
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: