Save docker image tarfiles in _output/release-images/$arch/#47939
Save docker image tarfiles in _output/release-images/$arch/#47939k8s-github-robot merged 1 commit intokubernetes:masterfrom
Conversation
|
(building hyperkube is still pretty slow, btw. I wonder if we can make progress on #42589 for 1.8?) |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ixdy Associated issue: 1400 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
build/lib/release.sh
Outdated
| @@ -26,6 +26,13 @@ | |||
| # This is where the final release artifacts are created locally | |||
| readonly RELEASE_STAGE="${LOCAL_OUTPUT_ROOT}/release-stage" | |||
| readonly RELEASE_DIR="${LOCAL_OUTPUT_ROOT}/release-tars" | |||
There was a problem hiding this comment.
This dir now seems named inconsistently; following the other two it should be RELEASE_TARS
build/lib/release.sh
Outdated
| function kube::release::package_tarballs() { | ||
| # Clean out any old releases | ||
| rm -rf "${RELEASE_DIR}" | ||
| rm -rf "${RELEASE_DIR}" "${RELEASE_IMAGES}" |
There was a problem hiding this comment.
Why don't we delete $RELEASE_STAGE here? Is that cleared out elsewhere?
There was a problem hiding this comment.
the various package_*_tarballs functions do this, but a good suggestion regardless. done.
| echo "${docker_tag}" > ${binary_dir}/${binary_name}.docker_tag | ||
|
|
||
| rm -rf ${docker_build_path} | ||
| ln "${binary_dir}/${binary_name}.tar" "${images_dir}/" |
There was a problem hiding this comment.
are you using ln instead of cp for efficiency?
There was a problem hiding this comment.
yeah, the docker tarfiles are pretty large. for amd64 alone, ~576M for everything except hyperkube, and another 582M for hyperkube. across 5 architectures that seemed like a lot.
|
please squash, then lgtm |
Additionally, add option KUBE_BUILD_HYPERKUBE to build hyperkube outside of the release flow.
|
/retest |
|
Automatic merge from submit-queue (batch tested with PRs 47650, 47936, 47939, 47986, 48006) |
Automatic merge from submit-queue (batch tested with PRs 49043, 49001, 49057, 49066, 48102) Always use gcr.io/google_containers for side-loaded Docker images **What this PR does / why we need it**: #45391 changed the behavior for what registry we use in the sideloaded docker images tarfiles shipped with releases. As a result of that change, if `KUBE_DOCKER_REGISTRY` is set to anything other than `gcr.io/google_containers`, clusters will fail to start on GCE (and other places where the side-loaded images are used). This PR reverts that change in behavior, which I believe was unintentional; we'll always use `gcr.io/google_containers` for the docker image tarfiles, but will tag the images with `$KUBE_DOCKER_REGISTRY` if different. Also, I'm fixing a small bug in variable names that I introduced in #47939. Note that with recent changes here and in the release repo, we don't even need to tag with `KUBE_DOCKER_REGISTRY` and `KUBE_DOCKER_IMAGE_TAG`, but that's a more extensive change, and this smaller fix is more suitable for cherry-picking to 1.7. **Release note**: ```release-note NONE ``` /release-note-none /sig release /assign @david-mcmahon
|
@ixdy I see this is only in 1.8+. How do we feel about backporting it to support all active branches? |
Additionally, add option
KUBE_BUILD_HYPERKUBEto build hyperkubeoutside of the release flow.
What this PR does / why we need it: Saves all of the docker tarfiles in a separate directory that the release scripts can use to push to a docker registry. This is easier than trying to guess which images should be pushed from the local docker engine, and supports work in kubernetes/test-infra#1400.
If we eventually use this for the official release workflow (
anago) this may prevent something like #47307 from happening again.Release note:
/release-note-none
/assign @luxas @david-mcmahon
cc @madhusudancs @roberthbailey