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.

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.

Previously we integrated all projects into the manifest, even those that
belonged to a different manifest branch. That led to all manifests
having the same project revisions, even if they should be different due
to different intgrated project branches.

Save a list of integration sources for each manifest branch separately
now, so that we can check which project belongs to which manifest branch
later.

We need to pass the correct target branch to the merge request creation
instead of using the project's default branch.

Add different integration jobs for different manifest branches. The
merge stage only has one job for each manifest, though, because
otherwise we cannot guarantee a consistent state for all branches.

Extend the deploy script for this purpose, so that it can deploy to
multiple manifest branches at once.

We were passing the complete TemporaryDirectory object to the repo clone
function instead of just the path string, resulting in the repo being
cloned into a local dir "<TemporaryDirectory '/tmp/tmphwakypf8'>".

Fix this to actually use the generated temp dir.

This change makes it necessary to keep the TemporaryDirectory object
reference until we don't need the directory anymore, otherwise it will
be removed immediately.

Get targets dynamically using the INTEGRATION variable instead.

MANIFEST_PROJECT, MASTER_BRANCH_MANIFEST, MASTER_BRANCH_PROJECT

Branch can be implicitly determined via the repo.

BCS 746-000808

Prior to this change the integration stop when one of the projects had
already the latest ref of gitlab-ci in to submodule.

Prior to this change the integration stop when one of the
projects had already the latest ref of gitlab-ci in to submodule.

The integration branch was reused even if there where new commits on the
target branch, which could lead into reverting some changes.
This adds a check, if the existing integration branch is directly based
on the target branch and deletes it if not.

The deploy_gitlab_ci now creates the integration commit and branch in
each passed subproject and create an integration commit in the manifest
containing all these new revisions.
A build is then triggered on this commit to test the functionality.

Split the update_submodule functions to reuse them in different ways.
Remove some previously used files.

BCS 746-000740

Initially the moved code was needed to create the files including the
new implementation.

This change should be reverted after once used.
It is needed to initially add the include .gitlab-ci.yml in
all subprojects.

As all projects are commited in the same branch the 'up-to-date' check
may not only check if the first parent commit points to the
master/dunfell branch. Now it is needed to loop through the history
until the integration branch's commit is found.

On fail a message is displayed which merge request needs to be
retriggered manually. This can now also be the 'parent'-MR that
triggered the complete chain.

The check job is used pipeline again.

The retrigger job also looks in the .gitlab-ci project for check jobs to
retrigger.

Allow deploy_gitlab_ci to change multiple projects at once.
Use it to create integration branches and merge requests in all
projects.

Add a python file to generate a job yml from jinja2 template.
Add a template for the jobs to trigger. These execute the actual
integration in all 'subprojects'.
Create the yml file in the deploy job and trigger it in a new trigger
job.

Add update gitlab-ci file with function to adapt the include ref to a
given revision.
Add a 'pre-commit-hook' to the update-submodule function.
Adapt deploy_gitlab_ci to use these to update the include statement in
the base project .gitlab-ci.yml to use the same ref as the submodule
is set to.

BCS 746-000646

This allows to increase the verbosity. Add --verbose in .gitlab-ci.yml
when the python script is called to view the output in the jobs log.

Explicitly triggering a pipeline in the target repository does not work
easily from this place because we would have to distinguish between the
manifest (which uses branch pipelines) and the sub-projects (which use
merge request pipelines). This separation should not be hard-coded here,
so we move the decision whether or not to run a pipeline to the
.gitlab-ci.yml file of the target. Reverting these two commits:

63279799
    deploy_gitlab_ci: trigger pipeline only if it has not run before

dfc6204a
    deploy_gitlab_ci: trigger pipeline on integration branch

The jobs in the deploy stage have to be triggered manually in GitLab.
There is one deploy job for each project which uses the gitlab-ci
scripts as a submodule, so that the deployment can be performed step by
step.

If executed within MR context, an integration MR is created and left
open. The user can extend this integration MR, e.g. if CI scripts have
been renamed, changed command line arguments or other changes requiring
updates of the correspronding .gitlab-ci.yml file. Subsequent runs of
this job will re-create the integration branch, so manual changes are
lost in this case.

If executed on the master branch (i.e. after the source MR has been
merged), the job does exactly the same, plus the integration MR will be
automatically merged. If this fails, the job will fail as well.