Skip to content

Update the code review guide to take the Merge Results in account

Rémy Coutable requested to merge docs-merge-results into master

What does this MR do?

This updates the Code Review guidelines to take in account the upcoming enablement of the "Merge Results" setting.

This is a preparation step for #200037 (closed).

Summary of the changes:

  1. When ready to merge, maintainers should:
    • Start a new merge request pipeline with the Run Pipeline button in the merge request's "Pipelines" tab, and enable "Merge When Pipeline Succeeds" (MWPS). Note that:
      • If the latest Pipeline for Merged Results finished less than 2 hours ago, you might merge without starting a new pipeline as the merge request is close enough to master.
      • If the merge request is from a fork, check how far behind master the source branch is. If it's more than 100 commits behind, ask the author to rebase it before merging.
      • If master is broken, in addition to the two above rules, check that that any failure also happens in master and post a link to the master:broken issue before clicking the red "Merge" button.

Note: Thanks to "Pipeline for Merged Results", authors won't have to rebase their branch as frequently anymore (only when there are conflicts) since the Merge Results Pipeline will already incorporate the latest changes from master. This results in faster review/merge cycles since maintainers don't have to ask for a final rebase: instead, they only have to start a MR pipeline and set MWPS. This step brings us very close to the actual Merge Trains feature by testing the Merge Results against the latest master at the time of the pipeline creation.

Review app:

Related issues

Related to #200037 (closed).

Author's checklist

Review checklist

All reviewers can help ensure accuracy, clarity, completeness, and adherence to the Documentation Guidelines and Style Guide.

1. Primary Reviewer

  • Review by a code reviewer or other selected colleague to confirm accuracy, clarity, and completeness. This can be skipped for minor fixes without substantive content changes.

2. Technical Writer

  • Optional: Technical writer review. If not requested for this MR, must be scheduled post-merge. To request for this MR, assign the writer listed for the applicable DevOps stage.

3. Maintainer

  1. Review by assigned maintainer, who can always request/require the above reviews. Maintainer's review can occur before or after a technical writer review.
  2. Ensure a release milestone is set.
  3. If there has not been a technical writer review, create an issue for one using the Doc Review template.
Edited by 🤖 GitLab Bot 🤖

Merge request reports