Re: Reminder: spin up REL_11_STABLE on your buildfarm animals

On 07/07/2018 03:49 PM, Tom Lane wrote:
> Please check that your buildfarm members are building the v11 branch,
> and update their configurations if not.  We currently have ~80 animals
> building v10, but only about 50 have checked in on v11 so far.
>
>             


Yeah, here's the list:

pgbfprod=> select sysname, operating_system, os_version, compiler, compiler_version from public.dashboard_mat where
branch= 'REL_10_STABLE' and sysname not in (select sysname from public.dashboard_mat where branch = 'REL_11_STABLE');
 
     sysname    |    operating_system     |       os_version       |   compiler    |              compiler_version

---------------+-------------------------+------------------------+---------------+--------------------------------------------
  aholehole     | CentOS                  | 5                      | GCC           | 4.1.2
  brolga        | Cygwin/XP-Pro           | 1.7.7                  | gcc           | 4.3.4
  calliphoridae | Debian                  | sid                    | gcc           | 6.3
  castoroides   | Solaris                 | 10                     | Sun Studio    | 12
  chub          | RedHat Enterprise Linux | 7                      | gcc           | gcc (GCC) 4.8.5 20150623 (Red Hat
4.8.5-4)
  conchuela     | DragonFly BSD           | 4.4.3-RELEASE          | gcc           | 5.2.1
  culicidae     | Debian                  | sid                    | gcc           | 6.3
  curculio      | OpenBSD                 | 5.9                    | gcc           | 4.2.1
  currawong     | Windows XP-PRO          | SP3                    | MSVC++        | 2008 Express
  dory          | Windows Server          | 2016                   | Visual Studio | 2015
  flaviventris  | Debian                  | Sid                    | gcc           | snapshot
  francolin     | Debian                  | sid                    | gcc           | 6.3
  frogmouth     | Windows XP/Pro          | SP3                    | gcc           | 4.5.0
  gaur          | HP-UX                   | 10.20                  | gcc           | 2.95.3
  grison        | Raspbian GNU/Linux      | 7.8                    | gcc           |  4.6.3
  guaibasaurus  | Debian                  | 8.1                    | gcc           | 4.9.2
  hamerkop      | Windows                 | Server 2008 R2 (64bit) | Visual C++    | 2005
  leech         | CentOS Linux            | 6.2                    | icc           | 14.0
  loach         | FreeBSD                 | 10.3-RELEASE           | clang         | 3.4.1
  macaque       | RHEL                    | 7.0                    | gcc           | 4.8.2
  mule          | Debian                  | Debian 9.0             | gcc           | gcc 6.3.0
  mylodon       | Debian                  | sid                    | clang         | 5.0
  pademelon     | HP-UX                   | 10.20                  | HP C Compiler | A.10.32.22
  piculet       | Debian                  | sid                    | gcc           | 6.3
  protosciurus  | Solaris                 | 10                     | GCC           | 3.4.3
  rhinoceros    | CentOS Linux            | 7.1                    | gcc           | 4.8.3 20140911 (Red Hat 4.8.3-9)
  serinus       | Debian                  | Sid                    | gcc           | snapshot
  sidewinder    | NetBSD                  | 7                      | gcc           | 4.8.4
  skink         | Debian Sid              | sid                    | gcc           | gcc-6.3
  snapper       | Debian                  | 7 Wheezy               | gcc           | 4.7
  tick          | CentOS Linux            | 6.2                    | clang/llvm    | 3.4


Note that brolga, currawong and frogmouth will not build past Release 10 
because the platform doesn't support huge pages, so they are expected to 
be on this list.

That leaves 28.

If you're running the modern way via run_branches.pl with 
branches_to_build set to ALL or HEAD_PLUS_LATESTn then this should just 
happen without owner intervention when a new branch is created. So I 
assume that all these are either running not using run_branches.pl. or 
have hardcoded lists of branches in their config files.

Probably not best practice.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services