Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Bump minimum go version for YDBGo from 1.13 to 1.18 (needed by stretc…
…hr/testify/assert package) Background ---------- * Below is pasted from stretchr/testify#1379 (comment) where I had asked a question on a recent failure we saw in the YDBGo pipelines (and in the YDBTest/go/unit_test subtest failures in in-house systems which had go 1.13 and 1.15). @HaraldNordgren : Hi. We have a Go application that uses the `stretchry/testify` package. It was working fine on various systems with different go versions. But for the past 4 days, our nightly pipelines have been failing when run with go 1.13.8. ```sh $ go version go version go1.13.8 linux/amd64 ``` The failure symptom is the following (pasted from https://gitlab.com/YottaDB/Lang/YDBGo/-/jobs/4268493955) ```sh $ go test -short $(go list ./... | grep -v /vendor/) # github.com/stretchr/testify/assert /go/src/github.com/stretchr/testify/assert/assertions.go:94:23: field.IsExported undefined (type reflect.StructField has no field or method IsExported) ``` The same application also fails on a system with `go version go1.15.15 linux/amd64` but passes on a system with `go version go1.18.1 linux/amd64`. 4c93d8f changed `assertions.go` to add the `field.isExported` call. But looks like that call is only supported by recent versions of go. Is this seeming regression expected? Thanks. * And below was the response (pasted from stretchr/testify#1379 (comment)) In general I would definitely advise against using the 'master' build of any library. You are better off pinning the version to testify@v1.8.2 and you would avoid this issue. This repo has been updated to only support Go versions >=1.18. Be aware the the Go versions you are using are not officially supported anymore: https://endoflife.date/go. It would also be a good idea to upgrade your Go versions. Fix --- * I tried pinning the version like was suggested. I tried updating go.mod as follows. ```diff $ git diff go.mod @@ -4,2 +4,3 @@ go 1.13 -require github.com/stretchr/testify v1.4.0 +require github.com/stretchr/testify v1.8.2 +replace github.com/stretchr/testify => github.com/stretchr/testify v1.8.2 ``` But the YDBGo pipeline still failed as before when it used go 1.13 or go 1.15. * I then tried the following change. ```diff $ git diff go.mod @@ -4,2 +4,3 @@ go 1.13 -require github.com/stretchr/testify v1.8.2 +require github.com/stretchr/testify v1.4.0 +replace github.com/stretchr/testify => github.com/stretchr/testify v1.8.2 ``` This one failed the same way as well. * Finally decided to bump the go version required by the pipeline to 1.18 as suggested above. Searched for all references of `1.13` in the YDBGo repository in the `develop` branch and changed all of them to be `1.18`. In some cases, used `1.18.10` as that was the latest golang version in the 1.18 series. And regenerated `go.mod` using the following steps. This auto-generated go.mod file is included in this commit. ```sh $ cd YDBGo $ echo "module lang.yottadb.com/go/yottadb" > go.mod $ go get -t go: added github.com/davecgh/go-spew v1.1.1 go: added github.com/pmezard/go-difflib v1.0.0 go: added github.com/stretchr/testify v1.8.2 go: added gopkg.in/yaml.v3 v3.0.1 ``` * And in the in-house systems that have go 1.13 (Ubuntu 20.04) and go 1.15 (Debian 11), decided to install the latest Go version using snap instead of using the old go version from the package manager. The install worked fine on x86_64, AARCH64 and ARM32 architectures. With those changes, the `go/unit_tests` subtest passes fine on all those architectures when it previously reliably failed.
- Loading branch information