I have so many thoughts on this topic. :) We use a tool for composing the public ATS build on top of our list of backports (all of which are currently public, iirc). This is how we use stuff like URI Signing, which isn't available in ATS 7. I'm currently in the process of getting that opened up so that everyone can look at it (a couple weeks, probably, though), but the principle behind it isn't exceptionally complex.
What I'd like to see in the ATC ATS RPM is: - It's deterministically produced (basically, everything (as far as is reasonable) pegged to specific changesets/versions). - It contains every feature supported by ATC. - It builds as a `./pkg` target: `./pkg ats_build`. - It produces a single RPM that just works. Bonus points if it's relatively easy to add extra backports or private bug fixes. The PR is close on determinism, though it encourages using a branch instead of a revision, which could cause trouble for folks with RPMs updating unexpectedly. It doesn't have backports for URI Signing and astats is in its own RPM, which I think puts more work on the people managing the CDN than is necessary. It's spot on for the ./pkg usage. It's absolutely a step in the right direction, though, and I'd rather have something than nothing. I'm not totally enthused with this solution, but it's a start and we can work toward things going forward. On Fri, Jun 15, 2018 at 12:48 PM, Zelkowitz, Evan <evan_zelkow...@comcast.com> wrote: > I like the idea and looks good. One thing to think about though is in > the trafficserver.spec file, if there are any good ways to dynamically do > those config files includes at the end. Im no spec expert so Im not sure if > there may be a better way but recently here I worked on getting our internal > spec and build system to be able to do builds of ATS master and it looks like > starting with 8/9 some more of those files will be going away and another new > one introduced. So those files change frequently across version numbers > > On 6/15/18, 11:27 AM, "Eric Friedrich (efriedri)" > <efrie...@cisco.com.INVALID> wrote: > > I’ve opened a PR to produce Trafficserver and astats RPMs in the Traffic > Control build process. Previously, new users would need to create their own > build environments or ask for RPMS on Slack. > > This PR will lower the barrier to entry for new users. For more involved > users, theres now a set of scripts that will build inside a Dockerized > Jenkins environment. > > The changes rely on having all TS changes in a single git repository to > form the RPM source tarball. I understand there are some users which have > private tooling to build from multiple repos. I’m open to including this if > possible. Until that tool gets open sourced, I think this is a step forward > for TC builds. > > https://github.com/apache/trafficcontrol/pull/2399 > > Any concerns with bringing this in? > > —Eric > > >
