cachix-action v14 added a new daemon mode, which pushes new derivations to the store
as soon as they have been built. This replaces the seed cachix workflow nicely by just
pushing from all jobs directly.
By passing -split-sections to all dependencies, GHC will link only the
modules we actually use and not the full package for each dependency.
This does neither work on MacOS nor Windows, thus we don't do it for
stack right now.
Stripping unused symbols in CI will further decrease the size of those files.
Makes it to cache only relevant directories, adds `dist-newstyle` to prevent needless rebuilding even harder and shortens cache key name by supplying `hashFiles`multiple arguments
Recent cabal adopted XDG guidelines and stores data
across multiple directories under $HOME.
Creating ~/.cabal manually returns old behavior and allows caching single directory again.
* ci: try nix-community/cache-nix-action
* ci: add cache-id param to setup-nix action
* ci: tidy up cache keys for non-nix jobs
* ci: merge-nix-caches-linux job
* ci: merge caches other way around
* ci: reduce number of caches
Should prevent disk overflow
* ci: change cache id prefix for merge
* ci: comment out cache merging job
* ci: revert cache id prefix
* ci: setup-nix: use latest cache-nix-action
Among others, makes action logs look more tidy (see https://github.com/nix-community/cache-nix-action/commit/17d19d3d8be918757589635bc1a6830be0b129d2)
* ci: use test-pg cache key for loadtest
This version of hasql-pool is a simplified rewrite that doesn't use
the resource-pool package. The major API changes are that idle
connections are no longer timed out (and the corresponding setting
is gone), and that `release` makes the pool unusable, where it used
to remain usable and only flushed idle connections.
We depend on a PostgREST fork of 0.7.2 that gives us reliable
flushing, compare https://github.com/PostgREST/hasql-pool/pull/1
- hasql-pool 0.7 removes timing out of idle connections, so
this change removes the db-pool-timeout option.
Given that we were typically running with very high
timeout settings, I don't anticipate the lack of timeout
to introduce new issues, though we might want to consider
introducing some retry-logic down the line when we
encounter connection failures.
- See https://github.com/PostgREST/postgrest/issues/2422 for a
discussion on depending on a forked dependency. Besides adding
the dependency to the nix overlay, we're also adding it to
stack.yaml and a new cabal.project to allow stack/cabal users
to build the project.
The idea is that this ensures
1. that it's easy for contributers to hack on PostgREST without
getting nix set up
2. we see things break more easily outside the very controlled nix
environment (e.g. it would be easy to add a GHC 9.4.2 build here)
Wolfgang Walther