On Thu, Sep 29, 2022 at 1:27 AM Robert Haas <robertmhaas@gmail.com> wrote:
> ... Here's a
> list of the follow-up fixes I've so far committed:
>
> 1. headerscheck
> 2. typos
> 3. pg_buffercache's meson.build
> 4. compiler warning
> 5. alignment problem
> 6. F_INTEQ/F_OIDEQ problem
>
> CI caught (1), (3), and (4). The buildfarm caught (1), (5), and (6).
I think at least some of 5 and all of 6 would be covered by sanitizer
flags and a 32 bit test respectively, and I think we should add those.
We're feeling our way here, working out what's worth including at
non-zero cost for each thing we could check. In other cases you and I
have fought with, it's been Windows problems (mingw differences, or
file handle semantics), which are frustrating to us all, but I see
Meson as part of the solution to that: uniform testing on Windows
(whereas the crusty perl would not run all the tests), and CI support
for mingw is in the pipeline.
> ... I
> feel like CI has not really made it in any easier to not break the
> buildfarm -- it's just provided a second buildfarm that you can break
> independently of the first one.
I don't agree with this. The build farm clearly has more ways to
break than CI, because it has more CPUs, compilers, operating systems,
combinations of configure options and rolls of the timing dice, but CI
now catches a lot and, importantly, *before* it reaches the 'farm and
everyone starts shouting a lot of stuff at you that you already knew,
because it's impacting their work. Unless you don't look, and then
it's just something that breaks with the build farm, and then you
break CI on master for everyone else too and more people shout.
I'm not personally aware of any significant project that isn't using
CI, and although we're late to the party I happen to think that ours
is getting pretty good considering the complexities. And it's going
to keep improving.
