Skip to content
Snippets Groups Projects
Commit 1a34cf41 authored by GitBot's avatar GitBot
Browse files

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

```yaml:frontmatter

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
parent 744e3250
No related branches found
No related tags found
1 merge request!188Integrate gitlab-ci/use-commit-message-as-mr-description and 13 more
Pipeline #6614 passed with stages
in 13 minutes and 27 seconds