Change:
readonly KUBE_CLIENT_PLATFORMS elif [[ "${KUBE_FASTBUILD:-}" == "true" ]]; then <del> readonly KUBE_SERVER_PLATFORMS=(linux/amd64) </del> <ins> KUBE_SERVER_PLATFORMS=(linux/amd64) readonly KUBE_SERVER_PLATFORMS </ins> readonly KUBE_NODE_PLATFORMS=(linux/amd64) if [[ "${KUBE_BUILDER_OS:-}" == "darwin"* ]]; then readonly KUBE_TEST_PLATFORMS=( darwin/amd64 linux/amd64 ) <del> readonly KUBE_CLIENT_PLATFORMS=( </del> <ins> KUBE_CLIENT_PLATFORMS=( </ins> darwin/amd64 linux/amd64 <del> ) </del> <ins> ) readonly KUBE_CLIENT_PLATFORMS </ins> else readonly KUBE_TEST_PLATFORMS=(linux/amd64) <del> readonly KUBE_CLIENT_PLATFORMS=(linux/amd64) </del> <ins> KUBE_CLIENT_PLATFORMS=(linux/amd64) readonly KUBE_CLIENT_PLATFORMS </ins> fi else KUBE_SERVER_PLATFORMS=("${KUBE_SUPPORTED_SERVER_PLATFORMS[@]}")

Discussion:
<!-- 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: building Kubernetes release and it failed due to a variable not being set (). It appears a does not function as expected on (used Ubuntu 16). Additional details will be provided in comment below What you expected to happen: successful build of Kuberentes release or documented minimum supported OS releases (i.e., bash versions) How to reproduce it (as minimally and precisely as possible): using Ubuntu 16 (), run [] using , or (containing or subsequent cherry pick) Anything else we need to know?: It appears the issue is with how and create variables, where I believe does not create the variables with the expected scope (created using scope versus scope). This creates a minimum supported OS version when running from the best I can tell. Environment: Kubernetes version (use ):  Cloud provider or hardware configuration: N/A OS (e.g: ):Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): N/A Others: /sig release
Some of the details I mentioned above, modified the file to output some helpful information the diff of changes I made the results when running on Ubuntu 16 (bash 4.3), the variable appears to be scoped inside the function the results when running on Ubuntu 16 (bash 4.3) without the variable attribute (you can now see the variable is a variable, not locally scoped to the function ) And on Ubuntu 18 (bash 4.4) the variable is scoped with the attribute as you would expect and runs as expected.
I guess fixes this problem. cc
I don't think the is/was the only issue here. It was obviously as I was testing with , so only variables were being used and not scoped outside the function (in bash 4.3).
we are also getting the same error on bash version 4.3 cc
any update on this, are you fixing it??
Same question with , this issue impact OpenLab cloud-provider-openstack E2E testing job.
can you please try this?

it works with your fix , previously jobs were failing --- EDIT --- Hold on, I think I was too fast, it failed in a later stage don't know if is a problem or related to the script changes. Should we have the tar files as an output ?
Sorry I missed this yesterday. I will try as well. Otherwise, my assumption was to revert the use of a function, as that creates the scoping problem we've been seeing with variables in .
i think that would be not
Also both not should work now.
Looks like worked for me. Was able to run a using successfully.
ref: as the pr that appears to have caused this