ci: Schedule monthly build to catch regressions Schedule monthly build to catch regressions in the build system during times of no commit/merge activity. Run build at 13:37 on the 14th of each month to help reduce peak load. See https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#scheduled-events
ci: [mac] Update Xcode version to Qt 5 supported Xcode 10.3 is no longer available. Update to the latest version Qt 5 supports.. though 12.5.1 has not rolled out across all build images. Use 12.4.0 for now (this can be increased later). This fixes build failures. See https://doc.qt.io/qt-5/macos.html
ci: Find Qt5 again on macOS With the introduction of Qt6 to homebrew, the install location of Qt5 has changed from /usr/local/opt/qt to the version-specific .../opt/qt@5. Adapt CMAKE_PREFIX_PATH accordingly. No longer hardcode the brew prefix. Also use the recommended, versioned package name "qt@5" instead of the "qt5" alias.
cmake: Modernize (and fix) deployment on macOS For the past decade or so, we have used a bunch of self-written python and bash scripts for creating packages for macOS. These have not aged well, and recently several workarounds had to be hacked in to keep the machinery somewhat working at all. Still, invoking the scripts at build time rather than install time caused a race condition where sometimes not all the packages would be created in CI. To break the camel's back, deploying dependencies no longer worked correctly and broke the packages completely in 0.14-rc1. Fix this by modernizing the whole deployment process and related parts of the build system, replacing the custom scripts by relying on Qt's and CMake's own tooling instead. Some workarounds still need to be added to that to make everything work correctly (neither tool can deal correctly with QtWebEngine, for some reason, and CMake's Info.plist template lacks functionality), but the main part of the work is now delegated to official tooling, everything properly happend at install time avoiding race conditions in the build process, and we can remove a bunch of decade-old and hardly maintained custom code. Also adapt the CI configuration to use -DBUNDLE instead of the old -DDEPLOY, and remove the explicit setting of qmake's path too, as it is no longer needed now.
ci: Select explicit Xcode version on macOS Github has bumped the default version for Xcode to one that is not officially supported by the current version of Qt, and thus causes warnings (and potentially other issues down the line). Avoid this by explicitly selecting Xcode 10.3, which is currently the oldest version provided by Github actions.
ci: Skip macOS 'brew update' to save a lot of time Skip macOS 'brew update' before 'brew install' to save up to an hour of time with Homebrew updates, as per GitHub's recommendations. See https://github.com/actions/virtual-environments/issues/2173 And https://github.com/microsoft/appcenter/issues/293 This could potentially introduce issues if Homebrew makes a breaking change in between the 1-2 week window that GitHub Actions updates their macOS CI images, but it seems unlikely and 'brew update' can be re-added if needed.
ci: Workaround macOS hdiutil out of space errors Workaround "hdiutil: create failed - No space left on device" by letting hdiutil auto-detect the required disk space. Keep the old method around via documentation in case this issue arises again. https://stackoverflow.com/questions/18621467/error-creating-disk-image-using-hdutil https://apple.stackexchange.com/questions/156994/yosemite-hdiutil-create-failed-error-5341 https://asmaloney.com/2013/07/howto/packaging-a-mac-os-x-application-using-a-dmg/ https://github.com/autopkg/jps3-recipes/issues/57 Make this issue easier to detect by changing the build script macosx_makePackage.sh to fail early if any individual command fails. This includes fixing up optional parameters to use default values. Re-enable the "Check artifacts" step of the "Post-Build" process now that macOS builds are hopefully more reliable.
ci: Make artifact sanity checks non-fatal for now Currently, macOS packaging is unreliable due to a race condition in the ancient scripts, sporadically leading to a missing QuasselCore package. A proper fix would require a modernization of the packaging process. Mark the artifact sanity check non-fatal for now, until a proper solution can be implemented.
ci: Add sanity check for artifacts to post-build job Check if expected artifacts have been created for every workflow run, not only for tagged commits. While this is just a rudimentary sanity check, it would at least cause a CI failure if one of the build jobs didn't produce artifacts for some reason. A nice side effect is that unlike the former create-release job, the new post-build job is not completely skipped for non-tagged commits, and thus shows up as successful for every good CI run (even though the individual steps required for creating a draft release are skipped, of course). This causes the GitHub UI to automatically collapse the (giant) list of checks after they are all complete.
ci: Replace Travis and Appveyor CIs by a GitHub Workflow Replace the previous CI systems by a GitHub Workflow for all supported platforms. This unifies the full CI setup in a single place, and provides better integration into GitHub itself via the checks API. Additionally, GitHub provides us with more resources than the other systems, enabling more parallel and faster build jobs. As a result, we can afford a larger build matrix than before, and now cover additional Linux baselines. Unlike Appveyor, GitHub also parallelizes Windows build jobs, which resolves the huge bottleneck we had when pushing multiple PRs or branches. The total turnaround time is still dominated by the Windows build, but at around 15 minutes it is much faster than before. GitHub also has a sane retention policy that keeps temporary artifacts around for several months, and won't run out of space during active development times like Appyevor did. For tagged commits, a draft release is automatically created and the source archive as well as packages for Windows and macOS are attached. The tag annotation is used for the release notes. Releasing as a draft allows for final, manual changes before publishing the release. Note that this change should also enable CI runs in forks, so contributors can enjoy CI feedback while developing, prior to creating a pull request.