Dr Carey Pridgeon, DR Nazaraf Shah
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
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.
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 email@example.com with the patch number and your
Username/Group Name in the email header, and the descriptive text in
- 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.
- Copyright: Randall Munroe - XKCD
- Mirrored in my hosting to avoid bandwidth stealing