As it happens rather frequently for someone (e.g. me) to forget to
update the translations after having messed with translated strings,
this commit introduces a check to the CI that verifies that the
translations are always up-to-date.
The idea here is that sometimes you really do have a lot of folks connecting from a single IP,
and if those connections are successful you don't want to ban any of them.
However, in cases where the server needs to guard against malicious users attempting a DDOS
by reconnecting their valid user account over and over, we need to be able to configure the
server to still ban those successful attempts.
We have had multiple cases now in which there have been some errors in
changes related to GRPC that weren't detected by the CI because it
excluded the GRPC code from the build process. This will bw changed now.
As all other CIs have been stubborn, for now we'll only build GRPC on
travis as these use a new-enough Ubuntu version to be able to build
GRPC.
MacOS CI I haven't got to work with the whole homebrew stuff and Windows
is done in its own repo (which I won't touch either).
m
This adds client authentication using TLS certificates when it is
enabled in gRPC. This just the basic feature right now. You either have
access or you do not.
Access is granted by putting the certificate digests of the authorized
users into the murmur.ini file.
CELT 0.11.0 provides better quality in comparison to CELT 0.7.0, but the two versions of the codecs are not compatible, which is why we provided both of them.
Opus was introduced in Mumble 1.2.4 (7586a61226), thus we expect that most (if not all) users are using it.
By removing CELT 0.11.0 we don't break backwards compatibility, because it's provided by CELT 0.7.0.
The main reason for removing the codec is the fact that its discontinued (in favor of Opus).
Also, CELT 0.11.0 was removed from the Debian package back in 2012: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010
Unfortunately "sonar-scanner" fails with the following error:
ERROR: Error during SonarQube Scanner execution
java.lang.IllegalStateException: The "build-wrapper-dump.json" file was found empty. Please make sure that:
* you are using the latest version of the build-wrapper and the SonarCFamily analyzer
* your compiler is supported
* you are wrapping your build correctly
* you are wrapping a full/clean build
at com.sonar.cpp.plugin.CFamilySensor.execute(CFamilySensor.java:239)
at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:48)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:85)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:62)
at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:82)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:122)
at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:403)
at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:399)
at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:362)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:122)
at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:141)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:122)
at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:72)
at org.sonar.batch.bootstrapper.Batch.executeTask(Batch.java:98)
at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:63)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
at com.sun.proxy.$Proxy0.execute(Unknown Source)
at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:233)
at org.sonarsource.scanner.api.EmbeddedScanner.runAnalysis(EmbeddedScanner.java:151)
at org.sonarsource.scanner.cli.Main.runAnalysis(Main.java:123)
at org.sonarsource.scanner.cli.Main.execute(Main.java:77)
at org.sonarsource.scanner.cli.Main.main(Main.java:61)
The file is not generated because the C/C++ plugin library fails to load:
ERROR: ld.so: object '/home/travis/.sonar/cache/87f7532f0609a32b83c77be7ae487f14/build-wrapper-linux-x86/libinterceptor-${PLATFORM}.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
Travis CI announced support for ARM64 builds a few days ago: https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support
We already have a Linux x86_64 build on Azure Pipelines, which also generates an AppImage.
This commit changes the architecture for the build we have on Travis CI, so that it's not redundant anymore (and becomes useful).
The "no-pch" build is not changed because the only differences consist in the PCH header not being used and the SonarQube Scanner being executed.
Also, we don't want to use an ARM64 builder unnecessarily.
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.
