SC2154: var is referenced but not assigned.
The 'rootmnt' variable is set in /usr/share/initramfs-tools/init and if
it's not available, that would be bad.
According to SC2154 you can fix that issue by using '${var:?}' so it
would fail if unset or empty.
So apply that and reference that SC item in the comments.
Also remove it from the exclude list in the CI config file.
To build the yaml files, we only need python3 and make.
All the other/old packages that got installed are needed for building
actual images, so get rid of them.
This should also significantly speed up the job.
While checking the 'artifacts' I noticed that git operations didn't
produce the output as expected, both in top comment as at the end where
build information is written to /etc/raspi-image-id.
That was caused by git not working as it wasn't installed.
Check all the scripts, under 'rootfs/etc/initramfs-tools' (for now) with
'shellcheck'.
A couple of checks are excluded of which SC1090 and SC1091 will remain.
But SC2086 and especially SC2154 should be fixed! And when they are
fixed in the current code, those should be enabled again for checking.
Also rename 'check yamls' job to 'yamllint', so that's directly clear
which tool is being used.
Add a new stage 'check input' to our CI configuration to check whether
our input files contain errors.
The first check is for the YAML files whether they contain errors or
warnings according to 'yamllint'.
Add 'yamllint' config file to not consider too long lines as errors.
And fix the errors/warnings in 'salsa-ci.yml' itself.
Apparently job names can contain space, so rename 'build-yamls' to
'build yamls'.
Upgrade the existing packages before installing new ones.
It's better to have a fully up-to-date system to work on and it could
also fix/prevent an installation issue if a package depends on an
existing, but un-upgraded one. With this change we get
"and 0 not upgraded", which was not always the case before.
Also add a '/' after the 'build' directory to make it clear it is a dir.
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