Goal: 

• If git push on master branch
• Then sync files onto server and deploy (e.g., running yarn run build or any other scripts)

I’m on DigitalOcean’s server, but this works on any self hosted servers.

For your server to auto-sync with a git repo, there are essentially 2 approaches, either a) git hooks or b) CI tools.

Git hooks can deal with simple actions like syncing and shell commands, but CI (Continuous Integration) can do much more. For instance, with CI, we can run tests and have the results displayed in a GUI (Graphic User Interface). More importantly, if you need to scale from deploying static HTML files to running a whole set of tests before deploying each merge, deploy on staging before deploying, be able to roll back changes easily, or collaborate with teammates on any part of the deploy process… just tune the CI configuration, add another script, and you’re all set.

And it’s simple to set up too.

Step 1: Install gitlab-runner

Prerequisites for this step:

• Have your repo hosted at https://gitlab.com.

There are plenty of choices when it comes to CI tools. The most common ones include Gitlab-CI, Jenkins, Drone, Pipeline… For the purpose of this article, we’ll be using the simple and powerful Gitlab-CI.

With Gitlab, we can have git hosting and CI all in the same place. And unlike Github, Gitlab allows you to run private repos free of charge. Better yet, it comes with its own CI tools.

There are 2 pieces of the puzzle here:

• Gitlab.com, who hosts your repo, detects when a change is pushed, and promptly informs all the runners.
• Gitlab-runner, who sits in your server, receives the change alert and performs actions.

As a result, we need to install Gitlab-runner in our server. Depending on the environment, follow the instructions here to install:

• https://docs.gitlab.com/runner/install/

Step 2: Register the Runner

We need to register the runner to have it linked to your Gitlab repo. To register, first we need to obtain a token from your repo settings page. Go to repo > Settings > CI Settings > Runners. Since we’re on our own server, we’ll be “setting up a specific runner manually”. You should see a registration token here, something like 8E7MsjR3q4ASO3eR7yHp.

SSH onto your server, follow the steps here to register your runner:

• https://docs.gitlab.com/runner/register/index.html

Things to pay attention to:

• GitLab instance URL: since our repo is on Gitlab, simply enter https://gitlab.com here.
• Runner executor: since we’re setting up a simple version here, enter shell.
• Tags: enter deploy here. This can be edited in Gitlab.com if need be.

Step 3: Add .gitlab-ci.yml

In GitLab CI, Runners run the code defined in .gitlab-ci.yml. Create this file in the root of your project, and paste this in:

stages:
  - deploy

deploy:
  stage: deploy
  environment: production
  script:
    - sudo rm -rf node_modules
    - yarn install
    - yarn run build
    - sudo cp -R ./build/* /var/www/html/
  tags:
    - deploy
  only:
    - master

With this configuration, we are telling gitlab-runner to:

• run yarn install and build, then copy files into place
• only execute with master branch updates

You can edit the scripts to fit your own need. The working directory of script runner will be something like /home/gitlab-runner/builds/g74dsd36/0/Username/repo-name.

Now go to Gitlab, open repo > CI / CD > Jobs, now if you push changes to master, you should see Gitlab picking it up almost instantly. Voilà! 😀

TroubleShoot

Go to Gitlab, open repo > CI / CD > Jobs. If the any of the runs failed, they will carry a failed badge here. Click on the ID of the job (e.g. #131224414) and you will be able to check on the shell output of the scripts you are running, and debug from there.

The sudo error:

• If you use sudo in your scripts, you might need to set up the permission for user gitlab-runner. See instructions here.

For instance, since I only needed cp and rm commands, I added to the end of visudo file:

gitlab-runner ALL = NOPASSWD: /bin/cp, /bin/rm