I doubt that anyone would use cabal2nix or update-nix-fetchgit manually
- and at the same time everyone surely has git installed through their
OS anyway, otherwise they can't even get that far.
There is no point to actually realize the derivations to disk, when they
are in cache. `nix-build-uncached` checks the cache and stops before
downloading dependencies if they are available. It will however build as
normal on a cache-miss. Should speed up CI when no Nix dependencies
change a fair bit.
We can only do this for the MacOS job, which only tests the builds. We
can not do this for other jobs which require the build results to be
present before uploading parts of them as artifacts.
These should have been updated by postgrest-nixpkgs-upgrade, when I
upgraded the Nixpkgs pin, but I did not follow my own readme, and just
ran nix flake update...
My recent commit to fix the stack cache on macOS only changed the
restore keys, but no cache would ever be saved that way. I effectively
disabled all caching...
Unfortunately, `docker manifest create` does not support image digests,
so we need to push a tag for each version of the image. Furthermore, the
docker CLI does not provide a way to delete that tag afterwards, so we
will end up with those temporary tags.
We now have two stack jobs for macOS, but they use the same cache, which
is very inefficient. Adding the architecture to the cache key will give
each of these jobs a separate cache.
Jumping past GHC 9.6, 9.8 and 9.10 immediately, because these versions
do not successfully build the static binary with TemplateHaskell and
iserv-proxy, yet.
Michal wrote the changes to hsie.
Co-authored-by: Michal Kleczek <michal@kleczek.org>
These don't really make sense, because it's non-trivial to construct a
build plan that *ensures* the dependency that renovate creates a PR for
is tested with the latest version. Cabal might just select a build plan,
that doesn't include the dependency, in which case we could just as well
have no upper bounds at all.
Since there is no good way to test these changes (I tried, a while
ago!), let's just disable these PRs. They are more annoying than
anything else.
I'm not sure whether that's Lix specific, but when I enter nix-shell, I
get quite a long TMPDIR, which results in all postgrest-with-pg-XX
scripts failing, because the unix socket path is too long. If TMPDIR was
not set, mktemp would fall back to /tmp, so we can just do that in any
case, which guarantees a short path in every case.
The x86 GitHub runner will not be available anymore, soon.
We might be able to re-introduce this, once we can build a static
executable via Nix on darwin, too.
This way we benefit from NixOS' binary cache to deliver GHC for us and
don't need to cache it ourselves.
This will become relevant once we do that for more platforms.
We have fixed the static build of PostgreSQL upstream, so we don't need
our separate overlay anymore. One more step towards building a static
executable on other platforms.
Instead of rolling our own, we can use some tooling from nix / nixpkgs.
We drop the "statically linked" check, because our goal is to compile
mostly-static executables to darwin, too. However, those will never be
fully static, because they always link to the platform's libc.
The dependency on it was removed in #3608 already, but we forgot to
remove it from postgrest.cabal, which caused it to still be built.
We didn't realize because all references of it were stripped away by
dead code elimination anyway.
Previously, the loadtest would always compare against main and the
latest tag. This meant a loadtest running on the v13 release branch,
would compare to a *future* version of both. This is not useful, and
also not supported by `postgrest-loadtest-against`, which recently
introduced a change on `main`, that now breaks the tests on the back
branches.
With this change, the loadtest will always run against the current
target branch of a PR, so against the v13 branch for a PR against v13,
for example. Also, it will compare against the latest released tag *for
that branch*.
Thus, when running this for v12, it will test against the v12 branch and
the v12.2.12 tag.
Splitting the executable in a separate output avoids distributing all of
the libraries and documentation, which are not needed when just running
PostgREST.
Reduces closure size from 4.3G to 73.9M for the flake exported packages.
Resolves#4149
Moat has been bought by Oracle. The advertising subpage redirects to
oracle.com, but pointing at that would be a bit misleading.
No need to keep failing links either.
This also moves the pin for nixpkgs into flake.lock instead of our
custom file. Even for the classic interface via default.nix, the pin
will be loaded from flake.lock, thus everything stays in-sync.
This just exposes the PostgREST package, not more.
The goal is to avoid duplication, so we're re-using only exports from
default.nix.
Resolves#3026
Supersedes #3105
We never need dynamic haskell libraries, because even the dynamic builds
only dynamically link non-haskell dependencies, but always link haskell
dependencies statically.
Profiled libraries are only required when running the memory test, so
explicitly enable them for the profiled package.
This also means, that we don't need to hide the memory test behind a
feature flag anymore. The reason always was assumed to be the big number
of rebuilds required for it. I assume ever since we moved off of
static-haskell-nix and back to nixpkgs-based builds, we have been
building profiled libraries for all our dependencies anway.
I removed those exceptions earlier this week, because I got fooled by my
local test output. Those only return 403 in GitHub Actions - it seems
like those websites block access from there.
Apparently Cirrus removed the 14-1 image. When I firsted looked into
this some days ago, when the job started failing, the docs were not
updated, yet - so it wasn't clear. Now the docs mention freebsd-14-2
explicitly...
This manager was recently introduced to renovate and is now creating PRs
for upper version bounds of our haskell dependencies. We still need to
figure out how to deal with those in the best way, but some basic
configuration can already be done. Here, we:
- disallow any of those updates on the backbranches.
- group GHC-provided dependencies together.
- group packages from the hasql ecosystem together.
- the fuzzyset dependency must be restricted to <0.3 - we know that
already and did that on purpose.
Apparently the STACK_ROOT has been moved to C:\sr - for unknown reasons,
at least to me.
This should enable caching again and make the stack on windows builds
much faster than recently.
Wolfgang Walther