kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #3689 from timothysc/conformance_guidance 

Update recommendations for tests that don't meet criteria
This commit is contained in:
Kubernetes Prow Robot 2019-05-08 15:00:50 -07:00 committed by GitHub
parent fc89fc3476 d3a393ebe7
commit 5d4d2caf3a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 9 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
contributors/devel/sig-architecture/conformance-tests.md
View File

@ -63,12 +63,20 @@ Examples of features which are not currently eligible for conformance tests:
- cloud-provider-specific features, eg: GCE monitoring, S3 Bucketing, etc. - cloud-provider-specific features, eg: GCE monitoring, S3 Bucketing, etc.
- anything that requires a non-default admission plugin - anything that requires a non-default admission plugin
Examples of tests which are not eligible for promotion to conformance: Conformance tests are intended to be stable and backwards compatible according to
the standard API deprecation policies. Therefore any test that relies on specific
output that is not subject to the deprecation policy cannot be promoted to conformance.
Examples of tests which are not eligible to conformance:
- anything that checks specific Events are generated, as we make no guarantees - anything that checks specific Events are generated, as we make no guarantees
about the contents of events, nor their delivery about the contents of events, nor their delivery
- If a test depends on events it is recommended to change the test to
use an informer pattern and watch specific resource changes instead.
- anything that checks optional Condition fields, such as Reason or Message, as - anything that checks optional Condition fields, such as Reason or Message, as
these may change over time (however it is reasonable to verify these fields these may change over time (however it is reasonable to verify these fields
exist or are non-empty) exist or are non-empty)
- If the test is checking for specific conditions or reasons, it is considered
overly specific and it is recommended to simply look for pass/failure criteria
where possible, and output the condition/reason for debugging purposes only.
Examples of areas we may want to relax these requirements once we have a Examples of areas we may want to relax these requirements once we have a
sufficient corpus of tests that define out of the box functionality in all sufficient corpus of tests that define out of the box functionality in all