A previous commit allowed to select each tool separately on the toolbox.
This commit makes use of that for CI to possibly speed up loading from cachix
a little bit. It will also cause fewer cache misses when nix code is changed.
Resolves#3183
This is to reduce storage requirements for GitHub Actions cache. We already build with GHC 9.4.x
via Nix on Linux x64, via stack on FreeBSD, MacOS and Windows and via Cabal on Linux ARM. That
should cover 9.4.x enough.
The Lint & Style job needs to run on all PRs, not only when something "test" related
changes. Otherwise not all workflow, nix or other files are style-checked and linted.
The enable-executable-static flag is set by default, so doesn't make a difference.
The pkg-config improvement for libpq was merged upstream, so we can use the same
here already.
This documents supported GHC versions. GHC 9.8.1 is currently commented
out to reflect the fact that PostgREST can't currently be built with it
straight from hackage - we still require some overrides in cabal.project
for that.
Splitting the output into separate files and adding top-level newlines makes this
much better to read and understand when looking at diffs.
Inspired by #1699
All those DROP IF EXISTS and CREATE IF NOT EXISTS etc. just give a lot more text to
read and understand. If in fact a user creates the same thing twice, they should be
able to understand the error message from postgres.
The jwt_token type was not created consistently in all examples, which can
be confusing when following those. To return an object with a single key
named token, it's enough to have an OUT parameter to the function.
Resolves https://github.com/PostgREST/postgrest-docs/issues/280
Those were left out of the schema dump when the features were introduced, probably
because ByteString doesn't have a toJSON instance. Changing the type to Text solves
this easily.
Resolves#3237
The obviously wrong statement is, that PostgREST does not support asymmetric keys, while it
does. Extending on this type of attack is not necessary, because it is in fact covered by
the paragraph before - reading the algorithm from the JWT header is the problem in that case,
too. We don't do that.
This leaves us with the sentence about how the chosen library is the most important part. While
that is correct, the hint about high quality libraries for use on the *client* side is mis-
leading: The important part here is the library we choose to implement PostgREST with, not the
client-side lib. Thus, removing the whole paragraph is the best thing to do here.
Resolves https://github.com/PostgREST/postgrest-docs/issues/123
Some users connect PostgREST to the wrong PostgreSQL instance - likely because they are
not even aware that another instance is running. By using the standard port 5432 instead
of 5433, we avoid this problem. The user will be made aware very early that they have
another postgresql instance running - and can solve the problem at this stage. If they
decide to change the port, they are much more likely to remember that in the later stages
of the tutorial, too.
Resolves https://github.com/PostgREST/postgrest-docs/issues/304
Commit 85fbb233 accidentally changed the default socket location in which libpq is
looking for postgresql unix sockets. This is changed in nixpkgs via patch. By imp-
orting the default patches, this is changed back to what it was before. Without
those patches it was changed from /run/postgresql to /tmp.
Not a bugfix, because it was not released, yet.
This moves the _build folder into the repo root, to avoid postgrest-watch ending in an
infinite loop of restarting the build.
Also, for repeated use during development, running linkcheck is not a good idea, this
will quickly result in rate-limiting requests from various servers.
This allows more flexible control over the working directory. Values for workingDir must always start
with a / and will then be relative to the repo root.
Going forward, an uneven minor version will be a development version, while an even minor will be
considered a stable version to be released. This is similar to what GHC does and was discussed in
#3113.
This bump should have happened after branching off v12.0.0, but obviously we didn't know about it
back then. This will happen immediately after branching off a new release from now on.
Previously using a generic mimetype handler failed when any kind of select= was given, because
we tried to cast the select-result to the original table type. With this change, this cast is
only applied when select=* is given implicitly or explicitly. This is the only case where this
makes sense, because this guarantees that correct columns are selected in the correct order for
this cast to succeed.
Resolves#3160
The upside is that postgrest-with-postgresql-xxx postgrest-test-io works as expected
now. The downside is, that postgrest-with-postgresql-xxx psql now starts without
any schema. This now needs an explicit postgrest-with-postgresql-xxx -f path/to.sql
to do anything useful.
Resolves#2864
Removing the condition when migrating the loadtest workflow was not helpufl, this
triggers the report job a few times per pipeline. The goal was to always download
the report, even when the overall pipeline fails because of some other jobs.
Explicitly checking for both success and failure should be enough.
When updating stack.yaml, we need to make sure to update stack.yaml.lock, too.
This check prevents them from getting out of sync by failing CI in this case.
This improves cachability.
The reason why those workflows were split in the first place was just to obtain loadtest
results quicker, because the in the separated workflow, only the single loadtest job
needs to finish before the artifacts can be downloaded.
However, the disadvantage of this approach was, that the results were not as easily
accessible as they could be in a single workflow. Additionally, it's possible to depend
on the "prepopulate nix" job for efficiency if the loadtest runs in the main workflow.
The two different PR and Merge jobs were introduced to be able to test the main branch
against the latest release. However, this is now included in the PR job, too, so no need
for the two separate jobs anymore.
The nix actions cache currently leads to repeated "no space left on
devices" errors for jobs in CI.
The prepopulate job is useless without the nix actions cache, so it
will go away at the same time.
The cache key for nix now depends on default.nix and shell.nix in the root folder and all
.patch files in the nix folder. Those may change the output of our nix derivations, so
must be included. At the same time, there is no reason to include the actions/setup-nix
folder. This would only lead to new caches being created every time we update one of the
dependent actions in this file. Finally, we never restore caches with a different id any-
more. There is no point in having the style job fall back to the static cache for example.
The cache keys for cabal can be more explicit: We only have one postgrest.cabal and one
relevant cabal.project file. We were missing the cabal.project.freeze file, though, which
affects the dependencies used, too.
