Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
GPIO Pinout
Raspberry Pi Wishlist
Comparison Chart
Quiz
Group Actions
Engagement
  • Author Author: koudelad
  • Date Created: Date Created
  • Views 3279 views
  • Likes 7 likes
  • Comments 5 comments
Related
Recommended

Raspberry Pi 4B and Gitlab, part 1

koudelad

https://upload.wikimedia.org/wikipedia/en/thumb/c/cb/Raspberry_Pi_Logo.svg/100px-Raspberry_Pi_Logo.svg.pngimage

Introduction

I am one of the winners of a brand new Raspberry Pi 4B https://www.element14.com/community/docs/DOC-93093/l/announcing-our-raspberry-pi-4-giveaway-winners . My project proposal was to try running a Gitlab server https://about.gitlab.com/ on the Pi. Gitlab is much more than just source code management tool (based on Git, of course). It also includes a project management and a ticket system and continuous improvement / continuous delivery (CI/CD) support. There are two options to run this application – hosted or installed on-premise. Both installation variants have currently four versions. The basic is always free, the other versions are paid, but more feature-rich. I know Gitlab as a user from my work, but I haven’t paid attention to the installation details until recently, when I saw that there is a package for the Raspberry Pi. Is it possible to run such a complex tool on the Pi? Let’s find out...

 

First Impressions

I know there are and will be many reviews, tests and benchmarks of the new Pi 4 on the internet, but I can’t resist writing a few sentences about the Pi itself.

 

imageimageimageimage

 

I receiver just the Pi, so I immediately had to buy the rest of the necessary stuff: power supply, SD card, microHDMI cable, cooling accessories etc.

 

image

 

Here comes the first difference – new power supply is connected via a USB-C connector and the specification says 3 Amps are needed (old supply used microUSB and supplied 2.5 Amps). I bought the original one and had no doubts it will work. I also tried a non-original microUSB adapter (which could supply up to 3 Amps) and a microUSB<>USB-C adapter. This setup also worked.

 

I found some older Kinston SDHC 8 GB Class 10 card at home. Later I decided to do some performance comparision. I chose microSD card according to this benchmark: https://www.jeffgeerling.com/blog/2019/raspberry-pi-microsd-card-performance-comparison-2019

One of the cheapest, but also most powerful cards was SanDisk Micro SDHC Extreme 32GB 100MB/s A1 UHS-I U3 V30. As it turned out later, there is a huge difference in SD cards performance!

 

After reading a few reviews, I already knew there is no point in putting the Pi into a solid enclosure (especially the original one), so I currently run a bare board. The idle temperature is about 55 Centigrade and gets to ca. 65 during non-intensive work. I haven’t applied a heat-sink yet, but I have one prepared for future use. And a 4 x 4 cm fan if it won’t be enough.

 

Basic setup

I don’t want to go into much detail in this part, there is a ton of information about the basic setup.

 

  1. Prepare SD card with a Raspbian image. I chose Raspbian Buster with desktop (but not all the software) https://www.raspberrypi.org/downloads/raspbian/
  2. Boot the Pi, finish the setup process.
  3. Update the Pi (if not performed in the previous step) https://www.raspberrypi.org/documentation/raspbian/updating.md
  4. Change the default’s user credentials, enable SSH / VNC or other form of a remote access.

https://www.raspberrypi.org/documentation/remote-access/ssh/

https://www.raspberrypi.org/documentation/remote-access/vnc/

If your VNC server doesn’t always start automatically, there is a known issue with a solution: https://help.realvnc.com/hc/en-us/articles/360021693151-VNC-Server-does-not-start-on-Raspberry-Pi-unless-a-mouse-keyboard-are-connected

My plan is running the Pi as a server, without keyboard, mouse, display.

 

Gitlab setup

Gitlab developers recommend downloading and installing an Omnibus package of Gitlab as the fastest and easiest option. There is also a manual for installing Gitlab on a Raspberry Pi, but at the time of writing this blog post, it worked only for Pi 2/3/4 running Raspbian based on Debian Stretch. However, current version of Raspbian is based on Debian Buster.

Please note that if there is an official updated manual for Buster, do not follow the steps below. Use the official manual. The current (September 2019) official manual is located here: https://about.gitlab.com/install/#raspberry-pi-2

I tried to contact the Gitlab support, asking for an installation manual update. Even though I don’t have a subscription or a paid licence, I got a polite answer with helpful resources and a promise that as soon as there will be builds for Buster (armhf architecture), the manual will be updated. The main steps are described here: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4461#note_192058612

Step one downloads the package. Be prepared for a 630 MB download!

curl -Lo gitlab-ce_12.2.5-ce.0_armhf.deb https://packages.gitlab.com/gitlab/raspberry-pi2/packages/raspbian/stretch/gitlab-ce_12.2.5-ce.0_armhf.deb/download.deb

image

 

Now install the downloaded package:

sudo apt install ./gitlab-ce_12.2.5-ce.0_armhf.deb

 

image

Note: in the beginning, if you search for a package using a keyword “gitlab” in Raspbian, you get a few community built packages, but not the official “gitlab-ce” package as described above!

image

Now let’s get back to a gitlab-ce package installation. The installation took almost 2 minutes (10 minutes with an older card!) and as you can see in the previous screenshot, consumed almost 1800 MB.

