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: https://gitlab.freedesktop.org/gstreamer/gst-ci/-/merge_requests/261
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.
This will reduce the excessive load on the runners which are having issues
with this job in particuliar. We will revisit when we better understand the
runners issues.
Passing regex as variable does not really works, we ended up matching the
regex as a string instead. Replace all REGEX variable with rules: override.
It is longer but more reliable.
Related to !247Fixes#63
Rules is a new feature that replaces only/except and allow for finer grain
control on the workflow. With rules, we gain finer grain to pipeline and merge
request pipelines.
The windows runner has become a bit unstable lately, might be
due to some recent update. It frequently timeouts while waiting
to pick up a job or sometimes it goes missing in the middle of a job.
Declare an docker build-arg [1] and use it
whenever cloning one of our repositories. If the buildarg
is not specified, the variable defaults back to 'master'
and thus the current behavior doesn't change.
From the .gitlab-ci.yml file, when building pass
the GST_UPSTREAM_BRANCH that's defined from the ci_template
as the buildarg so we will be building the corresponding branches
for the docker images.
Close#33
[1] https://docs.docker.com/engine/reference/builder/#arg
This is where the WINEPREFIX is now in Cerbero. This used to be
share/wine, but was moved to var/tmp/wine for clarity. It was causing
two problems:
1. The size of these generated files are ~1GB, which were ~500MB after
tar.gz, and they were completely useless since they can just be
regenerated by Wine the next time it's run. Let's not waste egress
bandwidth.
2. Random build failures because wineserver and associated processes
would not always exit before we started tarring up the prefix, then
write to the directory on exit while tar was reading the directory
causing `tar -czf` to fail:
```
$ tar -C ${CERBERO_HOME} -czf $CERBERO_DEPS build-tools build-tools.cache dist/${ARCH} ${ARCH}.cache
tar: build-tools/share/wine: file changed as we read it
Uploading artifacts...
manifest.xml: found 1 matching files
cerbero-build/logs: found 461 matching files
cerbero-build/cerbero-deps.log: found 1 matching files
cerbero-deps.tar.gz: found 1 matching files
Uploading artifacts to coordinator... ok id=1807197 responseStatus=201 Created token=4_qFUP8z
ERROR: Job failed: exit code 1
```
This is slightly weird, cause I am not sure what causes the clone
to be there, since gitlab-runner supposedly always either use a
clean volume or at least runs git clean on the existing ones.
But its there and so we have to deal with failures like so
https://gitlab.freedesktop.org/tpm/gstreamer-sharp/-/jobs/1672137
This is now an optional runtime dependency that cerbero can make use
of for doing runtime testing of the built binaries. Needed for
building a new image so that !227 can be merged.
Python fails to validate github.com SSL certificate, unless we first
run a dummy download to force refreshing Windows' CA database.
See: https://bugs.python.org/issue36137
Adapted from patches by Xavier Claessens!
This results into more docker layers, but it avoid invalidating
the previous layers when changing anything in the script, making
build times faster.
Adapted from patches by Xavier Claessens!
