Re: Commitfest 2020-11 is closed

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: David Steele <david(at)pgmasters(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Commitfest 2020-11 is closed
Date: 2020-12-08 20:46:16
Message-ID: CA+hUKGLctyLSrf8hDe_7+ncrmhbMRq44KNvMtyyMrUR179-Uzg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 4, 2020 at 1:29 AM Peter Eisentraut
<peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
> On 2020-12-02 23:13, Thomas Munro wrote:
> > I'm experimenting with Github's built in CI. All other ideas welcome.
>
> You can run Linux builds on AppVeyor, too.

Yeah. This would be the easiest change to make, because I already
have configuration files, cfbot already knows how to talk to Appveyor
to collect results, and the build results are public URLs. So I'm
leaning towards this option in the short term, so that cfbot keeps
working after December 31. We can always review the options later.
Appveyor's free-for-open-source plan has no cap on minutes, but limits
concurrent jobs to 1.

Gitlab's free-for-open-source plan is based on metered CI minutes, but
cfbot is a bit too greedy for the advertised limits. An annual
allotment of 50,000 minutes would run out some time in February
assuming we rebase each of ~250 branches every few days.

GitHub Actions has very generous resource limits, nice UX and API, etc
etc, so it's tempting, but its build log URLs can only be accessed by
people with accounts. That limits their usefulness when discussing
test failures on our public mailing list. I thought about teaching
cfbot to pull down the build logs and host them on its own web server,
but that feels like going against the grain.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-12-09 00:34:03 Re: [HACKERS] [PATCH] Generic type subscripting
Previous Message Tom Lane 2020-12-08 18:28:39 Re: get_constraint_index() and conindid