[squid-dev] Strategy about build farm nodes

[Francesco Chemolli]

Hi all,
  I'm moving here the discussion from PR #806 about what strategy to have
for CI tests, looking for an agreement.

We have 3 classes of tests ni our CI farm (https://build.squid-cache.org/)
- PR staging tests, triggered by commit hooks on GitHub (possibly with
human approval)
   the job is 5-pr-auto (misnamed, it tests trunk with the PR applied).
   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
- PR build tests run , after a PR is approved, also triggered by GitHub
  the job is 5-pr-test
  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
- full-scale build tests (jobs: trunk-matrix, trunk-arm32-matrix,
trunk-arm64-matrix, trunk-freebsd13-clang-matrix, trunk-openbsd-matrix)
  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

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
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
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

Would this work as a general policy? If there is agreement, I'll support
it moving forward

Thanks

-- 
    Francesco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20210428/3e3e3195/attachment.htm>