Loading...
 
Skip to main content
2

Tools for Merge Request reviewers

Here are the merge requests: https://gitlab.com/groups/tikiwiki/-/merge_requests

Main reviewers

Guidelines

  • If a MR is in draft, you can provide feedback, but don't merge yet.


Example: https://gitlab.com/tikiwiki/tiki/-/merge_requests/2910#note_1417388350

Atomic Commit Convention

Atomic Commit Convention

Database Schema changes

Please be extra careful on these. Please see: Database Schema Upgrade

Continuous integration pipeline

In general, do not merge if there are failing tests, but as of 2023-02-01, we have some issues on older branches, so pipeline will run tests only on modified files in MR/commit

Status as of 2023-02-01:

Questions and answers

Is it OK to rebase?

What about rebasing? When I click "Rebase", this alert displays: "Are you sure you want to rebase?
Rebasing creates a pipeline that runs code originating from a forked project merge request. Consequently there are potential security implications, such as the exposure of CI variables.

You should review the code thoroughly before running this pipeline with the parent project's CI/CD resources.

If you are unsure, ask a project maintainer to review it for you."

So my question is, is it ok go go ahead and rebase?

Answer: Yes, it is OK to rebase. And you need to do it before approving the merge request. It can also be useful to rebase if some tests are failing, as it may resolve a flaky test, or tests may have been improved in master.

What if the merge train fails and the merge request gets removed from it?

Recently we switched to the "Merge Trains" feature of GitLab. It might sometimes happen (especially on the older branches) that while trying to merge a MR (e.g. a cherry-picked backport) via the GitLab UI you get a message such as "<username> removed this merge request from the merge train because The resulting pipeline would have been empty. Review the rules configuration for the relevant jobs." and the MR is not merged. What can I do?

Answer: The merge request must be merged manually. Here are the steps you need to follow on your command line:

  1. git fetch "git@gitlab.com:<mr-author-username>/tiki.git" 'mr-authors-branch-name'
  2. git checkout -b ‘<mr-authors-branch-name>’ FETCH_HEAD
  3. git rebase upstream/<tiki-branch-name> # Or replace “upstream” with whatever you called the main tiki source. Just a standard local rebase. NOT a merge, we normally enforce linear history.
  4. git push upstream <tiki-branch-name> # Or replace “upstream” with whatever you called the main tiki source, instead of pushing back to the MR or to your own tiki fork. This is the "manual" part


For example:

Copy to clipboard
git fetch "git@gitlab.com:rodriguezny/tiki.git" '21x-remove-patch-already-applied-in-adodb-5.20.21'
git checkout -b 'tiki-21x-remove-patch-already-applied-in-adodb-5.20.21' FETCH_HEAD
git rebase upstream/21.x
git push upstream 21.x

Related

History Source Comments
Show PHP error messages