Integrate gitlab-ci/use-two-dashes-as-separator and 19 more
list_commits: use "--" as separator
Unfortunately, GitLab still interpreted three of the four dashes as start and end of YAML syntax, so we go back to two dashes.
--
list_commits: use "----" as separator
The former "---" was still rendered as YAML syntax by GitLab in some cases.
--
create_merge_request: optimize description
Restore the "---" separator which was removed in a previous commit. The description simply must not start with this separator. If we include it only in between the blocks, all instances are rendered as a horizontal line, which makes the MR description more readable. Include a helper function for this purpose, which extracts the message body from a commit message.
--
deploy_gitlab_ci: show instructions if merge fails
--
update_submodule: fix accidental multi-commits
If integration branch already existed and had to be replaced, the new commit was accidentally pushed on top of the already existing commit instead of replacing it. Fixed this by checking out the master branch again before creating the commit.
--
list_commits: replace "---" with "--"
GitLab renders "---" as a horizontal line or as a frame. We do not want this, so replace it with "--".
--
create_merge_request: use commit message as description
--
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.
--
check_pipeline_status: increase flush sleep
--
check_pipeline_status: add ability to cancel job
If an upstream pipeline has been canceled, this is reflected in the job result now.
--
deploy stage: simplify yaml syntax
--
deploy_gitlab_ci: automatically rebase if merge fails
--
Fix pipeline execution on master
--
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.
--
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.
--
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.
--
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.
--
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.
--
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
--
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