Skip to content

Collaboration server build instructions

Jump to bottom
Jonathan Van der Cruysse edited this page May 15, 2018 · 3 revisions

If you're looking for the collaboration server's source code, that's in a separate repository.

Dependencies

Building the collaboration server is super easy, provided you have the right tools. The subsections below detail how to install these dependencies on Debian-based distributions and Mac OS X.

  • A .NET runtime implementation. Windows ships with a .NET runtime by default. For Linux and Mac OS X, I warmly recommend Mono. The installation instructions should be pretty easy to follow.
  • A C# compiler, an MSBuild-compatible build engine and a NuGet client. These are included in Visual Studio on Windows. On Debian-based systems, install the mono-complete, mono-devel and nuget packages. On Mac OS X, install the mono and nuget Homebrew packages.
  • Python 3 with the requests module for running the tests.

Setup for Debian-based distros

First, add the mono apt repository by following the instructions here. The exact repository you need to add depends on your operating system version.

Next, run the following commands.

$ sudo apt install mono-complete mono-devel nuget python3-pip
$ pip3 install requests

That's it. You should be able to build the collaboration server now.

Setup for Mac OS X

Run the following Homebrew commands. Don't have Homebrew? Follow these super-simple instructions.

$ brew update && brew install mono && brew install nuget
$ pip3 install requests

Build instructions

To build the collaboration server itself, restore NuGet packages and build the main solution.

$ nuget restore src/UnSHACLed.Collaboration
$ msbuild src/UnSHACLed.Collaboration

That's all.

Running the tests

Testing the collaboration server is complicated to say the least. Here's why:

  1. The collaboration server contains very few non-trivial data structures and algorithms—the smart bits in the server consist of how it interacts with GitHub. Just unit testing the server won't do us much good.
  2. We can't test GitHub interactions before deployment because of how the GitHub authentication process works.

That kind of leaves us in a bind. But all is not lost.

  • We have semi-automated integration tests (where you need to sign in manually, but everything else happens automagically). These can be run against the production server only and check that GitHub interaction works as expected.
  • We can run the exact same set of tests in fully automated mode against a local server that fakes GitHub interaction (well, technically, it just uses a home-grown in-memory content tracker, but I guess that's a distinction without a difference). These tests always run during CI builds.

Running fully automated tests

To run the fully automated tests, execute the command below. These tests will host the server locally with an in-memory content tracker (as opposed to a GitHub content tracker implementation) and then run all manual tests against that instance. If these tests pass, you can be reasonably confident that your changes will work on the production server.

$ python3 test/auto_server_tests.py

Running semi-automated tests

To run the semi-automated tests and use the actual GitHub API instead of an in-memory content tracker implementation, execute the command below. The tests will always run against the production server, so keep that in mind; you can't run the manual tests until after you've deployed the collaboration server to production.

$ python3 test/manual_server_tests.py
Clone this wiki locally