Introduction

Like most developers I’m a bit paranoid about backups and I really dislike having to repeat something I’ve already done, so I have a Raspberry Pi (named ‘Sara’):

which I use to store my git repositories. And as an upstream remote its also useful for keeping other machines in sync with another copy of the code:

using a pure command line interface, such as:

mkdir moodle-theme_shoelace.git
cd moodle-theme_shoelace.git
git init --bare

but, is this ideal? I use GitHub to store my public repositories, github.com/gjb2048, but what about the same sort of thing locally? In the past GitLab has been mentioned to me so I decided to take a look.

Disclaimers

Firefox® is a registered trademark of the Mozilla Foundation.

Ubuntu® is a registered trademark of Canonical Ltd – www.ubuntu.com/legal/terms-and-policies/intellectual-property-policy

Moodle™ is a registered trademark of ‘Martin Dougiamas’ – moodle.com/trademarks.

Other names / logos can be trademarks of their respective owners. Please review their website for details.

I am independent from the organisations listed above and am in no way writing for or endorsed by them.

GitLab

Looking at GitLab’s website, about.gitlab.com/installation, I saw that there is an installation for the Raspberry Pi 2. Crumbs I thought! I have a B+ and a 3, so I can use the 3 as that is an advancement on the 2, odd though that the installation requirements say a minimum of 4GB of RAM when the Pi only has 1GB? But, I thought, must be a cut down version then? How wrong I was. I installed the community edition (‘sudo apt-get install gitlab-ce’) as per their instructions and ops! Running ‘top’ in another shell showed that the CPU was running at 100% most of the time and GitLab was unresponsive. So glad that I got the heat-sink for the CPU. After a few hours of struggle I gave up and performed the slightly tedious method of uninstalling.

The hunt for alternatives

Not one for quitting I started to search for alternatives. Surely there must be some out there?

So I started to search and found:

• Apache Allura, allura.apache.org, but looking at the installation instructions, forge-allura.apache.org/docs/getting_started/install_each_step.html, that mentions Docker and a virtual machine, so I’m fairly certain that the Pi would not be able to cope.
  GitBucket, github.com/gitbucket/gitbucket, it runs on Java 8, used Java before and installed the OpenJRE for version 8. But again like GitLab the performance was not great.

Then I came across Gogs, gogs.io, it says it is lightweight and runs on a Pi, so gave it a go.

Gogs

Installation

Installing from the binary, gogs.io/docs/installation/install_from_binary and following the intital configuration gogs.io/docs/installation/configuration_and_run.html was not enough initial information as I really wanted to establish remote access from the start. Refering to gogs.io/docs/advanced/configuration_cheat_sheet I created a custom ‘app.ini’ file to get things going with the fixed IP (Internet Protocol) address I have for the Pi – not shown – but I set the HTTP_ADDR and DOMAIN settings. And as I’d created a new user called ‘gogs’ to keep things separate, the setting RUN_USER. To keep things simple I’ve opted for the SQLite3 database.

This got me up and running, but I was not completely happy as I have fixed IP addresses for my machines with associated names in their respective hosts files, so referring to gogs.io/docs/advanced/configuration_cheat_sheet again I made changes from IP to the hostname.

At this point the site was HTTP, but what about HTTPS? After a bit of hunting I found, gogs.io/docs/intro/faqs#how-do-i-set-up-https. And being local I’ve also changed to offline mode, gogs.io/docs/intro/faqs#how-do-i-run-gogs-in-offline-mode%2Fon-an-intranet.

Then finally after I’d played around with Gogs for a while and liked it, I wanted it to start on boot instead of manually. Looking at gogs.io/docs/intro/faqs#how-do-i-run-gogs-as-a-daemon, Gogs already comes with scripts to help. The OS I have on the Pi is Debian based (Rasbian) so a matter of learning about daemon’s and altering the script to match the user. Or you can use systemd: gogs.io/docs/intro/faqs#how-do-i-run-gogs-at-startup-with-systemd.

I did think about running on port 80, but that requires running as root, not a good idea with software you are testing out, so kept with the HTTP alternative port of 8080.

One tricky bit that caught me out was adding SSH access, which is done by adding your public key via the user interface:

This enables ssh communication for ‘push’, ‘pull’ and ‘fetch’ between the client and the repository on the Pi.

If you don’t know how to set-up ‘ssh’ access then follow: www.raspberrypi.org/documentation/remote-access/ssh/passwordless.md and www.raspberrypi.org/documentation/remote-access/ssh/ then you can generate another public / private key combination to use with Gogs and whichever git client you use: git-scm.com/downloads/guis or simply the shell.

Installation is not completely simple but I think that depends on your circumstances. You definitely need a bit of system administration knowledge.

The Gogs experience

The interface is really simple and feels familiar. You have three options:

Where there is a ‘Migration’ that I think duplicates the repostory from elsewhere and can be a ‘mirror’? There is no documentation that I can find about this. The documentation is a bit sparce, gogs.io/docs, but as Gogs is open source and you can contribute to both the documentation github.com/gogs/docs and the actual code github.com/gogs/gogs/wiki/Contributing-Code.

The third option of creating an organisation just allows you to organise your different repositories into groups, I chose ‘OrgMcOrgface’.

Creating a repository is really easy and can either be a public or private one:

which creates the repository in the folder on the Pi that you specified on installation. Then you are presented with instructions on what to do next:

After pushing your code, the dashboard does a good job of presenting the history of your actions:

You can view each repository with a familiar look:

and examine what a particular commit did:

and even compare branches:

which gives:

Where here you can see a part of the difference between the Moodle 3.4 and 3.5 versions of my Shoelace theme (moodle.org/plugins/theme_shoelace).

Gogs can be used both on intranets and on the internet, so does come with an activity page that shows what you’ve been doing:

as you would find on similar applications. Note: I believe that the eMail field is only displayed to logged in users.

User management

Even though I am using Gogs just for myself, it is designed to operate with many users, teams and organisations:

Issue management

There is an issue management system with labels:

What I like about it is that there is an overview screen across all repositories that you are a part of.

Wiki

You can document your repositories using a Wiki:

I’ve only created a few pages here to experiment, but I’m sure there is ways that you can link the pages. The pages are a separate repository so should be able to export them.

Backup

The repositories you create are stored as standard directories as before:

so you’ll be able to backup like any other Git repository.

Conclusion

Overall I like Gogs, it is simple and presents a familiar interface that reduces the command line instructions you have to do. It comes with the features you need to manage a repository used for development. I’m sure that there is more to Gogs and will see over the next few months how I get along.

If you do try out Gogs, then do please come back and comment on what you feel about it.

• About
• Latest Posts

Gareth Barnard

Developer at HRDNZ

Gareth is a developer of numerous Moodle Themes including Essential (the most popular Moodle Theme ever), Foundation, and other plugins such as course formats, including Collapsed Topics.

Latest posts by Gareth Barnard (see all)

• Added value – 16th September 2024
• What is a developer? – 16th August 2024
• A little boost – 16th July 2024