All installer binaries extracted from a payload, regardless of their
runtime OS or architecture, are built on the payload architecture.
Therefore, GOHOSTARCH can be used to assume the cluster architecture for
which its payload was built. This is set through the Dockerfiles so that
manual builds of installer will continue to default to amd64.
Set a marker for oc to inject the release version to avoid potential
confusion from:
$ oc adm release extract --command=openshift-install quay.io/openshift-release-dev/ocp-release:4.2.7
$ ./openshift-install version
./openshift-install v4.2.5
built from commit 425e4ff003
release image quay.io/openshift-release-dev/ocp-release@sha256:bac62983757570b9b8f8bc84c740782984a255c16372b3e30cfc8b52c0a187b9
The actual oc injection logic is in [1].
[1]: https://github.com/openshift/oc/pull/165
And include that hash in the 'openshift version' and log output. This
makes it easier to troubleshoot reports from official builds, which
currently reference internal tags:
$ RELEASE=quay.io/openshift-release-dev/ocp-release:4.0.0-0.7
$ INSTALLER="$(oc adm release info "${RELEASE}" --image-for installer)"
$ oc image extract "${INSTALLER}" --file=/usr/bin/openshift-install
$ chmod +x openshift-install
$ ./openshift-install version
./openshift-install v4.0.15-1-dirty
although you can currently extract the commit given the pullspec and
access to the backing registry:
$ oc image info --output=json "${INSTALLER}" | jq -r '.config.config.Labels["io.openshift.build.commit.id"]'
c8b3b55326
previously the version information was a private variable in `cmd`. moving to a public pkg `version`
allows other packages to include the installer version information as desired.
good example is the AWS calls made by the installer.
