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.
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.
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.
So GitHub Updater just received a couple of new features in version 4.3.0.
At the suggestion of @mlteal, there is now a setting to add a personal GitHub Access Token. You must at least select
public_repos. What this does is blast away the limit of 60 API calls per hour and raises it to 5000 API calls per hours. If you need more than than I’ve got nothing more for ya. :smiley:
At the suggestion of our friends at Pods I’ve added the ability to switch between branches of a plugin. You must ensure that all branches have the appropriate headers otherwise you may find yourself unable to update. :frowning:
@szepeviktor has been driving me to fix a number of things including now having View details available on the plugins page.