389COM: GitLab

Dr Carey Pridgeon, DR Nazaraf Shah

2016-08-06 Tue

Created: 2016-11-03 Thu 15:36

Working with the Gitlab Codebase

Starting the process

  • First you need to get the Virtualbox image we have created with the gitlab environment set up on it.


  • This has a clone of the main dev branch on it. They recommend creating a fork and using that.
  • With this image as a base you can do this if you want to, but you need to do it yourself, we don't have time to support you doing it.
  • You can create your own development environment. The links to do this are in this document, but again we can't support this.

Bug Fixing Process Guides

  • Gitlab has an active community, the main page of which is here

Before you work on a bug

  • pull the latest source (update your local copy with git pull).
  • Unless you have switched to your own fork, you can't push commits, but you can commit locally.
  • Should you mess up, you can reset to the latest upstream source with:
    • git fetch origin
    • git reset –hard origin/HEAD
    • git clean -d –force

Patch Handling

First, fix a bug

  • Once you have fixed a bug and tested it by reviewing the result in your gitlab instance, it's time to submit a patch.

Creating a patch

  • Gitlab have provided some rather complete documentation on patch creation here
  • In essence you create a diff file with changes between the last original commit and your one with the bug fix.
  • For this to work, your changes must be visible to git, so must be committed locally.

Local Patch Submission

Bug Patch Submission to Module Staff - 1

  • We can apply a patch to our Gitlab clone to test your bugfix, doing so will count towards your mark, but ultimately committing to Gitlab is the goal.
  • Patches to be applied locally must be submitted in plenty of time.
  • By this I mean not in the last week before submission, prefereably not in the last two weeks. We will try, but we will also be really busy.

Bug Patch Submission to Module Staff - 2

  • In folder /patches/gitlab on Nostromo, create a sub folder with your username or groupname.
  • In that folder create sub folders for each patch, named with the patch id eg 1026865, put in this the patch itself and a descriptive text file detailing what the patch is intended to do (typically the bug description from the Gitlab Issues page).
  • List the patch in This Document

Bug Patch Submission to Module Staff - 3

  • Email ab0475@coventry.ac.uk with the patch number and your Username/Group Name in the email header, and the descriptive text in the body.
  • Patches only count as being merged locally for assessment if you have an email from Nazaraf or myself saying it was merged and solved (or did not solve) the issue it was intended, to included in your patch submission portfolio.

Environment setup links

Obligatory XKCD


  • Copyright: Randall Munroe - XKCD
  • Mirrored in my hosting to avoid bandwidth stealing