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.
When macos-14 was rolled out libpq was not installed, but by now it is
by default. Thus, we don't need to do that, it only creates a warning
annotation right now.
This should fix CI which is failing lately like this:
https://cirrus-ci.com/task/4665005218463744
ld-elf.so.1: /lib/libc.so.7: version FBSD_1.8 required by
/usr/local/bin/stack not found
The schema cache and OpenAPI output would currently list the first found
enum with the same name instead of the correct type. One other case
where this comes up is when a regular type and an enum type have the
same name. For example in the spec fixtures, we have an enum called
"bit". Every "bit" type, no matter whether it's that enum or the
built-in bit type, will show those enum options in the OpenApi output.
Not adding a test, because OpenAPI is supposed to go away in the future
anyway.
Since we changed our release workflow, we have adjusted:
- the docs to use postgrest.org/en/v12/ -style URLs, i.e. only using the
major component.
- the pre-release / devel versions to contain only two instead of four
version parts, i.e. currently 12.3.
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.
This doesn't make sense, because each tag is only pushed when those
pipelines have already passed. Thus, we can save time and avoid wasting
resources and don't run those again.
This happens a commit is pushed to main while the pipelines have not
finished for the previous commit. In this case the devel-tag pipelines
will run concurrently, leading to unpredictable results for the devel
release.
It's very unlikely, but it can (and did) happen that both the server and
admin ports have the same number returned from freeport(). This then
leads to a situation where PostgREST will accept the same port in both
cases, because the host "localhost" will allow binding to ipv4 or ipv6
respectively. This will make the IO tests fail.
This change makes sure that the admin port will never be the same as the
server port and thus avoids this problem.
The $subject commit broke internal_schema_cache_sleep for other tests.
This reverts the order change, but keeps the scaling by x1000 to ms and
thus changes other users of this setting to the new scale.
This changes the postgrest-release tool to work with our new workflow.
It can be run on main and the v* release branches. When on a release
branch, it will bump a patch version and push to that branch only.
When on main, it will bump a minor version by default. To bump a major
version, pass --major. This first bump will be force-pushed to the
v<major> branch. A second bump to the current development version will
then be pushed to the main branch.
The tool will not tag commits anymore - this happens in CI
automatically.
References #3113Resolves#3082
By increasing the delays in this test by factor 400x, postgrest will not
swamp pg with connection retries after the failed schema cache anymore.
This would happen because there is no backoff included after fatal
errors. Once it does, the io tests hang indefinitely in CI.
The statement timeout needs to be cleaned up after each test that
modifies it instead of before the test. Otherwise the changed timeout
leaks into other tests.
Defaulting to max-jobs = auto should improve build times by using more
cores.
Setting always-allow-substitutes to true should cause all nix
derivations to be cached on cachix, which should improve performance of
the MacOS job dramatically, when no rebuilds need to happen.
The release / tag job has logic to decide whether to push a new tag on
stable branches, which depends on the all the tags being fetched. The
checkout action doesn't do that by default, so enable that.
This work by automatically pushing a new tag on main and release
branches after each commit. The tag will be "devel" on main and the
version from postgrest.cabal for release branches. The release
workflow then runs as a tag pipeline, making the actual release.
For release branches, the tag will only be created if a tag for this
version doesn't exist, yet. This means to actually make a new patch
release, we still need to bump the version in postgrest.cabal. We
can automate this later as part of our backport-bot.
Resolves#2006Resolves#2997
This now behaves similar to other CI build jobs, which always run on the
main branches, but only conditionally on PRs, depending on which files
changed.
Using the -latest tag is potentially prone to errors, because an update of the tag
could break our CI. This recently happend with macos-latest, which we downgraded
to macos-12 earlier.
Using an explicit version reference makes this problem much less likely - in fact
renovate will pick up new versions once they exist and will suggest updates for it.
Thus, we will see the failures in a related PR instead of randomly everywhere.
f9ee1f7e introduced the hoisting of function settings as transaction-scoped
settings. However, this currently doesn't work with memory units, which are
case-sensitive according to the docs [1]. This removes the lowercasing of
values to make them work.
This is not added to the CHANGELOG, because this feature was not released, yet.
[1]: https://www.postgresql.org/docs/current/config-setting.html#CONFIG-SETTING-NAMES-VALUES
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
Wolfgang Walther