To avoid this kind of thing: #16521. This was an issue in which our test/release infra needed to change, and we had to cherrypick a bunch of stuff back into the release-1.0 branch, because we rely on release infra inside that branch.

Instead, we should have separate release infra (probably in contrib) that drives the release process, and relies on a clearly-defined interface with the build infra, (e.g. run make release, and expect all artifacts to exist in _output).

Specific action items:

• Define a clear contract between build and release
  • Straw man proposal: build logic is invoked with a single command, (i.e. make release or something similar,) and promises to put all artifacts for release into a specific local directory that the releasing logic can then push
• Factor out all kube::release::... logic from build/common.sh, and move all push-... scripts to release/
  • We might want to move all of the releasing infrastructure to kubernetes/contrib, but that opens up issues of how to deploy to a cluster (see next item)
• Figure out how to handle pushing to GCS from the build logic (for deployment) and how that can play nice with our releasing logic (cc @mikedanese regarding your work on deployment)
• Figure out what to do with build/release.sh
• Factor out versioning logic from push-... scripts, cut-official-release.sh, and build-official-release.sh