What type of enhancement is this?
Other
What subsystems and features will be improved?
Build system
What does the enhancement do?
If I take a tarball of the timescaledb repo and use it to build the extension, as PGDG rpm packages are built (Source0), and deb packages as well (notice no .git), then the function get_git_commit() returns an error when it's called:
postgres=# select * from _timescaledb_functions.get_git_commit();
ERROR: extension not built with any Git commit information
This is fine as far as behavior is concerned (though one could argue in favor of a line with null values or an empty set, but I don't quite care about it). And it's how PGDG packages all behave in production.
But in these same scenarios when we are building the extension from a tarball and we try to run all the tests, then both tsl/test/shared/sql/build_info.sql and tsl/test/shared/sql/compat.sql FAIL, even though the ERROR output is intentional and by design.
I don't think it it's fair to ask the packagers to fetch the code from git in order to get the function to output anything different or to make tests pass. In fact, they already use git, but they fetch the tarball from the /archive/ URL of git or they generate from git archive. And the use of a tarball is very much intentional, as it allows offline building, reproducible builds, protects them from upstreams changing tags etc.
And I don't think it's very nice for tests to fail because they throw a different, expected, output. It deters packagers from running fuller test sets that the extension makes available.
Implementation challenges
I'm not really sure what the best solution to this is, but I'd like a full test run from a tarball to run to completion successfully just as it does when it runs from a git clone of the project. Doing so will invite more people to running the full test set whenever they can which, in my experience, has helped surface bugs in this and other projects.
I'm leaning towards adding an alternate output to those two tests (<test>_1.out), so that even the ERROR lines lead to a successful end of the test set.
But I'd appreciate some discussion on the idea first. I'll gladly send a PR if there is consensus on a direction that reaches the goal of running tests cleanly from tarballs.
What type of enhancement is this?
Other
What subsystems and features will be improved?
Build system
What does the enhancement do?
If I take a tarball of the timescaledb repo and use it to build the extension, as PGDG rpm packages are built (Source0), and deb packages as well (notice no .git), then the function
get_git_commit()returns an error when it's called:This is fine as far as behavior is concerned (though one could argue in favor of a line with null values or an empty set, but I don't quite care about it). And it's how PGDG packages all behave in production.
But in these same scenarios when we are building the extension from a tarball and we try to run all the tests, then both
tsl/test/shared/sql/build_info.sqlandtsl/test/shared/sql/compat.sqlFAIL, even though the ERROR output is intentional and by design.I don't think it it's fair to ask the packagers to fetch the code from git in order to get the function to output anything different or to make tests pass. In fact, they already use git, but they fetch the tarball from the /archive/ URL of git or they generate from
git archive. And the use of a tarball is very much intentional, as it allows offline building, reproducible builds, protects them from upstreams changing tags etc.And I don't think it's very nice for tests to fail because they throw a different, expected, output. It deters packagers from running fuller test sets that the extension makes available.
Implementation challenges
I'm not really sure what the best solution to this is, but I'd like a full test run from a tarball to run to completion successfully just as it does when it runs from a git clone of the project. Doing so will invite more people to running the full test set whenever they can which, in my experience, has helped surface bugs in this and other projects.
I'm leaning towards adding an alternate output to those two tests (
<test>_1.out), so that even the ERROR lines lead to a successful end of the test set.But I'd appreciate some discussion on the idea first. I'll gladly send a PR if there is consensus on a direction that reaches the goal of running tests cleanly from tarballs.