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