This commit changes the Linux build script so that it retrieves the full Mumble version using mumble-version.py.
Previously we were using the first 7 characters of the commit hash as version, which is not very descriptive.
Copied from our current build environment, the header has been changed to match the one in the other scripts.
mumble-version.py determines the full Mumble version based on multiple variables, such as the current commit hash and the latest tag.
There's no reason to keep it in the build environment repository (mumble-releng), because it's supposed to be run inside the Mumble repository and doesn't depend on anything from the build environment.
Recent builds have failed because there is not enough space in `C:\` after installing the build environment, which we used to extract in `C:\MumbleBuild`.
This commit changes the PowerShell scripts so that our environment directory (e.g. `MumbleBuild`) is created in the proper directory (Agent.ToolsDirectory's value, e.g. `D:\a\_tool\`) instead of `C:\`.
`C:\MumbleBuild` is still required because our build environment's qmake expects its configuration files to be there (hardcoded). The environment installation script creates a symbolic link to solve the problem.
This should lower the overall CI completion time, because the macOS build seems to always take a while to start on Travis CI.
The macOS build will be removed from Travis CI in a dedicated commit.
Azure Pipelines offers many advantages over AppVeyor, with the biggest one being a maximum of 10 parallel builds for open-source projects, drastically reducing the builds completion time.
A pipeline takes about the same time to build on the two CI infrastructures, however the caching feature is currently only available on AppVeyor, meaning that on Azure Pipelines the compressed environment is downloaded for each build consuming about 10 minutes.
This means that we'll save at least 10 minutes per pipeline compared to AppVeyor once the feature is added to Azure Pipelines: https://github.com/Microsoft/azure-pipelines-tasks/issues/9190
This adds messagelimit and messageburst to the configuration file murmur.ini as
well as the ability to set these live.
Though adjusting these live is entirely possible, they only take effect for new connections.
We install the protobuf package via brew, which depends on "python@2".
The build image upgraded the installed "python", and now "python@2" conflicts with it when trying to create symlinks.
We don’t use the symlinked "python" installed by default in the image, so we unlink it to allow the "python@2" package to be installed without conflict.
Having to many channels on a server can impact performance to the point
of making the instance unusably slow. This can be a problem for hosters
that allow their users unlimited channel creation.
This patch introduces a new per-server configuration parameter
channelcountlimit which can be used to configure a maximum number of
channels that may be created on each of the virtual servers. Once the
limit is reached channel creation will be rejected with permission
denied.
To allow a translated error message we have to bump the client version
to 1.3.1 to be able to use a fallback message for older clients.
As usual dbus, ice and grpc can ignore this limit. It is only enforced
against clients.
