Horton
Menu

Re: Adding CI to our tree

Thomas Munro <thomas.munro@gmail.com>

View thread
From: Thomas Munro <thomas.munro@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: 0010203112132233 <boekewurm@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Andrew Dunstan <andrew@dunslane.net>
Date: 2021-10-02T02:41:13Z
Lists: pgsql-hackers 
On Sat, Oct 2, 2021 at 1:10 PM Andres Freund <andres@anarazel.de> wrote:
> On 2021-10-02 01:49:39 +0200, 0010203112132233 wrote:
> > Furthermore, after looking it through, I think that Cirrus is an
> > unfortunate choice as a CI platform of preference, as you cannot use
> > it without access to Github (which is problematic for people located
> > in certain localities due to USA regulations).
>
> I agree that it's not optimal that cirrus isn't available on all git hosting
> platforms. Hence saying that I think it's likely we'd end up adding a few more
> platforms over time.  If we factor the meat of the work into an helper script,
> so that the CI specific bit is just a couple invocation of that script, it's
> not a lot of overhead to have 2-3 CI platforms.

BTW I think they might be considering supporting other code hosting
platforms (at least they ask for feedback on this at
https://cirrus-ci.org/guide/quick-start/ ).

> > Lastly, I consider CI configuration similar to IDE configuration: each
> > developer has their own preferred tools which they use, but we don't
> > favour one over the other. We don't include IDE-specific configuration
> > files either, or at least, the policy is against that.

We have some files in the tree to help users of Emacs, vim, and even
make github format text the way we like.

Personally, I think that if someone is willing to develop and maintain
high quality CI control files that work for any public
free-for-open-source CI system, then we should accept them too.  It
costs very little to have a few .something.yml files at top level.  If
at any point the file for a given provider is showing signs of being
unmaintained, we can remove it.  Personally, I'm willing and able to
help maintain Cirrus control files, not least because it means that
cfbot will become simpler and will match exactly what you can get in
your own github account.

I really like Cirrus because our project has more portability concerns
than most, and most other CIs are like "we got both kinds, country and
western!".  I wanted to add FreeBSD to cfbot, which is something they
advertise as a feature, but it looks like at least 3 other OSes we
target would probably work just as well given a suitable image.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. ci: enable zstd where available.

  2. ci: compile with -Og where applicable.

  3. ci: include hints how to install OS packages.

  4. ci: fix copy-paste mistake in 16eb8231d1b.

  5. ci: macos: align sysinfo_script to other tasks.

  6. ci: Only use one artifact instruction for logs.

  7. ci: s/CCACHE_SIZE/CCACHE_MAXSIZE/.

  8. pg_basebackup: Skip a few more fsyncs if --no-sync is specified.

  9. TAP tests: check for postmaster.pid anyway when "pg_ctl start" fails.

  10. Don't enable fsync in src/test/recovery/t/008_fsm_truncation.pl.

  11. ci: windows: run initdb with --no-sync.

  12. ci: windows: enable build summary to make it easier to spot warnings / errors.

  13. ci: Add continuous integration for github repositories via cirrus-ci.

  14. Fix TestLib::slurp_file() with offset on windows.