From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: Adding CI to our tree |
Date: | 2021-10-01 23:04:03 |
Message-ID: | CAH2-WzkzwQj2=9vSeO8w_irTsbdJKJwpFy9ceNT=S7i-3BA4Kg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 1, 2021 at 3:28 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> For several development efforts I found it to be incredibly valuable to push
> changes to a personal repository and see a while later whether tests succeed
> on a number of different platforms. This is especially useful for platforms
> that are quite different from ones own platform, like e.g. windows in my case.
> An obvious criticism of the effort to put CI runner infrastructure into core
> is that they are effectively all proprietary technology, and that we should be
> hesistant to depend too much on one of them. I think that's a valid
> concern. However, once one CI integration is done, a good chunk (but not all!)
> the work is transferrable to another CI solution, which I do think reduces the
> dependency sufficiently.
I agree with everything you've said, including the nuanced parts about
the possible downsides.
We already know what happens when one of these CI providers stops
providing open source projects with free resources, because that's
exactly what happened with Travis CI: projects that use their
infrastructure are mildly inconvenienced. I can't see any real notable
downside, as long as we just use the resources that they make
available for development work. Clearly these services could never
replace the buildfarm.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Burke | 2021-10-02 00:09:17 | Better context for "TAP tests not enabled" error message |
Previous Message | Andres Freund | 2021-10-01 23:02:27 | Re: PATH manipulation in 001_libpq_pipeline.pl fails on windows |