Skip to content
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.

Sign up for GitHub

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

add new push-node.sh that uses pre-compiled upstream releases #3825

Merged
merged 1 commit into from
Dec 13, 2024
Merged

add new push-node.sh that uses pre-compiled upstream releases #3825

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
63 changes: 63 additions & 0 deletions hack/release/push-node.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,63 @@
#!/usr/bin/env bash
# Copyright 2024 The Kubernetes Authors.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

# this script replaces hack/release/build/push-node.sh for Kubernetes v1.31+
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(it started as a copy, I added VERSION="$1" and then ripped out all of the kubernetes build and version detection bits in favor of passing this as the kind build node-image argument)

# usage: push-node.sh v1.32.0

set -o errexit -o nounset -o pipefail

REGISTRY="${REGISTRY:-gcr.io/k8s-staging-kind}"
IMAGE_NAME="${IMAGE_NAME:-node}"

# cd to the repo root
REPO_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/../.." &> /dev/null && pwd -P)"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we always assume we will be in a git repo and not running on a downloaded copy of the source? If so, might be slightly safer to use git rev-parse --show-toplevel.

Copy link
Member Author

@BenTheElder BenTheElder Dec 13, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This approach is safe unless we move the script relative to the repo root, we use it pretty widely in Kubernetes. BASH_SOURCE[0] will be the script invoked and is reliable vs $0 or something like that.

It also works with a downloaded source tarball, for this particular script maybe we don't care, but I prefer using a consistent pattern, and for other scripts some packagers are using tarballs IIRC. (though we currently also have #3645)

This trick is a neat combination of things that are safe versus the more trivial dirname "${BASH_SOURCE}"

  1. we use a subshell, so we can CD without affecting the current working directory (and we'd want that anyhow to capture the output)
  2. we use CD + pwd -P to portably resolve the real path (versus something like realpath/readlink that are portability nightmares)
  3. we use BASH_SOURCE[0] to specifically get the primary source script in a supported way instead of depending on something like "$0 will probably maybe have it"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(pwd -P happens to be specified in posix: https://pubs.opengroup.org/onlinepubs/007904875/utilities/pwd.html and that flag forces it to resolve symlinks, but only for the current working directory)

Copy link
Member Author

@BenTheElder BenTheElder Dec 13, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main downside of this approach is you need to know the levels of nesting to the repo root (/../..) but that only needs changing if we move it to be more or less nested (like this, the other script is /../../..), which won't happen often and you're going to catch the first time you run the script after moving it.

Copy link
Member Author

@BenTheElder BenTheElder Dec 13, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(er and BASH_SOURCE is safe because we specifically use #!/usr/bin/env bash and bash specifies this, we usually require bash for development scripts in kubernetes (along with gnu coreutils), I use POSIX sh for some portable utilities that I want end users to run, like the local registry script, but it lacks a lot of modern features and is avoided in favor of bash, go, etc otherwise)

Copy link
Member Author

@BenTheElder BenTheElder Dec 13, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... also I think git rev-parse --show-toplevel doesn't work for git worktree, which is something we're starting to use more in Kubernetes scripts (e.g. for diffing codegen in verify scripts)

... I've spent way too much time hacking on these scripts :^), we should really write more of this down somewhere ...

cd "${REPO_ROOT}"

VERSION="$1"

# ensure we have up to date kind
make build

# ensure we have qemu setup so we can run cross-arch images
# TODO: dedupe specifying this image?
docker run --rm --privileged tonistiigi/binfmt:qemu-v7.0.0-28@sha256:66e11bea77a5ea9d6f0fe79b57cd2b189b5d15b93a2bdb925be22949232e4e55 --install all

# NOTE: adding platforms is costly in terms of build time
# we will consider expanding this in the future, for now the aim is to prove
# multi-arch and enable developers working on commonly available hardware
# Other users are free to build their own images on additional platforms using
# their own time and resources. Please see our docs.
ARCHES="${ARCHES:-amd64 arm64}"
IFS=" " read -r -a __arches__ <<< "$ARCHES"

set -x
# build for each arch
IMAGE="${REGISTRY}/${IMAGE_NAME}:${VERSION}"
images=()
for arch in "${__arches__[@]}"; do
image="${REGISTRY}/${IMAGE_NAME}-${arch}:${VERSION}"
"${REPO_ROOT}/bin/kind" build node-image --image="${image}" --arch="${arch}" "${VERSION}"
images+=("${image}")
done

# combine to manifest list tagged with kubernetes version
# images must be pushed to be referenced by docker manifest
# we push only after all builds have succeeded
for image in "${images[@]}"; do
docker push "${image}"
done
docker manifest rm "${IMAGE}" || true
docker manifest create "${IMAGE}" "${images[@]}"
docker manifest push "${IMAGE}"
Loading