Deprecate google-hosted kubernetes-build jobs

[spiffxp]

Part of #18549 (more specifically part of #19483)

Now that all release-blocking jobs use artifacts stored in community-owned gs://k8s-release-dev (ref: #20885), it's time to call the jobs that produce those artifacts release-blocking, and demote the jobs that write to gs://kubernetes-release-dev as release-informing.

Deprecate jobs that write to gs://kuebrnetes-release-dev by:

• appending deprecated to their job name and testgrid tab name
• moving from release-blocking to release-informing

Promote jobs that write to gs://k8s-release-dev by:

• removing canary from their job name and testgrid tab name
• moving from release-informing to release-blocking
• removing from sig-testing-canaries

/hold
This is a "breaking" change that will split job history across the rename boundary since tools like testgrid and kettle don't understand the concept of job renames.

Would like consensus from SIG Release subprojects

[spiffxp]

FYI @kubernetes/release-engineering @kubernetes/ci-signal @kubernetes/release-team-leads

[hasheddan]

I'm very happy to see this change, thanks @spiffxp! My one concern here is that there are still some critical components (such as dl.k8s.io) that utilize the builds pushed to the old infra. Do we feel good about making this change before all consumers have moved over?

[justaugustus]

For SIG Release and associated subprojects:
/lgtm
/approve

My one concern here is that there are still some critical components (such as dl.k8s.io) that utilize the builds pushed to the old infra. Do we feel good about making this change before all consumers have moved over?

Discussed and approved at today's SIG Release meeting.

Two things to note:

1. We're deprecating the jobs but not removing them here, so there should be no impact for dl.k8s.io consumers
2. We're going to lose job history (or rather, job history will move to a different place for new runs), so it's better to do this sooner rather than later

Will leave @hasheddan to lifting the hold.

[hasheddan]

/lgtm
/hold cancel

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: hasheddan, justaugustus, spiffxp

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:

• config/jobs/kubernetes/sig-release/OWNERS [hasheddan,justaugustus,spiffxp]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

@spiffxp: Updated the job-config configmap in namespace default at cluster test-infra-trusted using the following files:

• key kubernetes-builds.yaml using file config/jobs/kubernetes/sig-release/kubernetes-builds.yaml
• key 1.18.yaml using file config/jobs/kubernetes/sig-release/release-branch-jobs/1.18.yaml
• key 1.19.yaml using file config/jobs/kubernetes/sig-release/release-branch-jobs/1.19.yaml
• key 1.20.yaml using file config/jobs/kubernetes/sig-release/release-branch-jobs/1.20.yaml

In response to this:

Part of #18549 (more specifically part of #19483)

Now that all release-blocking jobs use artifacts stored in community-owned gs://k8s-release-dev (ref: #20885), it's time to call the jobs that produce those artifacts release-blocking, and demote the jobs that write to gs://kubernetes-release-dev as release-informing.

Deprecate jobs that write to gs://kuebrnetes-release-dev by:

• appending deprecated to their job name and testgrid tab name
• moving from release-blocking to release-informing

Promote jobs that write to gs://k8s-release-dev by:

• removing canary from their job name and testgrid tab name
• moving from release-informing to release-blocking
• removing from sig-testing-canaries

/hold
This is a "breaking" change that will split job history across the rename boundary since tools like testgrid and kettle don't understand the concept of job renames.

Would like consensus from SIG Release subprojects

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.

[spiffxp]

Do we feel good about making this change before all consumers have moved over?

FWIW I took a quick look at what builds are present where: https://gist.github.com/spiffxp/9a339a93ae889d1378e6f2259a733895

The main point, I think:

total  builds (in either bucket)       : 776
common builds (in both buckets)        : 661
only in gs://kubernetes-release-dev/ci : 95
only in gs://k8s-release-dev/ci        : 20

It's not perfect, but looking at the actual builds that are missing, it's pretty good. Mostly flakes in both directions.

We're deprecating the jobs but not removing them here, so there should be no impact for dl.k8s.io consumers

Exactly. I would like to switch dl.k8s.io/ci to point to k8s-release-dev at some point, but not until we have a better handle on ensuring build parity between the buckets (maybe using STS to sync, etc.)