Обсуждение: Enable CI on postgres/postgres github repo?

Hi,

Now that the CI patch has been merged [1], perhaps it'd make sense to enable
that on the postgres/postgres mirror on github? See [2] for instructions.

Arguably it doesn't add that much, because cfbot runs builds using the
.cirrus.yml file all the time, but to me it still seems worthwhile: For one,
it actually does run windows builds sooner after a commit than the buildfarm
often does...

Greetings,

Andres Freund

[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=93d97349461347d952e8cebdf62f5aa84b4bd20a
[2] https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob_plain;f=src/tools/ci/README

Dave Page <dpage@pgadmin.org> writes:
> On Tue, Jan 4, 2022 at 11:51 PM Andres Freund <andres@anarazel.de> wrote:
>> Now that the CI patch has been merged [1], perhaps it'd make sense to
>> enable
>> that on the postgres/postgres mirror on github? See [2] for instructions.

> Seems reasonable to me - no cost, and very little effort. I'm happy to set
> it up if noone objects.

I'm kind of down on this actually.  Either it will be a waste of cycles
because no one looks at the reports, or PG hackers will have to learn
to read and interpret a second source of build failure reports.  We have
a lot of accumulated knowledge about the buildfarm, plus ways to examine
past failures, none of which would exist here as far as I've gathered
from experience with the cfbot.  (And the cfbot's reports definitely suck
in usability compared to the farm --- failures often omit critical logs,
and what there is is crammed into a single badly-formatted web page.)

I guess the bottom line for me is "set it up if you want, but don't
expect me to pay any attention to it".

            regards, tom lane

Hi,

On 2022-01-07 14:55:28 +0000, Dave Page wrote:
> On Wed, Jan 5, 2022 at 3:17 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Dave Page <dpage@pgadmin.org> writes:
> > I'm kind of down on this actually.  Either it will be a waste of cycles
> > because no one looks at the reports, or PG hackers will have to learn
> > to read and interpret a second source of build failure reports.

Due to cfbot we kind of have to anyway...


> > We have
> > a lot of accumulated knowledge about the buildfarm, plus ways to examine
> > past failures, none of which would exist here as far as I've gathered
> > from experience with the cfbot.  (And the cfbot's reports definitely suck
> > in usability compared to the farm --- failures often omit critical logs,
> > and what there is is crammed into a single badly-formatted web page.)

It should be a bit better now. All *.log, *.diffs, regress_log* files are
preserved for 90 days for failing testruns. You can navigate to them at the
top of the page of a result.

It's still annoying to see the precise test that failed in a parallel
check-world invocation. But that's a much more general issue than just in CI
checks :(.


> > I guess the bottom line for me is "set it up if you want, but don't
> > expect me to pay any attention to it".

> OK, well from what I can tell, all the reports are delivered on the Cirrus
> or Github sites, so it'll take zero effort to ignore it :-)

I've wondered if it could make sense to forward those reports to the buildfarm
status page, via a dedicated animal. But it doesn't seem that important.


> I've enabled it for the postgres/postgres repo

Thanks!


> https://cirrus-ci.com/github/postgres/postgres/
> 
> There's nothing to see there at the moment; I guess we need a commit to
> trigger a build.

Yep. Happened since: https://cirrus-ci.com/github/postgres/postgres, two
successful runs.

Greetings,

Andres Freund