As described in a previous post, I have set up a GitLab CI runner to build and deploy this blog.

For obvious content changes it is easy to see if they have been applied - I can just visit the site itself. For changes that are a bit more “behind the scenes” it may not be so easy to determine if and what changes have been applied. For example: updating the version of Hugo used by the GitLab CI runner to generate the site.

To aid in raising the visibility of such changes I have added a status page which describes:

• The version of Hugo used to generate the site.
• The version of Pygments used to generate the syntax highlighting for code snippets.
• The current git commit hash identifier for the main blog repo.
• The current git commit hash identifier for the theme repo which I am using (added as a submodule within my main blog repo).

To achieve this I have added a status page as a Hugo content item with the following content:

+++
date = "2017-05-01T16:45:07+02:00"
title = "status"
url = "/status"
+++

### Status

HUGO_VERSION

PYGMENTS_VERSION

Blog commit: BLOG_COMMIT     

Theme commit: THEME_COMMIT  

And then I have a bash script at the root of the my blog repo with the following contents:

#!/bin/bash

cd ./content/about
sed -i "s@HUGO_VERSION@$(hugo version)@g" status.md
sed -i "s@PYGMENTS_VERSION@$(pygmentize -V)@g" status.md
sed -i "s@BLOG_COMMIT@$(git rev-parse HEAD)@g" status.md
sed -i "s@THEME_COMMIT@$(cd ../../themes/Hugo-Octopress && git rev-parse HEAD)@g" status.md

Note:

• The status.md page is located in my “about” folder as it shares the same layout as the About page.
• I used “@” to escape the parameters for sed as the output of the version information contains the “/” character.

The bash script uses sed to find and replace the values in the original status.md page with the relevant information.

I have updated my .gitlab-ci.yml file (which describes the build and deploy stages for GitLab CI) to execute the script before running Hugo to generate the site (see line 9). When the runner executes the “script” portion of the CI config it is executing from a copy of the project’s git repository’s root folder. This is why the “git” commands in the above bash script are able to successfully run and return with valid information regarding the git commits.

stages:
  - build
  - deploy
build:
  stage: build
  image: dinofizz/hugo
  script:
  - git submodule update --init --recursive
  - sh update_status.sh
  - hugo -d public_html -b "${BLOG_URL}"
  cache:
    paths:
    - public_html
  artifacts:
    paths:
    - public_html
  only:
  - master
deploy:
  stage: deploy
  image: dinofizz/rsync-ssh
  script:
  - echo "${SSH_PRIVATE_KEY}" > id_rsa
  - chmod 700 id_rsa
  - mkdir "${HOME}/.ssh"
  - echo "${SSH_HOST_KEY}" > "${HOME}/.ssh/known_hosts"
  - rsync -hrvz --delete --exclude=_ -e 'ssh -i id_rsa' public_html/ "${SSH_USER_HOST_LOCATION}" 
  only:
  - master

So now after each successful build and deploy I have an updated status page with the information that I need:

Check it out for yourself here.