<div dir="ltr">Hi all,<div>  I'm moving here the discussion from PR #806 about what strategy to have for CI tests, looking for an agreement.</div><div><br></div><div>We have 3 classes of tests ni our CI farm (<a href="https://build.squid-cache.org/">https://build.squid-cache.org/</a>)</div><div>- PR staging tests, triggered by commit hooks on GitHub (possibly with human approval) <br>   the job is 5-pr-auto (misnamed, it tests trunk with the PR applied).<br>   To be successful, it needs to successfully compile and unit-test all combinations of clang and gcc on the latest stable version of the most popular linux distros, at this time centos-8, debian-testing, fedora-33, opensuse-leap, ubuntu-focal</div><div>- PR build tests run , after a PR is approved, also triggered by GitHub</div><div>  the job is 5-pr-test</div><div>  To be successful, it needs to compile and unit-test all combinations of clang and gcc on LTS and most recent versions of most popular linux distros, at this time: centos-7, debian-stable, debian-unstable, fedora-32, fedora-34, ubuntu-bionic, ubuntu-hirsute</div><div></div><div>- full-scale build tests (jobs: trunk-matrix, trunk-arm32-matrix, trunk-arm64-matrix, trunk-freebsd13-clang-matrix, trunk-openbsd-matrix)<br>  these test everything we can test, including bleeding edge distros such as getntoo, rawhide, tumbleweed, and the latest compilers. Failing these will not block a PR from mergeing, but there is an expectation that build regressions will be fixed</div><div><br></div><div>The change in policy since last week is that the PR-blocking builds used to depend on unstabledistros (fedora-rawhide and opensuse-tumbleweed), I've removed that today as part of the discussion on PR #806<br></div><div>This policy would allow keeping stable distros uptodate and matching expected user experience, while not introducing instability that would come in from the unstable distros</div><div>One distro that's notably missing is centos-stream, this is due to technical issues with getting a good docker image for it, when available I'll add it</div><div><br></div><div>Would this work as a general policy? If there is agreement, I'll support it moving forward</div><div><br></div><div>Thanks</div><div><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">    Francesco</div></div></div>