<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Adding new nodes with next distro release versions is a manual process <br>
not related to keeping existing nodes up to date (which is automated?).<br></blockquote><div><br></div><div>Mostly.</div><div>Our Linux environments are docker containers on amd64, armv7l and arm64.</div><div>On a roughly monthly cadence, I pull from our dockerfiles repo (<a href="https://github.com/kinkie/dockerfiles">https://github.com/kinkie/dockerfiles</a>) and</div><div>$ make all push</div><div>The resulting docker images are free for everybody to use and test things on on any docker system</div><div>(<a href="https://hub.docker.com/r/squidcache/buildfarm">https://hub.docker.com/r/squidcache/buildfarm</a>). Just </div><div>$ docker run -ti --rm -u jenkins squidcache/buildfarm:$(uname -m)-<distro name> /bin/bash -l</div><div>(note: the above command will not preserve any artifacts once the shell exits)</div><div><br></div><div>Adding new Linux distros means copying and tweaking a Dockerfile, testing things, and updating our Jenkins jobs. I do it roughly every 6 months</div><div><br></div><div>FreeBSD, OpenBSD and (hopefully soon) Windows are hand-managed and much slower changing VMs</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>> What I would place on each individual dev is the case where a PR breaks<br>
>> something in the trunk-matrix,trunk-arm32-matrix, trunk-arm64-matrix,<br>
>> trunk-openbsd-matrix, trunk-freebsd-matrix builds, even if the 5-pr-test<br>
>> and 5-pr-auto builds fail to detect the breakage because it happens on a<br>
>> unstable or old platform. ><br>
> This feels a bit out of topic for me, but I think you are saying that<br>
> some CI tests called trunk-matrix, trunk-arm32-matrix,<br>
> trunk-arm64-matrix, trunk-openbsd-matrix, trunk-freebsd-matrix should be<br>
> classified as _required_.<br>
<br>
That is how I read the statement too.<br></blockquote><div><br></div><div>In a word of infinite resources and very efficient testing, sure.</div><div>But in a space where a single os/compiler combo takes 2hrs on Linux and 4hrs on Freebsd or openbsd, and a full 5-pr-test takes 6 hours end to end, we need to optimize or making any of these requirements blocking would make these times get 4+ times larger (a full trunk-matrix takes just about a day on amd64, 2 days on arm64), and the complaint would then be that development or release is slowed down by the amount of testing done.</div><div><br></div><div>My proposal aims to test/land the PR on the systems where we can be efficient and that are relevant, and fix any remaining after-the-fact issues with followup, PRs, that remain a soft requirement for the dev introducing the change. The dev can test any work they're doing with the anybranch-* jobs, if they don't have access to that OS</div><div><br></div><div>Can we do better? Sure.</div><div>For the sake of cost-mindedness a lot of the build farm nodes run in my home - a couple of raspberry PIs, an Intel NUC, I'm in the process of purchasing a second (and second-hand) NUC that comes with a Windows license. The set up is meant to be thrifty, I'm mindful of burning Foundation resources for little gain and I'm running a balancing act between always-on VMs, on-demand VMs and my own gadgets.</div><div><br></div><div>The real game changer would be rethinking how we do things to reduce the amount of testing needed.</div><div><br></div><div>For instance: we currently have a lot of different build-time configurations meant to save core memory in runtime environments. Is it maybe time to revisit this decision and move these checks to run time? Unfortunately, one of the problems we have is that we're running blind. We don't know what configurations our users deploy; we can only assume and that makes this conversation much more susceptible to opinions and harder to build consensus on</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature">    Francesco</div></div>