The 'failure' crate has been stale for quite some time and better
alternatives has been developed since its introduction. We choose the
'anyhow' and 'derive_more' to replace it.
This code rework the examples to use the new 2018 edition and also
rework the code to avoid using unnecessary 'extern crate' calls.
The 'use extern crate gstreamer as gst', as well as the other gstramer
related crates, were kept, otherwise we'd need to do it on 'Cargo.toml'
but it would make it more difficult to figure out the respective crate
name.
At the moment we are building 3 independent images, each one having a different
Rust version. This works perfectly fine but we can save storage space and
bandwith by making a smarter use of Docker's layering system.
Introducing a new 'base' image containing all the deps, including
GStreamer, acting as a base for the actual images.
As a result most of the actual content is now shared accross the same
Docker layer. This would save us from downloading/building all the deps
when updating images and will reduce storage and transfers for runners.
It's been replaced by cargo-deny in all modules.
Don't regenerate images for now, it's not a problem to keep it around
until the next images update round.
Fixed printing of pad capabilites in tutorial6.
Output now displays the capability lists eg:
layout:{ (string)interleaved, (string)non-interleaved }
The origional broken output was being displayed as:
layout:SendValue(Value(GString(Foreign(0x557140c99d00, 40))))
CARGO_HOME's semantic depends on when it's used in the pipeline:
- it's the install prefix when installing Cargo
- it's the crate cache location when building jobs
env.sh is sourced at the start of all jobs and was overidding the
CARGO_HOME path defined in the CI template for caching. Fix this by
moving the prefix install path to install-rust.sh.
It seems that when a job is failing, target/ is not properly wiped out
from the ci container triggering later jobs to fail, see for example
https://gitlab.freedesktop.org/gdesmott/gstreamer-rs/-/jobs/2349943
Manually clean it up as after_script to hopefully workaround this
problem.
