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
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 |