Hi Willy, On Fri, May 15, 2020 at 6:07 PM Willy Tarreau <[email protected]> wrote:
> Ilya, > > > also, I'd suggest to purge travis-ci cache (if you are build in your own > > fork). > > some travis related issue might be related when something is took from > > cache (which was not supposed to happen) > > Could you please handle Martin's patch, possibly cut it into several > pieces if relevant and add a commit message indicating what it does > (and why) ? Martin is not at ease with Git (which is not a problem), > and it seems only him and you understand how the reasons of the changes > in his patch. At least it's totally unclear to me why there's a new > install target for arm64 and why there's a special "make" invocation > there. > Let me explain the change. At https://github.com/haproxy/haproxy/blob/a8dbdf3c4b463a3f3e018f0cd02fa0d8d179bc07/.travis.yml#L113-L117 you may see the default 'install' phase. At https://github.com/haproxy/haproxy/blob/a8dbdf3c4b463a3f3e018f0cd02fa0d8d179bc07/.travis.yml#L12-L19 is the default environment. They are used by every job from the matrix ( https://github.com/haproxy/haproxy/blob/a8dbdf3c4b463a3f3e018f0cd02fa0d8d179bc07/.travis.yml#L35 ). But each job can override the default environment and any of the phases (before_install, install, after_install, script). For the ARM64 build I overwrote the 'install' phase by copying the default one and removing the execution of the build_ssl() function (the one that builds OpenSSL from source) and I also overwrote the environment to update the values of SSL_INC and SSL_LIB variables. 'openssl' and 'libssl-dev' packages are already installed in the Ubuntu image used by TravisCI so there is nothing to install manually.. I've added a comment ( https://github.com/haproxy/haproxy/blob/a8dbdf3c4b463a3f3e018f0cd02fa0d8d179bc07/.travis.yml#L47) to remind us how it works. > Feel free to add your "purge cache" change as an extra patch if needed. > But in any case, please make sure it's still possible to follow the > impact of each change, because we've touched many things blindly for > a while on this arm64 issue and most of the changes were basically > "let's see if this helps", which is a real mess :-/ > > Thanks! > Willy >
