Installing Gitea on a Raspberry Pi

While adding an integration for Gitea to GitHub Updater I stumbled upon the fact that many were installing Gitea on a Raspberry Pi. Now the Raspberry Pi has developed a cult-like following and the Internet is full of innumerable use cases.

Gitea is a very performant self-hosted git server written in Go. While working on GitHub Updater’s Gitea integration, I was looking for a way to continue to be able to test in the long term. The Gitea access I had during the development was gone and so I was looking for a solution. A Google search showed that many had successfully installed Gitea on a Raspberry Pi.

As of this writing the Raspberry Pi 3B+ is the latest model. It is quite capable for a credit card sized computer. The 3B+ comes complete with WiFi, HDMI, Ethernet, 4 USB ports, and a micro SD card reader all built in.

There are many posts and YouTube videos providing instruction on setting up a Raspberry Pi just to get the point where you can start.

tl;dr, it’s really simple.

However, that’s where the simple stopped. I found a couple of web pages that gave instructions on how to install Gitea and Go on the Raspberry Pi, but most were lacking in some way.

To that end I offer my own fork, Installing Gitea on a Raspberry Pi 3.

This version adds instructions that I have followed several times from the beginning to end and come out with a working Gitea server. Within the instructions are instructions on updating both Go and Gitea once the installation is complete.

I offer no warranties and make no claims other than it worked for me.

GitHub Updater and Gitea

Gitea is the new kid on the block for creating a self-hosted git server. Gitea is written in Go and is highly performant with very low overhead. In fact, Gitea is so efficient you can run it on a Raspberry Pi. There’s another post coming about that. 😉

As with most integrations of new git servers into GitHub Updater it all starts with an issue and a user willing to help. In this case, the user was Marco Berchart.

Over the years, I’ve continued to refactor GitHub Updater to become more OOP based and adding Gitea support definitely shows that this was the way to go. Adding support for Gitea was far and away the simplest integration yet. Much of this has to do with API closely following the GitHub API.

Marco was kind enough to start by creating  a PR and we were able to work on a branch until it was complete and able to be merged. There is a demo site at https://try.gitea.io where a test account can be created. There is no guarantee any sort of persistence and don’t expect your data, or possibly even your user, to be around long term. Marco was able to provide an account on his Gitea instance for me to test. I couldn’t have finished the integration with this access.

Since then I have figured out how to install Gitea on a Raspberry Pi. I’ve actually done the process several times and even updated both Go and Gitea. It makes testing much easier for me and it makes setting up your own local git server for less than $100 simple.

GitHub Updater – the Path to 8

In July it will have been 5 years since the first commit to GitHub Updater. In its 5 year span it has grown significantly in its evolution from a single file plugin to the complex integrated object oriented plugin that exists today.

Version 8 will see a bump in the requirement to at least PHP 5.6. Yes, it does work in PHP 7.2 but as PHP 5.6 is the lowest version of PHP still supported, I thought this was a nice minimum requirement. When PHP 5.6 becomes EOL’d I will transition up to PHP 7. I can only hope that at some point WordPress follows suit. I have learned that what this also means is that the bootstrap file needs to be compliant with a lower PHP version or the file will white screen the user’s site.

Version 8 has also seen a more modular architecture to the core of the plugin. What this means is that I’ve added a number of hooks to now allow me to keep most of the specific code siloed into its own classes. This has especially been beneficial to the Settings and Install functions.

In the Settings, this can result in a slight cosmetic difference as the APIs are hit and the server specific subtabs display. I’ve added a number of icons, tooltips, and notices to let the user know what’s happening and that no it’s not broken.

In case I haven’t mentioned it before, GitHub Updater also works with WP-CLI and can be used with a webhook for a continuous integration type of updating.

There’s already been a bump to version 8.1.1. The new feature is automatic renaming of the GitHub Updater plugin upon activation. If the plugin is renamed the activation fails as the activated plugin no longer exists. It has been renamed. 😉

As always, the best source of current information about GitHub Updater is the wiki.

Here’s the changelog.

Local by Flywheel (Pressmatic) and Symlinks

