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.

In 438f1e2a we accidentally disabled
caching for the build simulation by moving the cache definition to a job
class. The order of inheritance led to the cache configuration being
overwritten by the one of the "buildbase" class. Change inheritance
order to fix this.

When there are multiple open merge requests for a commit, we currently
take the newest one to determine the integration branch name. This is
not necessarily the correct one, we can have an open merge request with
the commit being part of the commit history while the top commit is a
different one.

Add a check if the commit is the top commit of the merge request in
order to get the correct integration branch name in these cases.

mkstemp() returns a tuple containing an OS-level handle to an open file
(as would be returned by os.open()) and the absolute pathname of that
file, in that order.

Use higher-level function NamedTemporaryFile() instead.

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/remove-redundant-if/

Move the main part of the action to the if branch.

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/swap-if-else-branches/

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/merge-dict-assign/

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/assign-if-exp/

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/inline-immediately-returned-variable/

This is the most concise and Pythonic way to create a dictionary.

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/dict-literal/

A list comprehension can create the list on one line, cutting out the
clutter of declaring an empty list and then appending values.

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/list-comprehension/

A dictionary comprehension can create the dictionary on one line,
cutting out the clutter of declaring an empty dict and then adding
items.

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/dict-comprehension/

Something we often do is check whether a list or sequence has elements
before we try and do something with it.

A Pythonic way of doing this is just to use the fact that Python lists
and sequences evaluate to True if they have elements, and False
otherwise.

Doing it this way is a convention, set out in Python's PEP8 style guide.

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/simplify-len-comparison/

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/de-morgan/

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/merge-nested-ifs/

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/remove-dict-keys/

IMO explicit declaration of lower and upper limits makes code easier to
read than using an implicit default value.

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/remove-zero-from-range/

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/sum-comprehension/

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

Instead of building the Yocto image, the Yocto SDK and the FNGSystem
image in one single pipeline, separate them into three independent
pipelines that are triggered in parallel.

This makes the concept more modular: we have a single general pipeline
now which is configurable from outside via variables. Hence we can have
a custom number of pipelines along with custom build targets in each
project without having to make code changes in the gitlab-ci project.

The default Yocto manifest pipeline configures three build pipelines:

- yocto-build-jobs
- sdk-build-jobs
- fngsystem-build-jobs

In a project including the Yocto manifest pipeline, we can disable
certain build pipelines using job rules, e.g. disabling the SDK build:

sdk-build-jobs:
  rules:
    - when: never

Furthermore we can add more pipelines by simply adding jobs extending
the '.build-jobs' class in the project's .gitlab-ci.yml:

yocto-custom-build-jobs:
  extends:
    - .build-jobs
  variables:
    BITBAKE_TASK: build
    CI_PARAM_IMAGE: custom-image
    CI_PARAM_DISTRO: custom-distro
    PACKAGE_TYPE: image

Image and SDK package jobs call the same package script just with
different arguments. Instead of having two job classes `package_release`
and `package_sdk` for these two tasks, merge them into the base class
`package` and make the differences configurable via a variable
`PACKAGE_TYPE`.

Instead of hard-coding the rules for manual builds in each actual job,
conditionally add this to the `buildbase` class and add a variable
`MANUAL_BUILD` to the according jobs.

Image and SDK builds share a lot of similar code. Instead of having two
job classes `build_yocto_image` and `build_yocto_sdk` for these two
tasks, merge them into the base class `build_yocto` and make the
differences configurable via a variable.

The `dump_install_command` part of the script, which was not executed
for SDK builds, is always present now, but it's only executed if the
`INSTALLSCRIPT` variable is set, which is not the case for SDK builds.

The `collect_srcrevs` part of the script is executed in all cases. It
was not part of the SDK build before, but it's not less relevant there.

Instead of specifying all possible artifacts paths and abusing the fact
that GitLab ignores non-existing paths during artifact upload, implement
a cleaner solution with a configurable path.

This is the first step on the way to a common pipeline for all build
configurations.