From 1a34cf416d4b3449ba7cc66597097bbdcd60d645 Mon Sep 17 00:00:00 2001
From: guf-gitbot <gitbot@garz-fricke.com>
Date: Tue, 29 Jun 2021 17:18:18 +0000
Subject: [PATCH] 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
---
 .gitlab-ci | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.gitlab-ci b/.gitlab-ci
index 4945658a..4468328b 160000
--- a/.gitlab-ci
+++ b/.gitlab-ci
@@ -1 +1 @@
-Subproject commit 4945658afccef314c91147f77793e82daa46733d
+Subproject commit 4468328b8c41263fd02f45f803ab9abccc7a2571
-- 
GitLab