Add CI test and PGXN release workflows

[theory]

Also ignore bitcode and darwin dylib files, and make the PostgreSQL version a valid SemVer in META.json.

Note that there are some test failures on PostgreSQL 17, as in this run. I can remove testing on 17 for now if you'd like.

To make a release, you'll need to set the PGXN_USERNAME and PGXN_PASSWORD secrets in your project here and then push a tag with the semver for the release. To make a release without a tag, comment-out the tags: [v*] line in release.yml, push, wait for it to succeed, then restore that line to only release on tags in the future.

[keithf4]

So the failure here isn't PG17 specific. If you read the commends in the 30sec test, it can fail depending on the time it's run. If it fails and you wait until the next 30 second block, it then succeeds. I haven't found any way to fix this consistently because it's all about which child tables it happens to create within a very short given timeframe.

I used to have a lot of other tests with known failures in it as well that depended on the version of PG whether it would fail or not. Not sure if you have ways to run specific tests with specific versions of PG or to skip some tests all together that will likely never succeed consistently like this 30sec time one.

[theory]

The pattern I've seen in Perl modules is to put author-only tests in a separate directory, usually xt, like here. Then just run them separately as part of some other job, or manually when you need to.

[keithf4]

So I guess it would seem that any test within a folder isn't getting tested here then? Because the procedure and tablespace tests in their own folders need out-of-bound commands run along with them. I'll just make a test_manual folder and throw the 30-second one in there.

[theory]

Oh, no! Should we pass the --recurse option to run tests in subdirectories?

In Perl modules, public tests live in the top-level t directory, while developer tests (excluded from the distribution) live in the top-level xt directory.

[keithf4]

Some of the the tests in the subdirectories are not going to run automatically. Things like stored procedures cannot be tested with a single pgtap call. Probably just be best to explicitly run the specific subdir tests that can be run

test_no_search_path is the only I think will work. test_bgw requires that the background worker be enabled and specific GUCs set test_nonsuperuser requires specific non-superuser roles to be created test_procedure cannot be called as a single tap test. manual commands between each tap test that call stored procedures have to be run. test_tablespace requires that a specific tablespace be set up

Instructions for running each test can be found in the tests in that folder. Is there a way to set those environments up?

[theory]

Instructions for running each test can be found in the tests in that folder. Is there a way to set those environments up?

Probably, yes, but each one will take a bit of fuss. You can run separate CREATE_OPTIONS to specify pg_createcluster options:

test_bgw requires that the background worker be enabled and specific GUCs set

Use CREATE_OPTIONS="--pgoption ... to set the GUCs

test_nonsuperuser requires specific non-superuser roles to be created

Use createuser to create the roles.

test_procedure cannot be called as a single tap test. manual commands between each tap test that call stored procedures have to be run.

Not so sure about this one, but you might be able to use \! [ command ] in the test script to invoke such commands from inside psql.

test_tablespace requires that a specific tablespace be set up

Use psql to create the tablespaces before running the tests?

[theory]

But you might want to consider just starting with what works here as an improvement on the status quo, and gradually add support for the others over time (modulo the ones that you expect to fail, of course).

[keithf4]

Do things run ok now on the development branch? I moved the one failing one to its own folder. We can work on fixing the others later, but would be good to get this initial PR in and working

[theory]

Looks like this commit is not represented in the development branch. Do you want me to try rebasing?

[theory]

I rebased, watching the build…

[theory]

All the tests passed! 🎉