Integrate gitlab-ci/use-commit-message-as-mr-description and 13 more

Commit: https://gitlab.com/garz-fricke/yocto/infrastructure/gitlab-ci/-/commit/4468328b8c41263fd02f45f803ab9abccc7a2571

create_merge_request: use commit message as description

Commit: https://gitlab.com/garz-fricke/yocto/infrastructure/gitlab-ci/-/commit/d9aff35de581b93a5bbbea9afeaab9f4406d5628

check_pipeline_status: reduce flush sleep again

Sometimes the job log of canceled jobs still is truncated, even with the larger sleep. Thus we can reduce it again. Usually the job log is complete after a retry.

---

Commit: https://gitlab.com/garz-fricke/yocto/infrastructure/gitlab-ci/-/commit/8c431e9b3f79d0bf2366dd8b66dcf3b992ddc234

check_pipeline_status: increase flush sleep

---

Commit: https://gitlab.com/garz-fricke/yocto/infrastructure/gitlab-ci/-/commit/c453cc07d9367cd472eb1f1e6eeb6799965a854e

check_pipeline_status: add ability to cancel job

If an upstream pipeline has been canceled, this is reflected in the job result now.

---

Commit: https://gitlab.com/garz-fricke/yocto/infrastructure/gitlab-ci/-/commit/b11d648ae13d609e266e9ae3574736ad72c5acd4

deploy stage: simplify yaml syntax

---

Commit: https://gitlab.com/garz-fricke/yocto/infrastructure/gitlab-ci/-/commit/1fe2486a95a7a36b8446a1fac5eff308c97079db

deploy_gitlab_ci: automatically rebase if merge fails

---

Commit: https://gitlab.com/garz-fricke/yocto/infrastructure/gitlab-ci/-/commit/adbeb1d77337ef9a25cd37a1aa9fe23177268c60

Fix pipeline execution on master

---

Commit: https://gitlab.com/garz-fricke/yocto/infrastructure/gitlab-ci/-/commit/00f04bda40df1e8066c71b89cc0e3dda7f697389

Add deploy stage

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.

---

Commit: https://gitlab.com/garz-fricke/yocto/infrastructure/gitlab-ci/-/commit/284876dd274640565bc0ff4bb6d5b27686cd7177

merge_into_manifest: add wait loop until MR has been updated

We still had cases where a merge request was rebased multiple times after an initial (actually required) rebase:

https://gitlab.com/garz-fricke/yocto/infrastructure/ci-test/minimal-bar/-/jobs/1345964713

I assume that GitLab simply does not update the MR that fast and so we attempt to do a rebase, while the MR still reports it is merge-ready.

Adding a wait loop now where the MR's sha is compared to the one of the new commit in order to make sure that the MR has been updated before we attempt another rebase.

---

Commit: https://gitlab.com/garz-fricke/yocto/infrastructure/gitlab-ci/-/commit/5a4b523998dc1e8a36cc69767c8dbf539edf5ffd

accept_merge_request: add additional error handling

We had one case where the merge() function returned successfully, but the MR was not merged (needed a rebase actually):

https://gitlab.com/garz-fricke/yocto/infrastructure/ci-test/minimal-bar/-/jobs/1345574290

This seems to be a known issue:

https://gitlab.com/gitlab-org/gitlab-foss/-/issues/59577 https://gitlab.com/gitlab-org/release-tools/-/issues/277#note_154733089

It seems like in these rare cases, the error is reflected in the merge_error field. Add evaluation of this to the error handling.

---

Commit: https://gitlab.com/garz-fricke/yocto/infrastructure/gitlab-ci/-/commit/6fa9c5a000cf897f1d8f829d234568ee00619151

retrigger_mr_pipeline_job: prevent rare exception where MR has no pipeline

There are rare cases where a merge request does not have a pipeline, even though this might only occur under testing circumstances, e.g.:

https://gitlab.com/garz-fricke/yocto/infrastructure/ci-test/minimal-foo/-/merge_requests/58

The retrigger_mr_pipeline_job script throws an exception in these cases:

https://gitlab.com/garz-fricke/yocto/infrastructure/ci-test/minimal-manifest/-/jobs/1345385316

Fix this by checking for existing pipeline before querying it.

---

Commit: https://gitlab.com/garz-fricke/yocto/infrastructure/gitlab-ci/-/commit/100cb2143a03b5bfd7c3362d1d244e6d746f58fb

merge_into_manifest: add merge_status check before merge attempt

We had some cases where the merge job added rebases of a commit where rebasing was not necessary at all, e.g.: https://gitlab.com/garz-fricke/yocto/layers/meta-guf-machine/-/jobs/1270293595

This is obviously a known issue in GitLab concerning the HTTP return value of the merge endpoint: https://gitlab.com/gitlab-org/gitlab/-/issues/196962

Suggested workaround is to manually check merge_status and wait until it is ready before attempting to merge the MR.

---

Commit: https://gitlab.com/garz-fricke/yocto/infrastructure/gitlab-ci/-/commit/1a8abc1d56acebb4dca3c2094053df84e54d5790

Add diagram detailing the CI pipeline flow

• Add a draw.io diagram that illustrates the flow of the CI pipelines across the manifest and layer repos
• Add a png export of the diagram

---

Commit: https://gitlab.com/garz-fricke/yocto/infrastructure/gitlab-ci/-/commit/c5a1877b45e21ee442086ed05bd95952065bc43f

Add diagram detailing the CI pipeline flow

• Add a draw.io diagram that illustrates the flow of the CI pipelines across the manifest and layer repos