Update CI go version

[zalegrala]

Here we update Go in our CI to address a potential security issue in one
of our dependencies.

https://groups.google.com/g/golang-announce/c/RP1hfrBYVuk/m/I7ouYouLAAAJ

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[joe-elliott]

This just changes our CI pipeline right? Should we update the docker image that we build off as well?

[zalegrala]

I updated the lambda Dockerfile Go version, and also the alpine version. Did I miss any others? Let's see if CI passes with the new alpine.

[mdisibio]

Fwiw it looks like the floating 1.17 was choosing the latest patch already. Do we want to pin the patch? I am personally ok with either approach. Go patches have historically been positive.

$ docker run grafana/tempo:r35-e1c6066 -version
tempo, version  (branch: r35, revision: e1c60662)
  build user:       
  build date:       
  go version:       go1.17.8
  platform:         linux/amd64

$ docker run grafana/tempo:main-e1c6066 -version
tempo, version  (branch: main, revision: e1c60662)
  build user:       
  build date:       
  go version:       go1.17.8
  platform:         linux/amd64

$ docker run grafana/tempo:1.3.2 -version
tempo, version  (branch: HEAD, revision: fbca6a01a)
  build user:       
  build date:       
  go version:       go1.17.7
  platform:         linux/amd64

And to be sure, my local go is only .6:

$ go version
go version go1.17.6 darwin/amd64

[zalegrala]

I suppose as long as the release builds are happening with the new version, I'm fine leaving out the patch pinning here. What do we think about the alpine updates?

[joe-elliott]

my .02:

• leave the floating patch on the go builds alone
• update the alpine versions as suggested in the PR

@zalegrala remove the go changes and we'll merge?