The 'eatmydata' program is "designed to disable fsync and friends" and
can speed up tasks at the risk of potential data loss.
The speed up is welcome and the data loss not important as it would only
make the pipeline fail (most likely), but you can run it again.
It's unclear (to me) what they filter out. And why.
https://salsa.debian.org/help/ci/yaml/index#only-except says:
"NOTE: only and except are not being actively developed. rules is
the preferred keyword to control when to add jobs to pipelines."
So if filtering is desired, it should be added using the 'rules' keyword
and the reasoning behind it should be clarified in comments and/or
commit messages.
As we're just starting out using CI, it is especially important to be
aware of any failure, so that we can fix it.
Such a workaround can be added later in case it is deemed necessary.
Debian's Salsa team has their own registry of images they maintain, so
use them instead of ones maintained by gitlab.
At https://salsa.debian.org/salsa-ci-team/pipeline/container_registry
one can view the various images they maintain.
Switch to using 'unstable' instead of 'sid'. The idea is to later also
add steps based on 'stable' and then 'unstable' matches better.
It's common to define variables/constants in the top of a file, so do
that here too.
Move 'stage' field directly under step name as it's quite significant
and seen in other salsa-ci.yml as well.
Move 'image' line after 'stage' line as it's quite important as well.
Diederik de Haas