I’ve changed development environments a couple of times. I started out using DesktopServer, a wonderful app. Gradually I grew disappointed with their update schedule and v4.0 ever on the horizon. One of the things I didn’t like was my inability to choose the PHP version I was developing in. I know there must be a way but it wasn’t obvious.

Feeling like I needed a challenge, I set out to learn how to use Vagrant and VVV cause all the cool kids were using it. Once I got it up and running it worked well. There were a number of quirky things that I needed to figure out for my workflow.

From my initial time with DesktopServer I was using GitHub and local git on my MacBook Air, using Tower, for version control. Currently I’m using GitKraken, but that’s another post. I kept all my local repos synced on GitHub. When using DesktopServer I would create a symlink to the /wp-content/plugins or /wp-content/themes folder of the local environment from my local repo.

This didn’t quite work in VVV as symlinks don’t work in Vagrant. Vagrant requires creating a synced folder which is similar, but not the same. I was able to create a Customfile, custom config file, for my VVV installation that would create synced folders at each vagrant up. This synced folder appeared on the desktop as an empty folder but in the site it ran perfectly. The problem was that in my IDE, PhpStorm, there was nothing in the folder to edit. I found that removing this synced folder and replacing it with an actual symlink made everything work in both my IDE and on the site. Perfect, I was back to my usual workflow.

The issue I had was that every time I did a vagrant up or a vagrant reprovision, Vagrant would destroy my synced folder and I would have to run the Customfile again to recreate it. As many know, Vagrant isn’t a speed demon during a vagrant up and the additional code of creating multiple synced folders was considerable. Add to that the extra step of creating the symlinks each time, then I was set.

When Pressmatic came on the scene I was already considering dipping my hand into Docker, but was slightly intimidated. Pressmatic made all of that so much simpler. Pressmatic was purchase by Flywheel, rebranded and released as a free tool, Local by Flywheel. OK so the name is kinda blah and the really cool Pressmatic logo is no more, but it works great! Local soon developed an add-on that created shared/synced volumes which pretty much was the same result as my Customfile in VVV. The only problem was I couldn’t find any simple way to re-create my experience of switching to a symlink. Part of the problem was that I was very dissatisfied with amount of time required at provisioning in Vagrant and the thought of having to do this multiple times a day was daunting.

I changed my workflow to use an small app that synced folders in the background. It worked, but was clearly a kludge. Out of curiousity I created a synced folder using the Local by Flywheel Volumes Addon and then changed this folder to a symlink. Instantly I was back in business when using my IDE. The best part was that the symlink persisted through the Local Machine restarts and re-provisioning the individual sites.

Since then I’ve created a bash script to automatically create the symlinks after the Volumes have been added. I can now effectly re-create my normal workflow and even better as in Docker, synced folders seem to be persistent.

I’m sure my understanding of synced folders was probably incorrect and they were persistent all along. I just didn’t see it at the time.

As of this writing both Local by Flywheel and the Volumes addon have been updated several times. The current versions are completely compatible and functional.

This setup may not be for everyone, but I’ve found it allows me to develop locally and continue to use git for version control.

GitHub Updater & GitLab

GitLab Support

I’ve finally been able to add support for GitLab in the GitHub Updater v4.5.0. Additionally, support for GitLab CE and GitLab Enterprise are also included. All that’s required is an additional header with the base URI for the GitLab server. As an example, GitLab CE: https://gitlab.example.com or GitLab Enterprise: https://gitlab.example.com.

Extras for GitHub

Support for GitHub Enterprise is also included using a similar header, GitHub Enterprise: https://github.example.com.
Support for updating from GitHub assets is also included if an asset exists for a tagged release. It will be preferentially used for the update. Using an asset’s URI for the remote installation of a plugin or theme will also function as expected.

Under the Hood

A bit of refactoring has been done as well. An abstract class API has been created to simplify the structure of all the git server API classes. Additionally a class Messages has been created to hold admin notices.
The class Base has been refactored to hold information regarding the added APIs in static arrays for use throughout the codebase.
I hope everyone likes the changes and updates. As always, if there are problems or improvements, please create an issue on GitHub.
Thanks.