CI/CD: Setting up GitLab Runners on AWS using CoreOS & Terraform

GitLab Runner is used as part of GitLab CI/CD pipelines. On a side note, it also supports GitHub and BitBucket too! But I digress… 

In this post we’ll cover how to install, configure and register Runner.

So many choices!

Runner can be installed on various operating systems/tools (Linux, Windows, Mac, Kubernetes, Docker), to name a few. If you’re interested, a full list can be found in the documentation. For the purpose of this post, we’ll use the Dockerised version on a CoreOS instance which is running in AWS. (Boy, that was a mouthful!)

URL & Token

Before we can spin up our Runner, we’ll first need to retrieve our GitLab URL and registration token. We can obtain both of these by:

  1. Selecting a repository
  2. Clicking “Settings” –> “CI/CD”
  3. Navigating to the “Specific Runners” section

Continue reading

Git: Merging & Rebasing basics

In the Git: Keeping in sync post we learned how to merge the orgin/master commits into our local master branch. Then in Git: Effective branching using workflows we learned about how to use branches effectively. What we haven’t yet touched on yet though is rebasing and its affect on merging.

Commit log

Before we get started on merging and rebasing, let’s first see how we can view our git log as we will need to do it throughout this post:

In a nutshell, the above command shows us the last three commits which were made in this repo. If we want to get a little fancier, we can have git draw a graph for us:

Continue reading

Git: Effective branching using workflows

In the Getting started with git we learned about local and remote branches ( master and origin/master respectively), and in Git: Keeping in sync we learned how to keep the two branches in sync. This is all great stuff, but if you’re working in a team and/or on a serious project, using only the master branch is not a good idea. The reason being that if master is having development code pushed to it continuously, it will never be stable.

What you should do instead, at a minimum, is have two branches. For example, dev and master, where  dev is used for features which are being developed and master is used for production code. Once the in-development features have been tested and are ready for production, they can then be merged into master. By employing this method master will always be in a stable state.

Continue reading

Git: Keeping in sync

In the Getting start with git post we covered a number of things, one of which was using push to send our commits to a remote git repo. This is works fine when both of these conditions are met:

  1. You’re the only person working on the project
  2. You’re doing all of your development from the same machine

If one of these points is not true, you’ll soon find the push command fails to work. The reason for this is because you must first retrieve all of the commits from the remote branch before you can merge your own. In other words, you must first be in sync before you can make modifications.

Therefore if someone does a push before you, and/or you do a push from a different machine, the machine you’re currently using will be out of sync with the remote branch. As a result you will be unable to do a push until you first re-sync with the remote branch.

Note: The reason why this issue is not encountered when you meet the two criterion listed above is because your machine will always be in sync with the remote branch given that it’s the only one doing any commits.

Let’s now run through an example to see this in action.

Continue reading

Getting started with git

What is git?

Wikipedia has a great answer for this question:

Git is a version control system for tracking changes in computer files and coordinating work on those files among multiple people. It is primarily used for source code management in software development, but it can be used to keep track of changes in any set of files. As a distributed revision control system it is aimed at speed, data integrity, and support for distributed, non-linear workflows.

OK cool, now that we know what is git let’s now take a look at git repositories.

What is a Repository (repo)?

A repository is receptacle for files which are part of a project. Each project should be stored in a separate repository so that their files are kept separate, access to them can be administered separately, etc.

Creating a new repo

When you create a new repo using a git server provided by the likes of GitHub and GitLab, you will be given a few options to help you get started. One of these options is as follows:

Continue reading

Installing Git on Windows

Installing Git on Windows is very similar to installing it on Linux. That might not come as a surprise though because the tools we’ll be using in this post are specifically designed to allow Windows users to utilise Linux packages without needing to install a VM.


The first thing you’ll need to do is download Git for Windows. Once you have done that, install it using all of the default settings. After completing the installation, you will find that you’ve now got three Git applications:

  • Git Bash
  • Git CMD
  • Git GUI

Continue reading

Installing Git on Ubuntu


Generating Ubuntu SSH key

Finding Ubuntu SSH key

Copy the  SSH-RSA text and paste it into your Git account’s key settings.

Continue reading

Git Local Overwrite

If your local repository is behind that of the remote repository and your locally tracked files differ from those of the remote repository, you will encounter an error. Performing the steps will result in the following:

  • If the locally tracked files exist on the remote repository, the remote files will overwrite the local files.
  • If the locally tracked files do not exist on the remote repository, they will be removed from your local repository.
  • If the local files are not being tracked, they will be left intact.

Continue reading