Gitlab CI automatically rebase master branch when review branch merged

Question

We use a peer-review process where reviewers are asked to merge in to a Review branch when done.

Thing is, after review, we wish that our master branch gets automatically rebased with what Review branch has. This would reflect our current manual process where repo maintainer manually rebases review branch in to master to make a deploy.

How can we achieve this automatization?

Blintze

Do you want to rebase master with review or you want to merge the review to the master ? – Declare

It's almost the same since master doesn't receives anything but what review has. – Blintze

It is not the same. In case you merge review with master any changes in master come to the review branch but the master itself does not receive the changes in the review branch. whereas if you merge review into master master will receive the changes made in review. Question is do you want to update the master with the changes in the review branch? – Declare

Exactly that, master should receive what review has. I said it's almost the same since master does not receives nothing except through review. There's no way, on our current process, that master has anything review haven't had before – Blintze

Answer 1

This can be achieved through a gitlab-ci pipeline task. Essentially you will need to merge to master and push. Unfortunately there is no direct way for a gitlab runner to push to remote.

The below is a workaround

• Setup ssh key in a before_script
• Make the git updates locally
• Push to remote

Sample code below

merge_to_master:
  before_script:
  - which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )
  - eval `ssh-agent -s`
  - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add - > /dev/null
  - mkdir -p ~/.ssh
  - chmod 700 ~/.ssh  
  - ssh-keyscan -H <Your gitlab server> >> ~/.ssh/known_hosts
  - ssh -vT git@<Your gitlab server>
  variables:
   VERSION: "$CI_PIPELINE_ID"
   VERSIONNAME: "$CI_COMMIT_REF_SLUG"
  only:
   - <Review* or similar>
  script:    
    - export LC_CTYPE=en_US.UTF-8
    - git config --global user.email "Some user email - Typically the machine user"
    - git config --global user.name "Some name"
    - git checkout master
    - git merge $CI_COMMIT_REF_NAME
    - git push ssh://git@<Your gitlab server>/<Repo> HEAD:master
  stage: dev_deploy

$SSH_PRIVATE_KEY - Environment variable containing the private SSH key for git Refer https://help.github.com/en/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent

[ci skip] - Add only if you want to skip the build after the push

Declare

I get the general idea. Wouldn't the git commit -am would overwrite the last commit's message in history with "[ci skip] Released" ? – Blintze

The commit was more for a change we were making in our pipeline where we are auto-incrementing a version number. This statement can be removed. Updating my answer likewise. – Declare