How this blog gets deployed (part 1)

This website is maintained with hugo which is a static site generator. That means the source is parsed and all of the html, css and javascript are generated and saved as files. It means deployment just requires a plain, basic web server.

But that still does mean it needs to be deployed.

You could deploy just on s3 but for me I already have my own server. So I just deploy it to there.

Regardless, the goal is to deploy to phrye.com with just a single git push to the master branch. Deploying to a test site on other branches would let me test style and other sorts of changes.

This is accomplished with Gitlab and some tools it provides.

The first part of gitlab that comes into play is Gitlab CI. This is configured with a .gitlab-ci.yml at the base of the repo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

image: registry.home/sys/slack/system

stages:
  - test
  - build
  - deploy

test:
  stage: test
  script:
    - ./scripts/ci.test.sh

pages:
  stage: build
  image: registry.home/sys/slack/golang-1.9:master-2251
  script: [ ./scripts/ci.pages.sh ]
  artifacts:
    paths: [ public ]

publish:
  stage: deploy
  script:
    - ./scripts/ci.deploy.sh
  only:
    - master

This provides for a three stage pipeline when I push to master; for other branches it doesn’t do the deploy step (the only: master bit enforces that).

The build step uses Gitlab Pages to deploy the site to a site hosted on the gitlab server. So http://kevin.pages.home/phrye.com is an internal site that has a test version of my site. This is done by running hugo to generate the stie. This will result in a directory called output which contains the site. Rename output to public and the pages step will hoover all that up and deploy it on that internal site.

One little hang up here is that the main deployment is at the root of the site but the pages site is not. The --baseURL flag of hugo will help fix that.

I’ll get into the ci scripts tomorrow.