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
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.
Change our checks for MUMBLE_NO_PCH to use string comparisons
instead of numerical comparisons.
When MUMBLE_NO_PCH is not set, the numerical equivalent check
fails because nothing is on the left-hand side of the -eq operator.
Fixesmumble-voip/mumble#3314
This commit adds a Homebrew-based macOS build to our Travis CI build
matrix.
It also cleans up the exising build matrix such such that Linux builds
are built only on Linux hosts, and macOS builds are only built on macOS
hosts.
