Should we look into creating a common “go builder” container base image that can be shared by all of the go components?
It would be easier to keep this in a common location rather than having to keep a bunch of Dockerfiles in sync. —Eric > On Jun 7, 2018, at 9:40 PM, Zelkowitz, Evan <[email protected]> > wrote: > > +1 on 3. I thought there were some changes made in 1.10 that have the > possibility of breaking things, i.e. I think it breaks some of Grove. They > may or may not affect TC but who knows what might happen in the future. So I > would think you would want the version pinned > ________________________________________ > From: Gray, Jonathan <[email protected]> > Sent: Thursday, June 7, 2018 4:53 PM > To: [email protected] > Subject: Re: [EXTERNAL] go version used in build > > I vote for option 3 since the version of go you compile with is no different > than the version of a library used in the build process. By specifying what > version it shall be, we also know when we go to newer versions and have more > reproducible builds. > > On 6/7/18, 3:27 PM, "Dan Kirkwood" <[email protected]> wrote: > > Hey, all.. I just investigated this issue ( > https://github.com/apache/incubator-trafficcontrol/issues/2380) and > realized that the `go` version being used in building traffic_stats and > traffic_monitor is different from that of traffic_ops due to the way it's > installed during the rpmbuild phase. In traffic_ops, a specific version > (1.8.3) is downloaded using a script; the others depend on yum without > specifying a version (currently 1.9.4). > > Should we worry about keeping these in line? If so, should we: > > 1. change TO to install latest version from yum? > 2. change TS and TM to use the script? > 3. change all to install a specific version from yum? > > Currently leaning toward #1, but I can be convinced otherwise.. > > thanks.. Dan > >
