-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
[WIP] releng: Remove configs for k8s-beta jobs / add k8s-stable4 variants #26028
Conversation
For years, we've had issues with the `k8s-beta` generic version marker. There are a few scenarios... During the dev cycle: - beta should not exist, but actually points to the previous release After a beta release: - beta should exist, but: 1. no one really updated this manually 2. the branch cuts and job creation happens at the RC stage After an RC release (branch cut): - beta should have already existed - beta represents the RC version after branch job creation After an official release: - beta should not exist, but actually points to the previous release None of these scenarios are acceptable, so it's time to remove this marker. Generated jobs that reference `beta` in their name have already been using version-specific markers for multiple releases, so this has minimal impact. Here we instead add a `k8s-stable4` marker, to provide a version marker for a release branch that is in maintenance mode/soon-to-be EOL-ed. Adding a marker at the end of the set means we no longer have to consider moving the `k8s-beta` marker during a release cycle. Signed-off-by: Stephen Augustus <[email protected]>
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: justaugustus 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 |
/hold this still needs job regeneration and we should land the release branch jobs first |
@justaugustus: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
@justaugustus: PR needs rebase. 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. |
We should resurrect this at some point, but for now: |
@justaugustus: Closed this PR. 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. |
(Continuation of #26015.)
For years, we've had issues with the
k8s-beta
generic versionmarker.
There are a few scenarios...
During the dev cycle:
After a beta release:
After an RC release (branch cut):
After an official release:
None of these scenarios are acceptable, so it's time to remove this
marker. Generated jobs that reference
beta
in their name havealready been using version-specific markers for multiple releases, so
this has minimal impact.
Here we instead add a
k8s-stable4
marker, to provide a versionmarker for a release branch that is in maintenance mode/soon-to-be
EOL-ed.
Adding a marker at the end of the set means we no longer have to
consider moving the
k8s-beta
marker during a release cycle.Signed-off-by: Stephen Augustus [email protected]
/assign @puerco @Verolop @palnabarun
cc: @kubernetes/release-engineering