I concur with the assessment that option #1 is easiest to achieve, but #3 is more desirable due to predictability when producing a build. I too prefer option #3, while acknowledging it could be more effort to implement. -- Thanks, Jeff
On Fri, Jun 8, 2018 at 11:19 AM, Dan Kirkwood <[email protected]> wrote: > 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 >>> > > >>> > > >>> > >>> > >>> >>
