Before, we were relying on the toolchains job to build and upload
packages that were part of the SDK. With this change, all packages that
should be part of the SDK are built and uploaded by the SDK job. The
toolchains job only builds toolchain packages specific for the release.
This change includes several adjustments done to both the SDK and the
toolchains jobs to make this work:
* Make the SDK job build all cross toolchains, including Rust
* Stop building Rust in the toolchains job and use the one in the SDK
instead.
* In toolchain_util.sh: detect when the symlink folder for crossdev
packages is missing and run crossdev to create it during
update_chroot setup.
* Make it possible to build the SDK starting from stage 4 instead of
stage 1, to make the SDK building faster for PR branches / nightlies
(full build should still be done for releases / weeklies).
The dev build SDKs are not in $FLATCAR_DEV_BUILDS/sdk but published under
$FLATCAR_DEV_BUILDS/developer/sdk.
Add an environment variable to specify where the SDK is to be found
but default to $FLATCAR_DEV_BUILDS/sdk if it is not specified.
From Jenkins this variable is exported as DOWNLOAD_ROOT_SDK.
When the ebuild file changed but not its version nor its cross-workon
commit, the binary package would be used. Also some dependencies are not
encoded to trigger a rebuild of depending packages.
Allow to exclude some binary packages so that we can be sure that they
are rebuilt.
More space can be saved by removing things that get overwritten on
the next job run, but they are used after this script runs (e.g.
for fingerprinting). Drop the cleanup from these scripts and move
it all to the post-build pipeline stage.
We are going to restore the split-script setup from the old Jenkins
server. This ensures that the each version's release process is
actually running with scripts in the correct release branch. It
also allows branching the VM format lists.
Note that the scripts added here only cover the currently active
jobs in the main build pipeline. There is no reason to add other
jobs, since they are mostly just running a single command using a
mantle binary from its master branch.
The scripts in this repository pick up after Jenkins has set up an
environment with all parameters and credentials defined, and an SDK
was prepared and validated.
