Add a job where the tag is checked if it is valid, it also checks if the
release should be published to Flathub beta and/or Flathub by
dynamically setting the matrix.
Due to changes on obs-deps, per-arch Qt builds do not contain universal
binaries anymore. To allow CI to cross-compile on x86_64 runners,
the universal release is used, which will run on both architectures.
Hardcode short hash length to 9 characters in CI and packaging scripts.
It is not guaranteed that short hashes are the same length across
different platforms or different versions of git. This caused problems
with upload/download action names, as the hashes sometimes didn't match.
Fix the download artifact name in the Windows installer job and the
macOS notarization job to prevent them from failing due to a name
mismatch.
Current build scripts rely on comparing a architecture string provided
by the OS which will be localised in certain languages.
This change uses a boolean 64-bit flag to use script-defined identifiers
to avoid this issue.
Use the entries in the matrix.ubuntu property to differentiate the
Linux CI artifacts. This allows us to have separate artifacts for each
job configuration created by the matrix.
Update all of our GitHub Actions to the latest versions. Notably, the
update to actions/cache gives support for the 10GB GitHub Actions cache,
and the updates for the other first-party actions are required for
future M1 runner support.
Commit 7a5bffc0a6 applied a fix to the
macOS build script. This applies the same fix to the GitHub Actions
workflow that is actually currently used on CI.
Prior version was linked against libxcb, because it was present on
Github Actions macOS runners. Consequently builds on CI will succeed
as the library is always present, will fail on user's machines though.
This aligns CI Windows builds with recently shipped deps to support AV1
and RIST as well as providing other updates.
* Update FFmpeg from 4.2.4 to 4.4.1
* Update nv-codec-headers from 9.0.18.2 to 11.1.5.0
* Add libaom and SVT-AV1 support (64-bit only)
* Add RIST support
* Enable multithreading for libvpx obs-deps builds
We currently publish the same build from the same branch
to Flathub. However, soon we'll need to build the Flatpak
manifest in different branches, and publish them in different
repositories.
Prepare for that by splitting the publish step in two: one
for Flathub, and another for Flathub Beta. Do that using
a matrix strategy.
Skip building and publishing stable releases when it's a beta
or RC release by setting an output variable in the first job.
We'll soon be moving to branching before releases, which
is a case that the current Flatpak worflow did not account
for.
Adapt it to also run on release/** branches.
Beta releases are being considered, in which case the tag
name will contain '-beta' instead of '-rc'. Adapt the CI
workflow to take '-beta' into account too.
Now that Flatpak has achieved full feature parity with non-Flatpak
builds, it is time to publish it directly into Flathub.
Add a new "publish" job to the Flatpak workflow that builds and
publishes to Flathub Beta, and to Flathub (if the release tag
doesn't contain '-rc').
Rename "flatpak_builder" to "generate_bundle", and set the display
name to "Generate Flatpak Bundle". This will make it less vague,
which will come in handy since next commits will add new jobs to
this workflow.
The flatpak-builder tool now supports passing secrets options to the
build system. These options are not printed during the build, nor
added to the resolved manifest after build, so they don't leak env
vars from CI.
Make secret variables part of the Flatpak workflow environment, like
the main workflow. Pass the various services hashes and clientids to
the build system using the new "secret-opts" key.
Microsoft Visual Studio 2019 ships with LLVM/Clang 12 as of Visual
Studio 2019 16.11.0 (August 10, 2021). LLVM/Clang 12 is available on all
platforms. This change should make it easier to have clang-format "just
work" on dev systems and be consistent across platforms without having
to use an outdated version.
(Jim note: Rather than copy the QtNetwork library manually like we were
doing before, this makes it so that QtNetwork is used as a dependency of
the UI. The cmake used to copy the library manually thus us no longer
necessary.)
The Flatpak action now contains two subactions:
- flatpak-builder: for building and uploading a bundle
- flat-manager: for deploying the bundle to a remote repository
Use the right action (flatpak-builder) for the Flatpak workflow.
This won't affect existing pull requests, except the ones that
have the "Seeking Testers" label applied - in which case, they
simply need to rebase against the master branch.
Unfortunately, neither Ubuntu 20.04 nor 18.04 have a recent enough
PipeWire package. Disable the PipeWire bits of linux-capture there.
The Flatpak workflow is still able to build it, so keep it enabled
there.
There are too many issues with 20.04 to successfully build with
VirtualCam - the azure kernel is missing videodev headers. For now,
use 18.04 LTS directly for main CI builds.
Both 18.04 and 20.04 include clang-format-10 without issue.
This is a simple, isolated workflow that generates Flatpak
bundles when running on the master branch, or when a pull
request has the "Seeking Testers" label.
Based on https://github.com/marketplace/actions/flatpak-builder
Co-authored-by: lvsti <lvsti@users.noreply.github.com>
Co-authored-by: Sebastian Beckmann <beckmann.sebastian@outlook.de>
Co-authored-by: Stefan Huber <sh@signalwerk.ch>
Co-authored-by: Ryohei Ikegami <iofg2100@gmail.com>
Co-authored-by: Colin Dean <colin.dean@target.com>
Co-authored-by: Wolfgang Ladermann <extern.ladermann_wolfgang@allianz.de>
Co-authored-by: Simon Eves <simon.eves@omnisci.com>
Co-authored-by: Colin Nelson <colnnelson@google.com>
Co-authored-by: Yoshimasa Niwa <niw@niw.at>
Co-authored-by: Michael Karliner <mike@modern-industry.com>
Co-authored-by: Jason Grout <jgrout6@bloomberg.net>
Co-authored-by: Alfredo Inostroza <jadenguy@gmail.com>
Co-authored-by: Daniel Kennett <daniel@cascable.se>
Co-authored-by: Gary Ewan Park <gep13@gep13.co.uk>
Co-authored-by: José Carlos Cieni Júnior <cienijr@outlook.com>