image

As suggested at the end of the installation, it is necessary to set an IP of the Pi to the external_url parameter in the configuration file. I put my local IP of the Pi there (don't delete the http:// ).

sudo nano /etc/gitlab/gitlab.rb

image

I skipped the recommended Pi-specific changes (creating swap, reducing the number of concurrent processes, optionally creating ZRAM swap) and started a recofiguration.

sudo gitlab-ctl reconfigure

The reconfiguration took 7 minutes.

image
By the way, it took 27 minutes image with the old SD card and threw some Grafana error.

Either way, the server seems to be running. When I pointed my computer browser to Pi’s IP, it showed the default password reset dialog. The installation is complete!

image

After setting a new password, the login / registration page appears. I signed in with the root account and freshly reset password.

image

Here comes the default page for the administrator:

image

You might have noticed that I haven’t set up SSL for the access. Gitlab installation offers automatic certificate request for your domain at a certification authority, however, I run this as a test application in my local network. If you want to know more about SSL, see this documentation page: https://docs.gitlab.com/omnibus/settings/ssl.html


I will divide this topic into a few shorter blog posts, in order to be easier to read. Next part will be about creating a project a starting a version control of it.

  • in reply to 14rhb

    Do not worry, I also haven't heard about Gitlab until I got a new job 12 months ago. I am still a beginner regarding version control systems.

     

    At work, we have strict rules about branching and merging, as I linked in my previous comment. At home, I use currently use just one development branch continuously. I have a few firmware projects that share some source and header files and the most valuable for me is just the possibility to see a previous version. Git is architecturally decentralized, but I want to use one device to synchronize against (similarly as in centralized VCSs).

     

    If you don't mind uploading the code to a 3rd party server, Github, Gitlab, Bitbucket and similar are often chosen to start with. All offer free plans for small teams / a few projects.

     

    https://about.gitlab.com/pricing/

     

    https://github.com/pricing#feature-comparison

     

    https://bitbucket.org/product/pricing

     

    I chose to try installing Gitlab locally, but these cloud solutions are simply ready to be used immediately.

     

    There is also a clear movement towards continuous integration / continuous delivery concepts. For example every commit can trigger static checks, unit checks, etc. Merging to a special release branch triggers a release to a server / device etc. It is always specific in the area of embedded development, but we can learn a lot from software developers. These tools and scripts require some works, but are a huge time-saver later.

     

    I could mention some more real-life examples, if you wanted.

  • in reply to koudelad

    A very good example and great explanation   which should encourage others to adopt Gitlab/Git/other. Your explanation is the exact sort of issue I was describing regarding 'IDE manage the whole project' and what drove me to llok at Git.

     

    I have a confession having said I never heard of Gitlab. Tidying up yesterday I found a sticker on my notebook and the shape of it reminded me it was for a version control software company - I looked at the rest of my stickers on my laptop and can see a Gitlab sticker....now I remember being visiting their roadshow stall and talking to them.

  • Thank you, and .

     

    For my hobby projects, I also previously created a zip archive for every version. I used only a few source files and it was somehow manageable.

     

    I also have an example where the device manufacturers can make life much harder:

    A few years ago, I started playing with PSoCs and their IDE, the PSoC Creator. There is no built in version control system (VCS) support, so I stuck with zip archives. One part of a PSoC development is creating the component structure in graphical editor. (Here is an example from PSoC ultrasonic range meter ):

    image

     

     

    Later, during compilation, tens or hundreds of source and header files are generated. If you want to fully control your source code and have the ability compile the code later without the IDE, you need to have the files in one pack - but there are also other non-source files, which are unnecessary to version as they only clog the repository (because they change every compilation).

    One solution was zipping the entire project. The other is use VCS without the connection to the IDE, which is what I recently chose. If you want to know see more, have a look at my post, just see the .gitignore file. Version control in PSoC Creator

     

    When starting with version controlling, it is always a bit painful transition, but it pays off. Gitlab or similar SW / service can help a lot.

    I will insert a link in the next part, but a key factor to success is discipline, good tool set and a good branching model. Many companies use this one: https://nvie.com/posts/a-successful-git-branching-model/

     

    I hope I will get to writing a next part soon, but we are doing a small reconstruction and redecoration at home.

  • Great blog!  This is definitely something that I should learn more about.  Back in my early days of Unix, RCS was such a useful tool.  As I moved into the world of development on DOS, all of the early clones of RCS were very flaky and I lost more code than I saved, leaving me very leery of these clones.  Since then, I have reverted to saving sources for each version, but I really need to rejoin the present and find a better solution.  Thanks for the push in right direction.

  • A great blog, thank you . I hadn't heard of Gitlab before but it makes absolute sense allowing better remote working in teams I guess. I'm looking forward to your follow on blogs.

     

    I've recently started to get into using git and really like the way you can jump back and forth, create branches and highlight all the differences. I used to just keep saving the files as new versions but that started to become awkward when IDE manage the whole project and you aren't always sure where the files are. I also know just enough git to be dangerous to my projects - I've managed to add so much as to make them almost break or have got lost as to what branch/revision I should be in. But like most things - practice and application always help the learning....so onwards image