btw, not going to act on this right now, so there still is time to provide your input.
On Fri, Jun 8, 2018 at 11:17 AM Dan Kirkwood <[email protected]> wrote: > Thanks, Dave -- that's where I stand as well -- preferring #1 but knowing > that #3 is probably the necessary option.. I like the common go build > idea, but can't spend the time on it now. > > Going for consensus.. Can everyone live with #3 (yum install golang > with specific version for all components)? > > Please speak up.... > > -dan > > On Fri, Jun 8, 2018 at 8:15 AM Dave Neuman <[email protected]> wrote: > >> I prefer #1 since that seems like the easiest, however that could lead to >> inconsistent builds and make it hard to support our products, so I think >> #3 >> is probably a better option. >> >> If we chose to go with #3 then I like Erics idea of making a common go >> builder so that we only need to manage the version in one place and not >> three (or more in the future). >> >> >> On Fri, Jun 8, 2018 at 6:41 AM Eric Friedrich (efriedri) < >> [email protected]> >> wrote: >> >> > 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 >> > > >> > > >> > >> > >> >
