-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
e2e-tests.md: update description of labels #7824
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: pohly 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 |
|
||
# Run tests in parallel, skip any that must be run serially and keep the test namespace if test failed | ||
GINKGO_PARALLEL=y kubetest --test --test_args="--ginkgo.skip=\[Serial\] --delete-namespace-on-failure=false" | ||
GINKGO_PARALLEL=y kubetest --test --test_args='--ginkgo.label-filter=!Serial --delete-namespace-on-failure=false' |
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.
!Serial
is special in an interactive bash when included in double quotes. Therefore I switched to single quotes here and (for the sake of consistency) also above.
/lgtm /assign @danwinship @BenTheElder @SergeyKanzhelev |
/hold The intent is that adding tests with only a |
do we want to merge and do the modifications or do the modifications and then merge based on the feedback? |
/lgtm this brings a lot of progress |
This explains how to use --filter-label (possible since Kubernetes 1.29) and clarifies the usage of feature gate labels.
As the text stands right now, it says (or implies?) that "annotating a test which depends only on a feature gate with only We could merge it now if we added a comment saying that this is the goal but that "as a stop-gap solution, tests which depend on a feature gate also need to be annotated with a feature". It's probably worth explaining that and merge, because then the rest of the new documentation, in particular the part about label filtering, is what people will see when they check the master branch. Agreed? |
While we now have the ability to support tests properly which only depend on alpha or beta feature gates, we still haven't migrated all jobs. So for now, developers still need to follow the old practice of tagging such tests with both [Feature] and [FeatureGate].
@aojea: I added such an explanation to the Alpha/Beta section. This is therefore ready for merging. |
/hold cancel |
/lgtm lazy consensus |
Sorry, I had already lifted the hold because the reason there no longer applied. I hadn't considered that I self-approve in this repo. Let's give @danwinship @BenTheElder @SergeyKanzhelev time until Wednesday to comment and suggest further changes before I send a mail to dev@kubernetes.io about this. |
it got merged :) ... we can always amend changes or modify, is not that this is set in stone |
Yes, that's what I meant, too. |
This explains how to use --filter-label (possible since Kubernetes 1.29) and clarifies the usage of feature gate labels.
The intent is that adding tests with only a
FeatureGate
label is sufficient. Before we allow such tests, we have to--label-filter
to skip tests with special requirements including alpha/beta feature gates, see convert some jobs to Ginkgo --label-filter test-infra#32648 - can be done gradually. Once complete, tagging of some tests can become simpler.That is because the "traditional"
SKIP=\[Features:.+\]
will no longer match tests which have[FeatureGate:Foo] [Alpha]
, as explained in kubernetes/kubernetes#124350.