In all our other builds, we are using the clone_manifest_ref script
to fetch the revision of gst-build that we discover in the manifest.
For the windows job this was missed it seems, but didn't cause
any issues till now cause it only affected the gst-build MRs.

Part-of: <!296>

Now that we have [`gst-tester`] all module are starting to be tested
with `gst-validate` (core and -base already have validate based unit
tests) so we need to ensure that changes there do not break those
modules.

[gst-tester]: gstreamer!461

Part-of: <!294>

gst-devtools!199
cerbero!490

Part-of: <!295>

Use release 2020.01 for the xilinx zynq target
from https://github.com/Xilinx/vcu-omx-il

Part-of: <!293>

It should now be built as a gst-build subproject. The version in Fedora is not
suitable for CI tests.

Part-of: <!292>

Part-of: <!291>

HACK: pointing to user repo
Part-of: <!291>

also move the default_branch arg later in the dockerfile to
avoid invalidating previous layers

Part-of: <!287>

Let's try extra hard to clean after ourselves, cause gitlab-runner
occasionally decides to reuse existing, polluted, volumes...

so much for clean build environments...

Part-of: <!288>

Similar to !232

Part-of: <!285>

Part-of: <!286>

Its still broken and keeps haning randomly... 😢️

Part-of: <!284>

Part-of: <!281>

Previously we were optimizing for cpu time, so we where building
gst-build once and then exporting that to be used by the test jobs.
However this meant that we where uploading 200mb (previously 600mb)
zipped of artifacts and then re-downloading them for each test job.
This caused big costs in terms of cloud egress since the runners
aren't hosted on the same cloud as the storage/artifacts instance.

Instead we are going to be rebuilding gst-build for each test
job from now, it also doesn't take more time than the network
i/o would of downloading the artifacts, so the impact of rebuilding
shouldn't be noticebly.

We are also using pinned git refs the modules we rebuild from
the manifest, so the binaries should be reproducible for the most
part (minus things like .pyc files).

Close #68

Part-of: <!280>

docker builds can be big, and other shared runner have smaller
storage space which we should avoid filling if can be avoided.
The gst tagged runners are a better fit for such builds since
their disk storage is about 1-2 terabytes.

This avoids the need of using privilledged namespaces and dind
as buildah are able to build images unprivilledged.

One thing to note is that buildah inside docker is not a
supported configuration and not tested in upstream podman,
but the possible fallout is still easier to deal with than
dind and requiring privileged runners.

This done by specifying -L parameter. Some of the FDO infrastructure is using
redirect.

Previously we where accidently exporting the whole repo of
gst-integration-testsuites which includes 350mb of raw media
files and made the artifacts storage explode through the roof
along with the CI bills fd.o had to pay for uploading and
redownloading the artifacts

To deal with this, we clean all the media files from the builddir
and when needed we copy them over from the cache in the docker image,
and then git fetch the repo.

Close #69

We don't run the libnice testsuite, and when binaries are built
they consume ~45mb of space. This increases the size of the artifacts
we export from the gst-build job for the testsuite and drives up
the storage and bandwith costs when re-downloading the artifacts.

Similary disable the test targets of couple other subprojects as well

This is a small regression from previous change.

We have notice that a lot of CI activity is cause by user pushing to their
branch after having created an MR. To reduce our CI foot-print, the CI will
now only be automatically triggered when a reviewer assign the MR to the merge
bot. It will still be possible to run the CI manually but the result of that
CI won't be used by Marge.

This is initial work looking over the deps subprojects and
cleaning up the low hanging fruits. Saves about 90mb compressed.

This is a rebuild of the image to acount for an issue
with a security update during February 2020

https://support.microsoft.com/en-us/help/4542617/you-might-encounter-issues-when-using-windows-server-containers-with-t

This also means we can drop the gstreamer-windows tag
that was added in 32c91139

This should have no functional difference as 1809 is an alias
to ltsc2019 but it makes it more explicit that what branch we
are tracking

Partial revert of 9ed6305e

For post-merge of android ndk-21 as part of:
!266
cerbero!463

For post-merge of android ndk-21 as part of:
!266
cerbero!463

The goal of this change is to reduce egress on the FDO servers.

Results in a better compression for artifacts that are going to be used
multiple times.

It seems to be timing out with high frequency only on Windows runners.

```
Version:      12.8.0
00:47
Git revision: 1b659122
Git branch:   12-8-stable
GO version:   go1.13.7
Built:        2020-02-22T03:03:07+0000
OS/Arch:      windows/amd64
Uploading artifacts...
gst-build/build/meson-logs/: found 2 matching files
WARNING: Failed to load system CertPool: crypto/x509: system root pool is not available on Windows
ERROR: Job failed (system failure): aborted: <nil>
```

See: !261

splitmux unit test includes encoding task which might require more time
to finish test

This might be related to the same issue described in the previous
commit: Till we can update the container image to the Feb 11 security
update, x86 executables and in general the container image will behave
badly because of:

https://support.microsoft.com/en-us/help/4542617/you-might-encounter-issues-when-using-windows-server-containers-with-t

vs2017 x86 has been failing with a runner system failure while
uploading artifacts / submitting job status:

```
Uploading artifacts...
gst-build/build/meson-logs/: found 2 matching files
WARNING: Failed to load system CertPool: crypto/x509: system root pool is not available on Windows
ERROR: Job failed (system failure): aborted: <nil>
```

https://gitlab.freedesktop.org/slomo/gst-plugins-good/-/jobs/2084184

Disable it for now.

Till we can update the container image to the Feb 11 security update,
all x86 executables will crash because of:

https://support.microsoft.com/en-us/help/4542617/you-might-encounter-issues-when-using-windows-server-containers-with-t

So restrict to the gstreamer runners that are running an older Windows
version. For example:

```
subprojects\gstreamer\gst\parse\meson.build:10:0: ERROR: Command
  "c:\python38\python.exe
  C:\builds\thaytan\gst-plugins-good\gst-build\subprojects\gstreamer\gst\parse\get_flex_version.py
  C:\builds\thaytan\gst-plugins-good\gst-build\subprojects\win-flex-bison-binaries\win_flex.exe"
  failed with status 1.
```

https://gitlab.freedesktop.org/thaytan/gst-plugins-good/-/jobs/2066909

```
meson.build:1:0: ERROR: Executables created by c compiler cl are not runnable.
```

https://gitlab.freedesktop.org/nirbheek/gst-ci/-/jobs/2070394

Can't figure out build errors without this.