redundant_pattern_matching does not seem to exist (perhaps renamed to
if_let_redundant_pattern_matching), and single_match + cast_lossless do
not seem to be violated (anymore?).
In 55badab1 versioning features were added to these crates after all
(even though they are not used in the actual code, merely to forward the
feature flag to dependencies like `gst` and `gst-gl`). They were omitted
at first and have these special cases in the CI, but those are not
necessary anymore.
Fixes: b2f3363c ("CI: Update to restructured GL EGL/Wayland/X11 layout")
They're fully additive so there's no point in building with default
features too.
For the non-sys bindings we might want to consider building with default
features though.
There have been some very weird issues, where
cargo keeps fetching older commits of glib-rs
and breaking the build like so [1]
Might be stale cache, or some http/git mirroring
shenanigans, so lets stop trying to use the
cache for now and check if the issue persists.
its confusing and it took 3 attempts to get `before_script`
to fucntion as expected. Instead get rid of the anchor
and use a (questionable) but simpler heuristic to detemine
when to update the lockfile.
We are caching the CARGO_HOME which includes git repos of
the gtk-rs bindings. Since we don't specify a branch
so it uses the default branch for the ref.
cargo build usually does an update if it has network access,
but its not guaranted or the case for other tools like clippy
which may still point to the stale git snapshot like here:
https://gitlab.freedesktop.org/thaytan/gstreamer-rs/-/jobs/4165449
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.
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.
We are caching $CARGO_HOME in between runs, so an arbitrary
cargo audit binary might already exist in the environment.
Force install it so cargo doesn't complain and our binary
is guaranteed "fresh".
