Commit graph

3 commits

Author SHA1 Message Date
Andres Freund
f52c44ce48 ci: Improve ccache handling
There previously were a number of issues:

- We'd upload the cache even if we already had a high hit rate. That means we
  churn through the available cache space very quickly.

  For this we now check if the cache hit ratio is already high, and skip
  uploading a new cache in that case.

- We'd generate per-branch caches, even if master's already would suffice,
  because the branch doesn't change much

  This is solved indirectly by the above.

- The cache key allowed prefix matches based on the branch,
  e.g. master-pending would always use master's branch

  Replace the cache key element separator of - with :, which is not a valid
  part of a branch name.

- When rebasing a feature branch, we'd start with just that branch's cache,
  rather than also having the newer cache of master available

  This is solved by downloading by master's and the feature branch's cache,
  simply overlaying both. That's possible because ccache is content addressed.

- The size of a cache would increase to the max, even though there likely will
  be no benefit from old cache entries.

  Address this by explicitly evicting old data and also recompressing the
  cache before uploading it.

In my testing this utilizes the available cache space (10GB for personal
accounts) much more effectively than before.

The not entirely trivial determination of whether it's worth uploading a cache
entry is moved to a python script.  I first had it as shell, but that gets
awkward.  This way it'd also be more viable to use ccache for msvc at some
point.

The per-job redundancies are a bit annoying. There's a way around that, by
using composite actions, but I think that might be harder to understand,
without all that much of an improvement.

Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com>
Discussion: https://postgr.es/m/7eugqon2ilnaq6yimtq7prtl5wlia43mhpmwlydzlw4u4wonaz@hh2fagz5bjuu
2026-06-08 15:26:47 -04:00
Andres Freund
9c126063b1 ci: Add GitHub Actions based CI
Cirrus CI, which the project used for CI until now, has shut down on June 1,
2026. Replace it with GitHub Actions. GitHub Actions was selected because it
has unlimited runner time for public repositories.

The GitHub Actions based CI currently covers:

- SanityCheck
- Linux - Autoconf
- Linux - Meson, (32-bit and 64-bit)
- macOS - Meson
- Windows (Visual Studio + Meson and MinGW + Meson)
- CompilerWarnings

BSD coverage is left for later, as it requires more work.

Note that, for performance reasons, use of address sanitizer was moved to the
Linux - Meson (64-bit) task.

While Actions workflows in new forks are disabled by default, existing forks
that pull new changes into the repository will automatically start running
CI. That may not be desired. There however is no way native to Actions to
prevent this.

To avoid that, each repository that wants real CI to run needs to explicitly
opt into doing so, by creating the 'PG_CI_ENABLED' repository variable with
the value 1.

To make that less confusing, emit a summary whenever we skip running CI, with
a message explaining how to enable CI.

The remaining cirrus-ci support will be removed in a subsequent commit, to
make review easier.

Back-branches will be updated later, after being sure that workflow runs
correctly on master.

Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
Author: Andres Freund <andres@anarazel.de>
Author: Jelte Fennema-Nio <postgres@jeltef.nl>
Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com>
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com>
Discussion: https://postgr.es/m/3ydjipcr7kbss57nvi67noplncqhesl5eyb6wgol4ccjxynspv%40yatlykpribmm
2026-06-04 14:55:57 -04:00
Nathan Bossart
dec9d4acdb Add CODE_OF_CONDUCT.md, CONTRIBUTING.md, and SECURITY.md.
These "community health files" provide important information about
the project and will be displayed prominently on the PostgreSQL
GitHub mirror.  For now, they just point to the website, but we may
want to expand on the content in the future.

Reviewed-by: Peter Eisentraut, Alvaro Herrera, Tom Lane
Discussion: https://postgr.es/m/20240417023609.GA3228660%40nathanxps13
2024-07-02 13:03:58 -05:00