This seems to happen on nix 2.22 only, v2.21 in CI and v2.20 locally work fine. The error is:
vendor folder is empty, please set 'vendorHash = null;' in your expression
For full logs, run 'nix-store -l /nix/store/kxnnr344n7gsxzc6kycj19hs19rvddjj-slocat-go-modules.drv'.
error: 1 dependencies of derivation '/nix/store/x9w480k36a11i99m6zp12d5cjijsn3lm-slocat.drv' failed to build
Since the slocat module doesn't actually have any dependencies, this shouldn't matter much.
Those create annoying "cancelled" notifications which looks like CI on
main was failing. It's not, though.
By just disabling the cancel-in-progress setting, but keeping the group
intact, this should queue multiple tag jobs / tag workflows behind each
other and still avoids the underlying problem which occurs when running
them in parallel.
This action makes sure to always have the correct GHC and/or stack
version installed in all environments. This solves problem where ghc or
stack might not be available on newer macos images anymore or where
ghcup is not available by default on our new custom github runner on
arm.
This is a first step to split up the cabal and stack caches in separate
pieces. Here we split the work folder, which just contains the
postgrest-specific build artifacts, into a separate cache.
More fine-grained caching should give us better cache hits and much
fewer upload size in the regular case, improving CI performance.
Since the work file caches are very small (about 30-40 MB) they are
cached for PRs, too. This will allow the majority of PRs, which only
change source code files, but no dependencies, to still have cached
their build files for additional commits.
This restores caches on all branches and pull requests, but only stores
them on the main branch and release branches. This prevents those caches
from being evicted early when we hit the 10 GB limit quickly.
Update hasql-notifications to include the fix on
https://github.com/diogob/hasql-notifications/issues/24.
Which now reveals the following error:
```
$ postgrest-with-postgresql-16 --replica -f test/spec/fixtures/load.sql postgrest-run
17/May/2024:18:35:38 -0500: Successfully connected to PostgreSQL 16.2 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 13.2.0, 64-bit
17/May/2024:18:35:38 -0500: Could not listen for notifications on the "pgrst" channel. ERROR: cannot execute LISTEN during recovery
17/May/2024:18:35:38 -0500: Retrying listening for notifications...
```
This is still not good because the LISTEN channel will be retried
forever without a backoff.
When using `postgrest-with-postgresql-* --replica`, the PGRST_DB_URI
will set the replica host as preference. This to be able to run
quick manual tests with postgrest running on a replica.
steve-chavez