Check tests are being added to gstreamer/gstreamer-vaapi!181.
However, gstreamer-vaapi inherently requires specific hardware
drivers and platforms to function. The CI does not provide this
level of driver/platform selection. Thus, avoid running any
check tests in gstreamer-vaapi.
The cisco repository has been problematic for a while causing
dnf to error due to some gpg issue and break the pipe in non-interactive
ttys.
```
Importing GPG key 0xCFC659B9:
Userid : "Fedora (30) <fedora-30-primary@fedoraproject.org>"
Fingerprint: F1D8 EC98 F241 AAF2 0DF6 9420 EF3C 111F CFC6 59B9
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-30-x86_64
The command '/bin/sh -c /usr/bin/sh /root/prepare.sh && /usr/bin/sh /root/cleanup.sh' returned a non-zero code: 141
```
https://gitlab.freedesktop.org/gstreamer/gst-ci/-/jobs/573870
We do have a meson subproject for openh264 nowdays in gst-build
and it will get enabled automatically once the distro package
is no longer there.
We are only using the builddir of the main fedora job to run
tests, the rest where exported by accident. Its especially
problematic cause static build eat a bunch of space and take
an eternity to be uploaded.
Part of #32
* Install git-lfs as its required now by gst-integration-suites
* Clone gst-build eache time to avoid dated gst-build checkouts
and overwritting .wrap files. Similar to !137
* Split the dockerfile and add a second run stage refresh the
powershell env inbetween calls
* Remove the msys2 workaround as its not needed anymore
This adds 3 new jobs that build against msys2 x86_64, msvc 2017 x86
and msvc 2017 x86_64. For the msvc build, some subprojects (like libnice)
don't satisfy all their deps, and are getting automatically disabled.
This doesn't add jobs that run the test suite also. Will hopefully
get implemented later on.
The git-update that is performed attempts to update gst-build however
will not use the updated git-update script for further operations. This
causes the CI to not use any updates to the git-update which is always
stuck on the version provided by the backing docker image.
The valgrind runs are there to spot obvious problems during the dev phase,
not sure we really need to run them in full after each merge.
Should reduce load on the build bots a little.
If any problems slip in they will be picked up soon enough by
the MR jobs again.
When the pipeline is based on top of a stable branch, we want
to track that branch isntead of the primary development branch.
This patch makes it so the upstream branch can be specified with
an env var.
part of #11
