clusterctl v1.3.4 release is dynamically linked

[killianmuldoon]

Running file clusterctl for the v1.3.4 release of clusterctl results in:

clusterctl: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=yR9uWcD4N15MM7Kjv1mn/M3gTbLzMQhJ_RDVasc7T/_jsEXNT9ofeNgJ62hqfq/FiapP7BVUu3GBuVTnKqQ, with debug_info, not stripped

Showing that it is dynamically linked.
For v1.3.3 the output was:

clusterctl: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=8fPykMBy1OD0kQ6IyHsd/JtqmYRi5AvrSiojXqgxJ/4Dm_jSA0C-9KnYJ_8iuv/FhBSw_QQzsmWks8T6Koq, with debug_info, not stripped

The new binary should also be statically linked. This may be related to changes in #8199

/kind bug
/area clusterctl
[One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels]

[killianmuldoon]

Definitely related to #8199. Removing this and setting the user explicitly makes the binary statically linked and allows it to build.

[killianmuldoon]

/triage accepted

[killianmuldoon]

It turns out that using the -e flag to set environmental variables in docker run commands - like is done in the clusterctl release-binary build - does not persist across commands. The release binary fix introduced for v1.3.4 ended up with the wrong env variables as a result.

I confirmed this by running:

 docker run -e CGO_ENABLED=0 --user 1000:1000 golang:1.19.6 go env | grep CGO_ENABLED ; echo ; go env | grep CGO_ENABLED;

Which gave the output:

CGO_ENABLED="0"

CGO_ENABLED="1"

I'm not certain if this is down to docker version or some other variable.