Versions in the build matrix with significant leading/trailing zeroes
need the version string quoted otherwise it will get treated as number
and those zeroes will be removed. As currently those tests fixed by
this patch run PG 11.1 instead of 11.10.
The command `get_git_commit` shows quite a little information and
especially if mistakes are made it is hard to verify what the binary is
actually based on.
This commit extends the function to provide some more information:
specifically the SHA of the HEAD regardless of whether there is a tag
on it or not and the time for the HEAD commit.
```
postgres=# select * from _timescaledb_internal.get_git_commit();
commit_tag | commit_hash | commit_time
--------------------------+-------------+------------------------
1.7.4-10-g09b0b778-dirty | 09b0b778 | 2020-09-13 17:50:38+02
(1 row)
```
If git is not installed, the function `get_git_commit` will return an
error indicating that no git information is available. If some of the
fields are available, they will be emitted and the remaining fields
will be NULL.
Fixes#2457
The latest update test refactoring renamed some of the output files
to better state their origin but not all places in the github
workflow were adjusted to handle the new names.
Disable NOTICE messages for time based tables in
continuous_aggs_policy test. The refresh sometimes
does not have anything to update as the intervals
are computed based off now(). This causes intermittent
failures due to NOTICEs that the cagg is up to date.
Remove continuous_aggs_policy from ignores list in CI
scripts.
This patch changes the update test to use the same checks
between clean / updated install and dumped/restored install.
Previously only a small subset of the checks would be run against
the updated instance and most of the tests would only run against
the dumped and restored container.
During migration of CI from travis to github actions running
postgres regression test suite was missed. This patch changes
our regression workflow to run postgres regression test suite
as well.
Tests are updated to no longer use continuous aggregate options that
will be removed, such as `refresh_lag`, `max_interval_per_job` and
`ignore_invalidation_older_than`. `REFRESH MATERIALIZED VIEW` has also
been replaced with `CALL refresh_continuous_aggregate()` using ranges
that try to replicate the previous refresh behavior.
The materializer test (`continuous_aggregate_materialize`) has been
removed, since this tested the "old" materializer code, which is no
longer used without `REFRESH MATERIALIZED VIEW`. The new API using
`refresh_continuous_aggregate` already allows manual materialization
and there are two previously added tests (`continuous_aggs_refresh`
and `continuous_aggs_invalidate`) that cover the new refresh path in
similar ways.
When updated to use the new refresh API, some of the concurrency
tests, like `continuous_aggs_insert` and `continuous_aggs_multi`, have
slightly different concurrency behavior. This is explained by
different and sometimes more conservative locking. For instance, the
first transaction of a refresh serializes around an exclusive lock on
the invalidation threshold table, even if no new threshold is
written. The previous code, only took the heavier lock once, and if, a
new threshold was written. This new, and stricter locking, means that
insert processes that read the invalidation threshold will block for a
short time when there are concurrent refreshes. However, since this
blocking only occurs during the first transaction of the refresh
(which is quite short), it probably doesn't matter too much in
practice. The relaxing of locks to improve concurrency and performance
can be implemented in the future.
Since GitHub updated the macos image used for CI it updated llvm
to a version that is buggy on macos. So this patch disables building
postgres with llvm support on macos. It also fixes the cache suffix
code for macos because it changed with the latest runner version,
and uses the image version now as cache suffix.
https://bugs.llvm.org/show_bug.cgi?id=47226
This patch changes the update test to run on PG 11.8 and 12.3 instead
of 11.0 and 12.0. This patch also adds additional diagnostic output
when errors occur during the update test.
Migrate the travis coverity config to github actions. This new workflow
will depend on the cached postgres build of the main regression workflow
so we don't have to duplicate the build matrix in this workflow. Since
the main regression workflow runs at least once a day there should
always be a cache hit. In case of a cache miss this workflow will abort.
Since there is a quota on coverity runs this workflow is configured to
run once a week every saturday. Additional runs can be triggered by
pushing to the coverity_scan branch.
On macOS the path used is depending on the runner version leading to cache
failure when the runner version changes or is different from the one used to
build the cache. This patch extracts the runner version and adds it as
suffix to the cache key on macOS.
This workflow will install our rpm packages and then try to enable
timescaledb in the database and also check the version installed
from the package against the expected version.
This workflow will install our apt package and then try to enable
timescaledb in the database and also check the version installed
from the package against the expected version.
When either TESTS, SKIPS or IGNORES is set for a regression check
run we would generate a new temporary schedule based on those
variables without any parallelity. This patch changes the behaviour
to keep the original test schedule when only IGNORES is specified
and just prepend the ignore lines to a copy of the original schedule.
This patch adds collecting coredumps to the regression workflow
in addition to the binary all shared libraries used by the coredump
are collected as well.
Check for coredumps and only execute the stracktrace if there are
actually coredumps. This patch also changes the log handling to
always collect logs and upload them cause they might have useful
information even when all steps succeed. Additionally a list
of all failed tests is shown before the regression diff.
This patch also disables fail-fast so a single failed job does
not cancel other jobs still in progress.
Since within a workflow artifacts share a namespace we need to make
sure artifacts have a unique name within the workflow so other
runs in the same workflow don't overwrite artifacts.
When fail-fast is true a single failing job will cancel
the entire workflow which is not desirable for scheduled runs
and the code style tests. This patch changes fail-fast
to false for the code style tests and the scheduled i386 tests.
It also changes the different code style check steps to always
run.
PostgreSQL 12 is preinstalled, while 11 is not. To unify different
paths of PG 11 and 12 binaries, this commit implements workaround by
forcing installation of PostgreSQL 12, so it is in the same path as
PostgreSQL 11.
Since we want to run additional test configurations when triggered
by a push to prerelease_test or by cron but github actions don't
allow a dynamic matrix via yaml configuration we generate the matrix
with a python script. While we could always have the full matrix
and have if checks on every step that would make the actual checks
harder to browse because the workflow will have lots of entries and
only by navigating into the individual jobs would t sit be visible
if a job was actually run.
Additionally we set fail-fast to true for pull requests and false
for other event types.
This patch adds a slack notification on failed i386 tests.
Unfortunately most slack actions don't work with the 32bit
image so our options for better styling/costumisation are
somewhat limited.
This patch removes code support for PG9.6 and PG10. In addition to
removing PG96 and PG10 macros the following changes are done:
remove HAVE_INT64_TIMESTAMP since this is always true on PG10+
remove PG_VERSION_SUPPORTS_MULTINODE
Windows builds, for Debug and Release configurations, are now tested
using GitHub Actions. The build test covers all currently supported
PostgreSQL versions (9.6, 10, 11, 12) using a build matrix.
Currently, the TimescaleDB regression test suite is not run since it
requires a Windows-specific test client that we do not
support. Instead, the binaries are tested by doing a `CREATE
EXTENSION` to verify that they load and run without, e.g., missing
symbols or similar.
The test configuration is optimized for speed by using a cache for the
PostgreSQL installation. This avoids repeated downloads and
installations of PostgreSQL from EnterpriseDB's servers. But it also
means that we won't have a full installation on cache hits, which
means no running PostgreSQL service. This requires manual PostgreSQL
starts, which is what we want anyway since we need to preload our
extension.
It's anticipated that this build configuration can be extended to
produce release binaries in the future.
