Move the deltachat clanService test to the deltachat clan service.
The tests should live close to the definition of the service, so that
debugging and discoverability is better.
Move the mycelium clanService test to the mycelium clan service.
The tests should live close to the definition of the service, so that
debugging and discoverability is better.
Move the admin clanService test to the admin clan service.
The tests should live close to the definition of the service, so that
debugging and discoverability is better.
We currently have to re-run our integration tests a lot because they are
depending on the whole repository. This pull request changes locks the
clan-core used for vm tests. This has the caveat that we might not run
the latest NixOS machine of our profiles. On the upside we can test
behaviour against an older clan-core version and capture breakages and
make it backwards compatible. If we actually want to test the latest
version, the PR that changes the exposed flake api, could also bump the
clan-core snapshot.
Since this project is an ever growing monorepo, having derivations depending on the whole repo leads to bad CI performance, as the cache is busted on every commit.
-> We never want any derivations depend on the whole repo
...except: the test that tests that nothing depends on the whole repo, which is added by this commit.
For now only add this check to packages to allow contributors to build it locally.
We might want to add it to the CI later once all occurrences are fixed.
Exposing the function via clanLib makes it more accessible to clan modules
This allows each module to define its own test without needing to depend on any fileSystem path assumptions in the clan-core repo
Some test were referring to the whole source code via ${self} which amde them rebuild on every single commit.
This is not mitigated by introduceing `self.filter { include = [...]; }` allowin to a content addressed subset of the source code in tests.
This adds the `mumble` clan-module.
This allows for voice chatting in a true peer-to-peer network.
Every machine that has the module enabled is a potential host and
client - every participant has the same role.
It doesn't matter who in the network is online - as long as one of the
machines is up, one server is up and people can start their voice chat.
