Re: Adding CI to our tree

Hi,

On 2021-12-14 16:51:58 +1300, Thomas Munro wrote:
> I'd better go and figure out how to fix cfbot when this lands...

I assume it'd be:
- stop adding the CI stuff
- adjust links to CI tasks, appveyor wouldn't be used anymore
- perhaps reference individual tasks from the cfbot page?


> > I think this may be OK for now, but I also could see arguments for wanting to
> > transfer the image specifications and the google account to PG properties.
> 
> No clue on the GCP account side of it (does pginfra already have
> one?), but for the repo I guess it would seem natural to have one on
> git.postgresql.org infra, mirrored (just like the main repo) to a repo
> on project-owned github.com/postgres, from which image building is
> triggered.  Then it could be maintained by the whole PostgreSQL
> project, patches discussed on -hackers, a bit like pg_bsd_indent.
> Perhaps with some way to trigger test image builds, so that people
> working on it don't need their own GCP account to do a trial run.

I think that's a good medium-term goal, I'd not make it a prerequisite for
merging myself.


> +  # Test that code can be built with gcc/clang without warnings
> 
> As a TODO note, I think we should eventually run a warnings check for
> MSVC too.  IIUC we only aim to be warning free in assertion builds on
> that platform, because it has no PG_USED_FOR_ASSERTS_ONLY (I think it
> has it in C++ but not C?), but that's something.

Hm. Not entirely sure how to do that without doing a separate windows build,
which is too slow...


> +  # XXX: Only do this if there have been changes in doc/ since last build
> +  always:
> +    docs_build_script: |
> +      time ./configure \
> +        --cache gcc.cache CC="ccache gcc"
> +      time make -s -j4 -C doc
> 
> Another TODO note: perhaps we could also make the documentation
> results a browsable artefact with a short retention time, if that's a
> thing.

Might be doable, but I'd guess that the volume of data it'd generate make it
not particularly attractive.


> I feel like I should apologise in advance for this level of
> nit-picking about English grammar, but:

:)

Will try to fix.


> +  name: FreeBSD
> 
> FreeBSD is missing --with-llvm.

That was kind of intentional, I guess I should add a comment about it. The CI
image for freebsd already starts slower due to its size, and is on the slower
side compared to anything !windows, so I'm not sure it's worth enabling llvm
there? It's probably not bad to have one platform testing without llvm.


> > [1] Some ideas for what could make sense to extend CI to in the future:
> 
> To your list, I'd add:
> 
> * 32 bit

That'd be easy.


> * test coverage report

If the output size is reasonable, that should be doable as well.


> * ability to capture complete Window install directory as an artefact
> so a Windows user without a dev environment could try out a proposed
> change/CF entry/...

I think the size of these artifacts would make this not something to enable by
default. But perhaps a manually triggered task would make sense?


> I hope we can get ccache working on Windows.

They did merge a number of the other required changes for that over the
weekend. I'll try once they released...

Thanks!

Andres Freund