This way, we won't have to update the path every time we update the used Visual Studio version (and find the correct one via trial & error).
This solution makes use of Microsoft's vswhere script (see microsoft/vswhere) to locate the VS installation directory. Based on that, we assemble the required path.
This way, we won't have to update the path every time we update the used
Visual Studio version (and find the correct one via trial & error).
This solution makes use of Microsoft's vswhere script
(see https://github.com/microsoft/vswhere) to locate the VS installation
directory. Based on that, we assemble the required path.
We used to use a self-hosted macOS CI runner but since we were only
using that for Nightly builds, we frequently ran into situations where
some issue was only appearing there which meant that while for the PR
the CI succeeded, it would fail after the change had been merged in.
As this is not a desirable situation, this commit makes sure that we are
using the same macOS runner for all CI runs. For simplicity we are using
the Azure hosted ones for that purpose.
f999081ab8 enabled the MySQL plugin for Qt.
Turns out its master dependency (libmysql) cannot be built for x86:
https://github.com/microsoft/vcpkg/issues/11214
This issue leaves us with two choices:
1. Get rid of x86 builds altogether.
2. x64 builds with MySQL plugin, x86 ones without. Potential confusion.
We asked on our Matrix channel whether anyone used official x86 releases.
Nobody did, which is a very good thing considering x86 (32 bit) CPUs are no more.
In addition to that, Microsoft dropped the platform with Windows 10 2004.
The automatic upgrade from VS2019 to VS2022 broke our build and in order
to prevent that in the future, we now pin the used VS version to 2022.
Later upgrades will have to be performed explicitly.
Apparently the first commit (59ae429972)
did not include all files.
Furthermore the used script tended to produce funny results in certain
cases. This has been fixed and as a result thereof a few more changes
were made in this second run.
This PR updates the copyright notices of all files. For doing so
it introduces a script that can do this automatically.
Furthermore a few files that are no longer needed got removed.
The timeout has been increased for the Windows CI builds. The new
timeouts are:
- x64: 90 minutes
- x86: 120 minutes
x86 has the higher timeout because it always takes quite a bit longer
than the x64 build.
The timeout was increased as we frequently see the CI job being
cancelled because it did not finish within the default 60 minutes
timeout.
This fixes the last build failure, which was due to the job's display name containing spaces.
"x86_64" is changed to "x64" as the latter appears to be the most common identifier for the architecture, at least for Windows.
Turns out environment variables cannot be exported globally:
"/.ci/azure-pipelines/main.yml (Line: 7, Col: 1): Unexpected value 'env'"
It has to be done for each step that makes use of the variable.
Furthermore if a variable is not defined on Azure, the expansion
$(MY_VARIABLE) does not resolve to an empty String (as is the case e.g.
in Bash) but this expression is then taken literally without any
expansion at all. Therefore we have to make sure that the
BUILD_NUMBER_TOKEN variable is always defined. Thus we define it in
main-pr.yml as for PRs we don't define it on Azure.
In order for these variables to not interfere with each other, the
variable name inside the scripts was prefixed with MUMBLE_
As of now the built x86 files overwrite the x64 ones since the x64
build is usually done first but they both produce files of the same
name.
With this commit the build artifacts for x86 and x64 are separated.
MacStadium kindly provided us an hosted 2012 Mac mini for free last year.
Until now we only used it for testing and to build the vcpkg environment, waiting for the CMake project to be merged.
Now that everything is in place, we can use it for CI and to release builds.
