Change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: some of base images support multi-arch, if no platform specified, the image pulled will actually reflect where the operation is performed, current implementation always assume the default platform is amd64 which make the tags is not correctly defined. for example, on arm64 platform, here is what I got after build the image of ipc-utils, What you expected to happen: tag should be defined correctly How to reproduce it (as minimally and precisely as possible): on arm64 platform, Anything else we need to know?: Environment: Kubernetes version (use ): latest Cloud provider or hardware configuration: all arch except x86 OS (e.g: ): all Kernel (e.g. ): all Install tools: Network plugin and version (if this is a network-related bug): Others:
/assign
/sig testing release
This is the side effect of command, you can fix it by specifying tag while building the image.
The tag is still experimental and introduced in so I really doubt about using this anywhere, I feel it is just a cosmetic issue and only applies for the images with tag. As we are pushing fat manifest images with proper archs so we don't have to worry much about it.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/lifecycle frozen
/remove-lifecycle rotten
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted

Discussion:
base_image="" if [[ -f BASEIMAGE ]]; then <del> base_image=$(getBaseImage "${os_arch}" | ${SED} "s|REGISTRY|${REGISTRY}|g") ${SED} -i "s|BASEARCH|${arch}|g" $dockerfile_name </del> <ins> base_image=$(getBaseImage "${os_arch}" | "${SED}" "s|REGISTRY|${REGISTRY}|g") "${SED}" -i "s|BASEARCH|${arch}|g" $dockerfile_name </ins> fi <del> # copy the qemu-*-static binary to docker image to build the multi architecture image on x86 platform if grep -q "CROSS_BUILD_" Dockerfile; then if [[ "${arch}" == "amd64" ]]; then ${SED} -i "/CROSS_BUILD_/d" Dockerfile else ${SED} -i "s|QEMUARCH|${QEMUARCHS[$arch]}|g" Dockerfile # Register qemu-*-static for all supported processors except the current one echo "Registering qemu-*-static binaries in the kernel" local sudo="" if [[ $(id -u) != 0 ]]; then sudo=sudo </del> <ins> # Only the cross-build on x86 is guaranteed by far, other arches like aarch64 doesn't support cross-build # thus, there is no need to tackle a disability feature on those platforms, and also help to prevent from # ending up a wrong image tag on non-amd64 platforms. build_arch=$(uname -m) if [[ ${build_arch} = 'x86_64' ]]; then # copy the qemu-*-static binary to docker image to build the multi architecture image on x86 platform if grep -q 'CROSS_BUILD_' Dockerfile; then if [[ "${arch}" = 'amd64' ]]; then "${SED}" -i '/CROSS_BUILD_/d' Dockerfile else "${SED}" -i "s|QEMUARCH|${QEMUARCHS[$arch]}|g" Dockerfile # Register qemu-*-static for all supported processors except the current one echo 'Registering qemu-*-static binaries in the kernel' local sudo if [[ $(id -u) -ne 0 ]]; then sudo=sudo fi ${sudo} "${KUBE_ROOT}/third_party/multiarch/qemu-user-static/register/register.sh" --reset -p yes curl -sSL https://github.com/multiarch/qemu-user-static/releases/download/"${QEMUVERSION}"/x86_64_qemu-"${QEMUARCHS[$arch]}"-static.tar.gz | tar -xz -C "${temp_dir}" # Ensure we don't get surprised by umask settings chmod 0755 "${temp_dir}/qemu-${QEMUARCHS[$arch]}-static" "${SED}" -i 's/CROSS_BUILD_//g' Dockerfile fi </ins> fi <del> ${sudo} "${KUBE_ROOT}/third_party/multiarch/qemu-user-static/register/register.sh" --reset -p yes curl -sSL https://github.com/multiarch/qemu-user-static/releases/download/"${QEMUVERSION}"/x86_64_qemu-"${QEMUARCHS[$arch]}"-static.tar.gz | tar -xz -C "${temp_dir}" # Ensure we don't get surprised by umask settings chmod 0755 "${temp_dir}/qemu-${QEMUARCHS[$arch]}-static" ${SED} -i "s/CROSS_BUILD_//g" Dockerfile fi </del> <ins> elif [[ "${QEMUARCHS[$arch]}" != "${build_arch}" ]]; then echo "skip cross-build $arch on non-supported platform ${build_arch}." popd continue else "${SED}" -i '/CROSS_BUILD_/d' Dockerfile </ins> fi docker buildx build --progress=plain --no-cache --pull --output=type="${output_type}" --platform "${os_name}/${arch}" 

# reset manifest list; needed in case multiple images are being built / pushed. manifest=() # Make os_archs list into image manifest. Eg: 'linux/amd64 linux/ppc64le' to '${REGISTRY}/${image}:${TAG}-linux-amd64 ${REGISTRY}/${image}:${TAG}-linux-ppc64le' <del> while IFS='' read -r line; do manifest+=("$line"); done < <(echo "$os_archs" | ${SED} "s~/~-~g" | ${SED} -e "s~[^ ]*~$REGISTRY/$image:$TAG-&~g") </del> <ins> while IFS='' read -r line; do manifest+=("$line"); done < <(echo "$os_archs" | "${SED}" "s~/~-~g" | "${SED}" -e "s~[^ ]*~$REGISTRY/$image:$TAG-&~g") </ins> docker manifest create --amend "${REGISTRY}/${image}:${TAG}" "${manifest[@]}" # We will need the full registry name in order to set the "os.version" for Windows images.