postgresql/src/tools/ci
Thomas Munro 5f03da8518 ci: Pin MacPorts version to 2.9.3.
Commit d01ce180 invented a new way to find the latest MacPorts version.
By bad luck, a new beta release has just been published, and it seems
to lack some packages we need.  Go back to searching for this specific
version for now.  We still search with a pattern so that we can find the
package for the running version of macOS, but for now we always look for
2.9.3.  The code to do that had been anticipated already in a commented
out line, I just didn't expect to have to use it so soon...

Also include the whole MacPorts installation script in the cache key, so
that changes to the script cause a fresh installation.  This should make
it a bit easier to reason about the effect of changes on cached state in
github accounts using CI, when we make adjustments.

Back-patch to 15, like d01ce180.

Discussion: https://postgr.es/m/CA%2BhUKGLqJdv6RcwyZ_0H7khxtLTNJyuK%2BvDFzv3uwYbn8hKH6A%40mail.gmail.com
2024-07-25 14:48:18 +12:00
..
ci_macports_packages.sh ci: Pin MacPorts version to 2.9.3. 2024-07-25 14:48:18 +12:00
cores_backtrace.sh ci: Add continuous integration for github repositories via cirrus-ci. 2021-12-30 19:02:44 -08:00
gcp_freebsd_repartition.sh ci: freebsd repartition script didn't copy .git directory 2024-03-24 08:41:14 +01:00
pg_ci_base.conf ci: Add continuous integration for github repositories via cirrus-ci. 2021-12-30 19:02:44 -08:00
README ci: Make compute resources for CI configurable 2023-08-23 15:15:28 -07:00

Postgres Continuous Integration (CI)
====================================

Postgres has two forms of CI:

1) All supported branches in the main postgres repository are continuously
   tested via the buildfarm. As this covers only the main repository, it
   cannot be used during development of features.

   For details see https://buildfarm.postgresql.org/

2) For not yet merged development work, CI can be enabled for some git hosting
   providers. This allows developers to test patches on a number of platforms
   before they are merged (or even submitted).


Configuring CI on personal repositories
=======================================

Currently postgres contains CI support utilizing cirrus-ci. cirrus-ci
currently is only available for github.


Enabling cirrus-ci in a github repository
=========================================

To enable cirrus-ci on a repository, go to
https://github.com/marketplace/cirrus-ci and select "Public
Repositories". Then "Install it for free" and "Complete order". The next page
allows to configure which repositories cirrus-ci has access to. Choose the
relevant repository and "Install".

See also https://cirrus-ci.org/guide/quick-start/

Once enabled on a repository, future commits and pull-requests in that
repository will automatically trigger CI builds. These are visible from the
commit history / PRs, and can also be viewed in the cirrus-ci UI at
https://cirrus-ci.com/github/<username>/<reponame>/

Hint: all build log files are uploaded to cirrus-ci and can be downloaded
from the "Artifacts" section from the cirrus-ci UI after clicking into a
specific task on a build's summary page.


Images used for CI
==================

To keep CI times tolerable, most platforms use pre-generated images. Some
platforms use containers, others use full VMs. Images for both are generated
separately from CI runs, otherwise each git repository that is being tested
would need to build its own set of containers, which would be wasteful (both
in space and time.

These images are built, on a daily basis, from the specifications in
github.com/anarazel/pg-vm-images/


Controlling CI via commit messages
==================================

The behavior of CI can be controlled by special content in commit
messages. Currently the following controls are available:

- ci-os-only: {(freebsd|linux|macos|windows|mingw)}

  Only runs CI on operating systems specified. This can be useful when
  addressing portability issues affecting only a subset of platforms.


Using custom compute resources for CI
=====================================

When running a lot of tests in a repository, cirrus-ci's free credits do not
suffice. In those cases a repository can be configured to use other
infrastructure for running tests. To do so, the REPO_CI_CONFIG_GIT_URL
variable can be configured for the repository in the cirrus-ci web interface,
at https://cirrus-ci.com/github/<user or organization>. The file referenced
(see https://cirrus-ci.org/guide/programming-tasks/#fs) by the variable can
overwrite the default execution method for different operating systems,
defined in .cirrus.yml, by redefining the relevant yaml anchors.

Custom compute resources can be provided using
- https://cirrus-ci.org/guide/supported-computing-services/
- https://cirrus-ci.org/guide/persistent-workers/