Two warnings, SC2034 and SC2178, pop up very often with the references
- shellcheck handles them poorly and produces a ton of bogus warnings
about them. Silence the warnings and drop most of the "shellcheck
disable" clauses.
Reports generation used to be executed four times. The number of runs
was a result of cartesian product of two sets - old and new state, and
of amd64 and arm64 architectures. It was pretty much a slow process
because egencache was called implicitly four times, and it was running
in a single-threaded fashion, and also SDK reports were duplicated
(they were the same for old-amd64 and old-arm64, and the same for
new-amd64 and new-arm64 runs).
This changes the generation, so it is being run only two times - once
for old state and once for new state. Every run generates SDK packages
reports and per-architecture board packages reports. Egencache will
now utilize more threads too.
This adds an explicit generation of md5-metadata cache before any we
do any emerge invocations. That way we can have a copy of reports even
if emerge fails for some reason. But mostly the reason for this
copying is to consume the data later, outside the SDK container.
The coreos-devel/sdk-depends is a metapackage that is emerged in
stage4 of the catalyst SDK build. But the fsscript that is being run
at the end of the stage4 build also pulls in dev-lang/rust package.
Thus pull both packages for the report.
This should result in updated dev-lang/rust to appear in the reports.
This adds some scripts I have been using for over a year to deal with
the weekly package updates.
It comes with a `README.md` which describes a workflow similar to my
own.
The `sync_packages.sh` and `update_packages.sh` scripts are currently
not used anywhere. The idea behind them was to use them for Github
Action, but that will come as a follow-up PR.