- Then sync files onto server and deploy (e.g., running
yarn run buildor 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
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:
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
SSH onto your server, follow the steps here to register your runner:
Things to pay attention to:
- GitLab instance URL: since our repo is on Gitlab, simply enter
- Runner executor: since we’re setting up a simple version here, enter
- Tags: enter
deployhere. This can be edited in Gitlab.com if need be.
Step 3: Add
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
yarninstall and build, then copy files into place
- only execute with
You can edit the scripts to fit your own need. The working directory of script runner will be something like
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à! 😀
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.
- If you use
sudoin your scripts, you might need to set up the permission for user
gitlab-runner. See instructions here.
For instance, since I only needed
rm commands, I added to the end of
gitlab-runner ALL = NOPASSWD: /bin/cp, /bin/rm