Fix guarantee final pipeline #351
Conversation
Background: There are cases when a project needs to have a final run of the CI pipeline before the merge. For example, if a team practices fixup-driven code review process in a project, the fixup commits must be auto-squashed prior to a merge. This can be done in CI check by having a job that performs the check only when Marge-bot is assigned. Gitlab CI is not triggered automatically on actions like assigning, so that Marge-bot `--guarantee-final-pipeline` option is what is exactly needed in this case: it is supposed to trigger a pipeline right before the merge. Problem and cause: `--guarantee-final-pipeline` does not trigger Gitlab CI at all. Only a comment `jenkins retry` appears in the review. Looking to the code, it is visible that no more than additional 30 seconds of waiting is implemented. Measure: - When `--guarantee-final-pipeline` is specified, change the Marge-bot behavior to triggering a merge request pipeline (falling back to a regular branch pipeline if [MR workflow][0] is not set up) and waiting for it to pass. - Check the solution in Marge-bot tests. [0]: https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html#prerequisites
`--guarantee-final-pipeline` flag is a bit hidden now from a potential user who has no Merge-bot installed yet because it is not mentioned in the readme file. Add the output from `--help`.
| @@ -64,8 +64,9 @@ def update_merge_request_and_accept(self, approvals): | |||
|
|
|||
| if _updated_sha == actual_sha and self._options.guarantee_final_pipeline: | |||
There was a problem hiding this comment.
i'm not sure that this condition is right or not.
maybe it could be if _updated_sha != actual_sha && self._options.guarantee_final_pipeline
in my test with this patch, marge bot is still unwaited the final testing result.
I found more good point
Line 88 to be
if target_project.only_allow_merge_if_pipeline_succeeds or self._options.guarantee_final_pipeline:
There was a problem hiding this comment.
Thank you for your interest in the PR, @d3m3vilurr.
in my test with this patch, marge bot is still unwaited the final testing result.
Do you have the "Pipelines must succeed" option checked in Gitlab project settings? In my understanding, the main point of the --guarantee-final-pipeline switch is to enforce the mentioned Gitlab merge strategy in the case when no actual changes happened to the MR commits, so the pipeline is triggered for the last time, as it must succeed.
There was a problem hiding this comment.
you are right. we didn't mark the pipeline must succeed in gitlab project setting.
because we want to push & merge without margebot in emergency time.
in my case, a bot started with guarantee_final_pipeline, when reassigned to a bot, a branch of MR was rebased with a target branch by a bot.
(a target branch has another commits, so technically, MR was changed)
but if a project doesn't have pipeline must succeed option, the last checking CI would be always failed cuz bot didn't wait for this CI before merging.
So, I want to wait for CI result like another bot (such as bors-ng)
|
@qusielle @d3m3vilurr ping. |
Hello @felh, |
There are a group of people who have recently forked the project at https://gitlab.com/marge-org/marge-bot |
Hey folks, as John said, this pull request has been imported into the community fork: https://gitlab.com/marge-org/marge-bot/-/merge_requests/351 If you'd like to see it merged, please join over there. @qusielle do you have a GitLab.com account? |
couple weeks ago, I also got a email from gitlab.org about import an issue. now I've reopened a thread of my comment in gitlab, and copied thread comments of this to there. |
Background:
There are cases when a project needs to have a final run of the CI pipeline before the merge.
For example, if a team practices fixup-driven code review process in a project, the fixup commits must be auto-squashed prior to a merge. This can be done in CI check by having a job that performs the check only when Marge-bot is assigned. Gitlab CI is not triggered automatically on actions like assigning, so that Marge-bot
--guarantee-final-pipelineoption is what is exactly needed in this case: it is supposed to trigger a pipeline right before the merge.Problem and cause:
--guarantee-final-pipelinedoes not trigger Gitlab CI at all. Only a commentjenkins retryappears in the review. Looking to the code, it is visible that no more than additional 30 seconds of waiting is implemented.Measure:
--guarantee-final-pipelineis specified, change the Marge-bot behavior to triggering a merge request pipeline (falling back to a regular branch pipeline if MR workflow is not set up) and waiting for it to pass.