Re: Adding CI to our tree

Hi,

On 2022-02-12 23:19:38 -0600, Justin Pryzby wrote:
> On Sat, Feb 12, 2022 at 05:20:08PM -0800, Andres Freund wrote:
> > What was the reason behind moving the docs stuff from the compiler warnings
> > task to linux?
>
> I wanted to build docs even if the linux task fails. To allow CFBOT to link to
> them, so somoene can always review the docs, in HTML (rather than reading SGML
> with lines prefixed with +).

I'd be ok with running the compiler warnings job without the dependency, if
that's the connection.

> BTW, docs can be built in parallel, and CI is using BUILD_JOBS: 4.
> /usr/bin/xmllint --path . --noout --valid postgres.sgml
> /usr/bin/xmllint --path . --noout --valid postgres.sgml
> /usr/bin/xsltproc --path . --stringparam pg.version '15devel' stylesheet.xsl postgres.sgml
> /usr/bin/xsltproc --path . --stringparam pg.version '15devel' stylesheet-man.xsl postgres.sgml

Sure, it just doesn't make a difference:

make -j48 -C doc/src/sgml/ maintainer-clean && time make -j48 -C doc/src/sgml/
real 0m34.626s
user 0m34.342s
sys 0m0.298s

make -j48 -C doc/src/sgml/ maintainer-clean && time make -C doc/src/sgml/

real 0m34.780s
user 0m34.494s
sys 0m0.285s

> > 1) iterate over release branches and see which has the smallest diff
>
> Maybe for each branch: do echo `git revlist or merge base |wc -l` $branch; done |sort -n |head -1
>
> > > > Is looking at the .c files in the change really a reliable predictor of where
> > > > code coverage changes? I'm doubtful. Consider stuff like removing the last
> > > > user of some infrastructure or such. Or adding the first.
> > >
> > > You're right that it isn't particularly accurate, but it's a step forward if
> > > lots of patches use it to check/improve coverge of new code.
> >
> > Maybe it's good enough... The overhead in test runtime is noticeable (~5.30m
> > -> ~7.15m), but probably acceptable. Although I also would like to enable
> > -fsanitize=alignment and -fsanitize=alignment, which add about 2 minutes as
> > well (-fsanitize=address is a lot more expensive), they both work best on
> > linux.
>
> There's other things that it'd be nice to enable, but maybe these don't need to
> be on by default. Maybe just have a list of optional compiler flags (and hints
> when they're useful). Like WRITE_READ_PARSE_PLAN_TREES.

I think it'd be good to enable a reasonable set by default. Particularly for
newer contributors stuff like forgetting in/out/readfuncs, or not knowing
about some undefined behaviour, is easy. Probably makes sense to use different
settings on different tasks.

Greetings,

Andres Freund