Since this invalid Semantic Version messages redirecting to stdout
will be captured by line 790 at hack/lib/golang.sh:
`goldflags="${GOLDFLAGS=-s -w -buildid=} $(kube::version::ldflags)"`
This happens when only no valid tag exists in repo
Currently target CC can only be set if the host platform
is linux/amd64 . If target is already set in the environment
it is always safe to use it and enable cgo.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
* switched one spot to use kube::logging
* make kube::util::find-binary return an error when it doesn't find
anything so that hack scripts fail fast instead of with '' binary not
found errors.
* this required deleting some genfeddoc stuff. the binary no longer
exists in k/k repo since we removed federation/, and I don't see it
in https://github.com/kubernetes-sigs/kubefed/ either. I'm assuming
that it's gone for good now.
If a bearer token is present in a request, the exec credential plugin should accept that as the chosen method of authentication. Judging by an [earlier comment in exec.go](c18bc7e9f7/staging/src/k8s.io/client-go/plugin/pkg/client/auth/exec/exec.go (L217)), this was already intended. This would however not work since UpdateTransportConfig would set the GetCert callback which would then get called by the transport, triggering the exec plugin action even with a token present in the request. See linked issue for further details.
See #87369 for further details.
Signed-off-by: Anders Eknert <anders.eknert@bisnode.com>
While the umask was previously set for builds (and in fact `docker run`
sets it to 0022 by default), the release pipeline `cp`'s files (with
`-a`) which respect the user's umask, and is outside of the build path.
This sets the umask in a common function called by all build tools,
which Stephen agreed was the simplest and most complete fix. The
`verify-prereqs` function is already poorly named for what it does, and
this only makes it epsilon worse.
Some binaries now run as non-root (kube-scheduler). When umask is 0027,
for example, the container image we build has the binary 0750, which is
not executable by the non-root UID.
We have been having issues with making builds reproducible, especially
with the `.note.go.buildid` ELF section. One tip from a golang issue was
to set `-ldflags=-buildid=` which seems to work well. You can confirm
that the buildid is set to empty by inspecting the binaries with the go
command example `go tool buildid _output/local/go/bin/kubectl`
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
