This should help with getting better stacktraces out of the build.
The container image isn't yet built with frame-pointers, but once
we update to fedora 38 that will be resolved and improve things further
as well.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5543>
This often blocks updating the base image of the CI since we
have to wait to port away from all the deprecated apis each time.
That's work that is done independantly usually and blocking image
updates, means that more regressions that would have got caught
by the newer toolchain sneak past and get merged.
Deprecations will still show up when developing locally.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5543>
While everything that's merged needs to have passed CI, the
testsuite result are not as consistent as we'd like and sometimes
regress.
It's nice to have have a pipeline hitory of the tests results
to make it easier to spot regressions that might have caused
racy/flaky tests.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5588>
Set up a test suite that runs fluster in a virtual machine using virtme.
This test only runs when a kernel image path is set in the new
`virtme_kernel_image` meson option.
The kernel iimage must have support for visl.
The suite contains 4 tests, 1 for each supported codec in visl:
- vp8
- vp9
- h.264
- hevc
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5434>
When using parallel:matrix variables, only the value of the
variable is shown in the Gitlab GUI and thus we end up with
a job name resembling "build fedora gcc: [both, true]".
Pass down the whole string/arguments as the matrix variable
values so that we will have a bit more context.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4698>
Now we will pick up the right gstreamer branch + namespace when
building an image, and also the right (matching, if any) cerbero
branch + namespace.
This solves the bootstrapping issue when doing an image update that
requires coordination between gstreamer and cerbero.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5043>
The libpsl subproject wasn't building successfully and CI didn't
notice because:
1. The plugin wasn't explicitly enabled
2. Even when the plugin is explicitly enabled, the dep is not required
at build time when not building a static plugin
So fix all of these issues.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5038>
We need the Windows 11 SDK for Windows Graphics Capture API support,
which will be enabled at runtime based on feature availability on
Windows, so should work correctly on Windows 8, 8.1, 10, and 11.
However, if we enable it in the VS 2019 installer, it will install
both Windows 10 SDK (required) and Windows 11 SDK (optional), which
will bloat the image by 3GB or more.
So just move to VS 2022 for the Windows images, which requires only
the Windows 11 SDK.
Had to remove the UWP build tools because they were causing the
installation to fail, likely due to an installer bug. We don't need
UWP anymore anyway. We just need the ARM64 build tools for the
cross-arm64 monorepo build.
Also stop installing into C:\BuildTools and let Meson pick the install
up with --vsenv.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4939>
This is a new feature which makes it so we can generate
jobs based on the possible matrix of the environment variables
we pass into it.
In this commit we refactored the gstbuild template to a matrix of
Buildtype, debugbuild (and could have also set werror, but we
always have it on in fedora gstbuilds).
Then create 2 jobs, one for each compiler set. We could have
put them in the matrix, but CC and CXX are kinda coupled
and doesn't make sense to tests the matrix between them.
https://docs.gitlab.com/ce/ci/yaml/README.html#parallel-matrix-jobs
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4281>