This makes the variable HIDE_FTP_UPLOAD_STAGE obsolete, because we can
hide the FTP stage now by setting DEPLOY_FTP_TARGET to an empty string.

This variable has been removed in Yocto. Its contents have been merged
into DISTRO_RELEASE_ARTEFACTS.

See for reference:
seco-ne/yocto/layers/meta-seconorth-distro@a316e95e

Extract and save these variables in the build stage instead and
explicitly pass them as arguments to the package script.

Append it to the configured target at the deploy class level instead.
This removes the need for eval'ing the variables before usage.
RELEASE_NAME can be used directly at the class level because it is known
from build-version.env.

This makes the deploy behavior identical to the Azure stage.

Instead of passing MACHINE from stage to stage or loading it from
testdata.json, use the original value from the Jinja2 loop and set it
directly for each job where it is used.

The expressions to calculate RELEASE_NAME and RELEASE_VERSION cannot be
stored within these variables themseselves. If set on the trigger level,
they would override the calculated values in build-version.env then,
as trigger variables always have the highest precedence.

Use separate variables RELEASE_VERSION_EXPRESSION and
RELEASE_NAME_EXPRESSION to define how RELEASE_VERSION and RELEASE_NAME
are calculated instead.

Instead of passing these variables from stage to stage or regenerating
their values in later stages, use the ones set in the build-version job
at all places.

The RELEASE_NAME variable can be set directly now, so there's no need to
have a dedicated RELEASE_SUFFIX anymore. A previous configuration like

  RELEASE_SUFFIX: "-custom"

can now be achieved using:

  RELEASE_NAME: "Yocto-${RELEASE_VERSION}-custom"

This adds a machine-independent job "build-version" which populates the
RELEASE_VERSION and RELEASE_NAME variables, so that following jobs can
use these without depending on the various build jobs.
The variables can be set from the trigger job in a project's
`.gitlab-ci.yml` file. They are eval'ed before saving them to
version.env, so we can use deferred variable expansion or even command
execution to construct their values. This mechanism is already used for
the Flash-N-Go System variables.

Rename variable in order to avoid confusion with the original MACHINE
variable used everywhere else. Also rename the local Jinja2 variable to
include an underscore to make naming consistent.

This had been accidentally removed in
5e36715e.

This was used in times when the same code was executed from different
places. We don't do that anymore, so the variable is obsolete.

There is no need to add a prefix to the variables. Basically every
variable can be set or overridden at the trigger level, so we just use
plain variable names for everything.

We were using different variable names for the same variable in build
and package stages. Unify these names in order to reduce potential
confusion.

Use underscore to separate words within variable name.

FNG_INSTALL_URL was defined in build.env only, and in order to use it
during the build we sourced build.env after writing it.
Remove this workaround and define the variable cleanly in the first
place. This removes the intermediate variable FNG_INSTALL_PATH.
Also move the "/artifact" path from JOB_URL to FNG_INSTALL_URL in order
to make the JOB_URL variable name match better.

On every usage of IMAGEPATH, SDKPATH and LICENSESPATH we prepended
BUILDPATH to it. Prepend it directly on definition to prevent
repetition.
Also remove redundant variable IMAGEBASEPATH.

There were three variables set in build.env of which the values are
already known in the environment for all jobs, because they are passed
from the parent pipeline. Use the original variables instead of defining
new ones.

Disable it locally instead, so that
 1. new code additions are always checked, and
 2. we can refactor one function at a time to make the check pass.

This is another check that suggests changes an average developer without
profound Python experience would find hard to understand. Disable it.

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/for-append-to-extend/

The pkg.py file is no longer deployed by the build process.

See commit
seco-ne/yocto/layers/meta-seconorth-distro@e79e8579

This suggestion aims to reduce code size, but IMO for the expense of
readability for non-python-experts, so we disable it.

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/use-named-expression/

I don't see any benefit in accepting the refactoring suggestions based
on this rule. IMO it makes the code harder to read, especially for non-
experienced Python developers.

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/use-next/

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/raise-specific-error/

The old printf-style string formatting syntax using '%' is not
recommended anymore. See for reference:
https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting
https://docs.sourcery.ai/Reference/Python/Default-Rules/replace-interpolation-with-fstring/

Python 3.6 introduced f-strings as a better alternative:
https://docs.python.org/3/reference/lexical_analysis.html#f-strings

Consequently switch to this new syntax for all strings.

This stage contains jobs to deploy packaged artifacts to our Azure blob
storage. The required variables `AZURE_STORAGE_ACCOUNT` and
`AZURE_STORAGE_SAS_TOKEN` are stored in the GitLab CI/CD variables.
The storage container `AZURE_CONTAINER_NAME` and artifact path
`AZURE_TARGET_FOLDER` are passed from the parent pipeline.

This adds two jobs to the Yocto pipeline:

 - generate-confluence-page
 - publish-confluence-page

The first one generates a confluence page from a template
(`confluence-page.xml.jinja2`) using information downloaded from all
successful "Deploy FTP" jobs of the same pipeline.

The second one publishes this page in Confluence and displays a link to
the new page. If the page already exists it is overwritten.

The place in Confluence where the new page is published is configurable
via the `CONFLUENCE_SPACE` and `CONFLUENCE_PARENT_ID` variables.

This was accidentally forgotten in the previous commit.

This makes the script more general and open for other future purposes.
The parsing of the YAML content is conditional now, depending on the new
"format" argument.

Instead of mixing dedicated CI test jobs and Yocto build simulation jobs
within one pipeline, use the new multi-build-pipelines architecture to
split them up into separate child pipelines.
This also makes most of the Yocto pipeline code reusable, so that we
don't have to declare all the jobs again in ci-test.