Cannot build from master !! ??

[droslean]

$ ./hack/build.sh 
+ LAUNCH_PATH=/root/go/src/github.com/openshift/installer
++ dirname ./hack/build.sh
+ cd ./hack/..
++ go list -e -f '{{.Dir}}' github.com/openshift/installer
+ PACKAGE_PATH=/root/go/src/github.com/openshift/installer
+ test -z /root/go/src/github.com/openshift/installer
+ LOCAL_PATH=/root/go/src/github.com/openshift/installer
+ test /root/go/src/github.com/openshift/installer '!=' /root/go/src/github.com/openshift/installer
+ MODE=release
++ git describe --always --abbrev=40 --dirty
+ LDFLAGS=' -X main.version=v0.3.0-145-g6106d58ddf61f3f18c51f6b295ab8c73160dac91'
+ TAGS=
+ OUTPUT=bin/openshift-install
+ export CGO_ENABLED=0
+ CGO_ENABLED=0
+ case "${MODE}" in
+ TAGS=' release'
+ test '' '!=' y
+ go generate ./data
writing assets_vfsdata.go
+ echo ' release'
+ grep -q libvirt_destroy
+ go build -ldflags ' -X main.version=v0.3.0-145-g6106d58ddf61f3f18c51f6b295ab8c73160dac91' -tags ' release' -o bin/openshift-install ./cmd/openshift-install
# github.com/openshift/installer/vendor/k8s.io/client-go/transport
vendor/k8s.io/client-go/transport/round_trippers.go:437:9: undefined: strings.Builder

[droslean]

That start happening after #579

[droslean]

It seems that the go versions should be higher than 1.9. Is this documented anywhere?
Also the hack/build.sh should check that before continuing.

[wking]

It seems that the go versions should be higher than 1.9. Is this documented anywhere?

strings.Builder is new in Go 1.10. With Go 1.11 released in August upstream dropped support for 1.9. Do we want to document/advertise support for deprecated Go releases? The version that we do support is documented here, and that declaration:

• Is backed by CI, ensuring that it works.
• Is something users can invoke locally if they have issues building the installer on their host system.

[DanyC97]

@wking imo will be good to document it in a md file - even if that is in hack dir or something rather than wait for people to look in the dockerfile

[wking]

Also, cross-linking #589.

imo will be good to document it in a md file...

So in this case, the Go 1.10 floor is due to a vendor bump. Do you think we should be manually pulling deps like that from our vendored packages? We vendor a bunch of packages, and that seems like a lot of work.

Or do you think we should list a minimum version and test that version in CI? Maintaining CI tooling for multiple Go versions also sounds like a lot of work. Would you run e2e tests on installers built with each Go version (crossed with different versions of our other dependencies? Kernel versions? Once we test them, libvirt versions?).

• even if that is in hack dir or something rather than wait for people to look in the dockerfile

If the issue is "folks are having trouble building the installer", using a Dockerfile approach with versions that work and pass CI is something we're already doing. And while it's a bit unfortunate that folks are on their own as far as other versions go, there's only so much we currently have time to maintain. Would you be ok with a link from docs/dev/dependencies.md to images/installer/Dockerfile.ci to make the Dockerfile more discoverable?

[droslean]

opened #621

[raesene]

This would be well worth documenting. I'm following the "happy path" install for libvirt on a vanilla CentOS 7 VM and it fails due to this issue. the current build pre-requisites instruction is to install the golang-bin package via yum and this doesn't work as CentOS provides golang-bin-1.9.4-1.el7.x86_64

AFAIK there are no official CentOS Golang packages for Go 1.10+.

The Docker option for building sounds useful but it would be good to have some instructions on using it to build the binaries in the front page README.

[DanyC97]

@wking

Would you be ok with a link from docs/dev/dependencies.md to images/installer/Dockerfile.ci to make the Dockerfile more discoverable?

yes i'd say