| Age | Commit message (Collapse) | Author |
|---|
|
Just so that I'm not using both in the same file. :)
|
|
As Turtl's codebase continues to be left unmaintained, more and more build
issues appear with it due to changes in Rust. Like with rusqlite, recently the
url library started experiencing build issues with the current Rust compiler.
So I added another patch to update the url version from v1.6.0 to v1.7.2, which
appears to work around the issue. There's still an ever increasing amount of
build warnings, though all of the unit and integration tests still pass, so for
now, its probably okay.
I didn't update it to the latest version because, like with rusqlite, I was
worried about the possibility of API-breaking changes that would require
patching the source code to fix.
The long-term fix for this would of course be for me to actually learn Rust and
its packaging system, and then update all of the dependencies to the latest
versions (dealing with and fixing compiler errors/warnings as I go) and then
sending it as a pull request to the core-rs repository on GitHub.
But for now, this is really all I can do. :(
The pkgrel has been bumped to 5 for this change, as it results in a different
binary then previously.
|
|
|
|
|
|
Rather than using the system plugins directory for the Turtl server
(which may have plugins that can interfere with the integration tests)
we make a blank plugins directory within the source tree that prevents
such plugins from being loaded.
|
|
The tests that were hanging all had a feature in common - they were
trying to synchronise a file from the server, and this is what the
tests were getting stuck on. For some reason, files will not sync when
the server is accessed from localhost (127.0.0.1) - this was also
noticed when I tried connecting the official Turtl client to the test
server - the file attachment wouldn't sync. What makes this even
stranger is that, although file syncing doesn't work from 127.0.0.1,
it works just fine when the server is accessed via 127.0.1.1 instead.
I'm not sure if this is an upstream bug or if it's a problem with my
personal setup, but for now, I've worked around the issue by manually
specifying 127.0.1.1 as the API/hosting endpoint in both of the test
configuration files.
Now all of the integration tests (except migrate, of course) pass!
|
|
Previously, the integration tests were able to find the built core-rs
library automatically, however this no longer seems to be the case.
To work around this, I've exported the path to turtl_core.so into
LD_LIBRARY_PATH which once again allows the tests to find the library.
|
|
This version of core-rs depends on rusqlite version 0.13.0, which
cannot be built on current versions of rust. I have added a patch to
update all instances of rusqlite to version 0.14.0, the first release
to contain the fix for newer compiler versions.
|
|
* The integration tests (which actually communicate with the Turtl server) are
now run during the check() step in addition to the regular unit tests.
* Some of the integration tests do not work (authentication error resulting in
the test repeatedly trying and failing to sync with the server) and I have no
idea why, so for now those tests have just been disabled.
* Change the provided server configuration to allow unconfirmed invites, to
allow the respective integration test to work
* I now export the OpenSSL paths directly rather than using vars.mk
* The 'make' calls have been replaced with direct calls to 'cargo'
|
|
|
|
* For the core-rs tests, this is simply copying a pre-made file instead of
using sed to patch the template configuration.
* For the server, this is a little bit harder. The server does not support
loading a custom configuration from anywhere on the system, so I copy all of
the server's JavaScript files into a directory within $srcdir, copy the
custom configuration and then launch the server from within $srcdir.
* This has the benefit of ensuring that the servers are running with a fully
custom configuration, rather than using exported variables and sed patches
against a user-controlled config.
|
|
* The check() step has been divided into "modules" which can be run
independently of each other.
* This then allows the individual steps (create directories -> initialise
database cluster and start SQL server -> configure database and start Turtl
server -> generate configuration and run tests -> shut down Turtl server ->
shut down SQL server -> remove directories) to be run individually, with
traps set up to perform the necessary de-initialization should one step fail.
* This is important as makepkg's default behaviour is to stop as soon as a
command returns with a non-zero exit code. Trapping errors in this manner
allows us to perform the proper database and server cleanup regardless of
whether or not the tests succeeded.
* The output of commands is also no longer redirected to /dev/null, and the
log messages are bolded and coloured to look like makepkg messages.
|
|
* The check() function will now do the following: create a PostgreSQL database
cluster, start a PostgreSQL server, create a role and database in the cluster
for Turtl to use, initialize the database and upload directory for the Turtl
server, start the Turtl server as a background job, run the core-rs tests,
shut down the Turtl and SQL servers and clean up after itself.
* For most commands, the standard output is either silenced with command line
flags or is redirected to /dev/null, to show only errors that occur during
the process.
* This of course requires you to have turtl-server installed.
* Please note that this package creates a release build during the build()
step, whereas in order to run the tests, a debug build has to be made. This
will result in the program being built twice - if this is unacceptable you
can run makepkg with --nocheck to skip running the test suites. This will
also remove the dependency on turtl-server.
|
|
|