Re: Adding null patch entry to cfbot/CommitFest

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: david(dot)g(dot)johnston(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Adding null patch entry to cfbot/CommitFest
Date: 2025-05-20 05:39:46
Message-ID: 20250520.143946.1690749256047253821.ishii@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> I too made this realization while reviewing the application. I concur it
>> is something that we should try and mitigate. Sending a canary patch
>> through once-a-day, or on any fixed time period, doesn’t quite seem
>> sufficient.
>
> Yeah, I'm afraid that won't do much except eat valuable cycles.
>
> IME the real problem with the CI tests is that the CI infrastructure
> itself is not very stable, and intermittently fails tests for reasons
> having little to do with the tested patch *or* the state of the master
> branch.

I am not sure. Cfbot seems to run tests for a particular patch every
day until it fails. (Once tests failed, it seems Cfbot sleep 10 days
or so if a patch is unchanged). If CI is that unstable, we should see
random failure day by day even if the patch is unchanged.

> If there is a problem in master, we typically know it because
> the buildfarm is also unhappy, so I'm not clear on what a null patch
> in the queue would add.

The particular CF test I am seeing failure is "Windows - Server 2019,
VS 2019 - Meson & ninja". As far as I know there's no equivalent
animal in the buildfarm.

Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2025-05-20 05:40:14 Re: Conflict detection for update_deleted in logical replication
Previous Message Michael Paquier 2025-05-20 05:09:13 Re: Add comment explaining why queryid is int64 in pg_stat_statements