Miriam Grainer, Junior IT-Consultant

About the author

Miriam Grainer is a Junior IT-Consultant for Infralovers and for Commandemy. Miriam loves to learn and experiment with new technologies and programming languages. She currently studies Informationmanagement at the University of Applied Science FH-Joanneum in Graz. Twitter LinkedIn

Latest articles:

Womenintech Part 4: Continous Delivery Of A Static Web Page With Jekyll, GitLab And AWS
Womenintech Part 3: First Steps With Ruby And Chef
Womenintech Part 2: My Journey Continues
Womenintech Part 1: Becoming An IT Employee

As a new project, I was assigned the task to automate internal processes for our website deployment and to implement some features. Therefore, I had to deal with the topics Jekyll, GitLab Runner and AWS S3 Buckets.

GitLab Runner

GitLab offers a continuous integration service which is easy to configure. You just need to add a .gitlab-ci.yml file to the root directory of your repository and configure a GitLab Runner within your project. Now, because of the Runner, every commit or push, triggers the CI pipeline. In the .gitlab-ci.yml file you can configure what the GitLab Runner should do. For example, you can tell the GitLab Runner to execute a script:

In our case, we wanted to push code to the repository and the Runner should find out if we are working on the master branch or on a feature branch. If we are on master branch, it should do the production deployment of our static website. But if we’re working on a feature branch, it should deploy the code to our staging environment, using a particular URL. To accomplish this, I needed to change some things in our Jekyll configuration.  


Jekyll is a simple, blog-aware, static site generator that renders Markdown, Textile and Liquid templates, and produces a complete, static website ready to be served by a webserver.   In the config.yml file, the so called baseurl option has to be changed to the name of the branch within every deployment. So let’s pretend, I have the website http://miriamgrainer.com and I’m working on the branch example. When I push code to my repo, I would like to have “example” as my baseurl: http://miriamgrainer.com/example

- url
- baseurl

To achieve this, you can do something like this in your _config.yml file: baseurl: /example. The problem here was, that we didn’t want to change the variable manually for every deployment. So, we wrote a script that changes the value of baesurl to the name of the branch, or leave it blank if we’re on master.

If we’re deploying to the staging environment, the GitLab Runner has first to create a subfolder, named after the branch, and you also have to tell Jekyll to create the website in this directory. Otherwise, you would not see any content when you call your site with the baseurl option.   Our static website lives on AWS S3 Buckets, because we use s3_website to deploy. Therefore, we have a s3_website.yml file where the destination buckets are defined. Here you have the variable ‘site’ with the path where the website is generated. Another challenge occurred, when I wanted to have multiple branches deployed. Every time when a branch was deployed to the bucket, the deployment before was deleted. You can easily fix this with one line in your s3_website.yml file: ignore_on_server: _DELETE_NOTHING_ON_THE_S3_BUCKET_.

Without the help of my colleagues Edmund and Jürgen, I would have solved some problems in a more complicated fashion that was required. In my opinion it’s a big benefit to work in a small group, because you can work and solve problems easier together. We also had some discussions about how and why things work like this. That helped me a lot and I learned some real cool new stuff.