We are pleased to announce the general availability of RPM and Debian native distributions for Gerrit Ver. 2.10. They have been packaged from the original Gerrit WAR using the new native installers tools developed and contributed back to the Gerrit community.

Why yet another packaging format?

Gerrit Code Review has always been released as pure Java executable WAR that has then to be invoked with a target installation directory. This style of packaging has been working fine right now, however many companies use the Linux native software packaging tool to standardise the way they install and update software.

The reasons behind that choice are:

• automatic compatibility matrix and dependencies tracing and resolution: Gerrit dependencies are automatically checked and download upon installation
• automatic update of the latest patch-set released on Gerrit using “yum update” or “apt-get install –only-upgrade”
• out-of-the-box support for Puppet / Chef for unattended installations
• compliance with company standards: system administrators do not have to manage a “special case” for Gerrit

What type of packages are provided?

The following two packaging formats are currently supported:
– RPM packages for RedHat / CentOS Linux distributions
– Deb packages for Ubuntu or other Debian distributions

How to enable Gerrit native packages on my Linux system?

Gerrit packages are distributed using the native repository distribution system provided by the Linux distribution:

• YUM repository for RedHat / CentOS
• Debian source for Ubuntu

To facilitate the set-up, GerritForge provided an RPM for RedHat / CentOS that will do the job for you:

rpm -i https://gerritforge.com/gerritforge-repo-1-5.noarch.rpm

On Ubuntu 14.x up to 16.x / Debian you need to define the extra source pointing to the GerritForge distribution site:

echo "deb mirror://mirrorlist.gerritforge.com/deb gerrit contrib" > /etc/apt/sources.list.d/gerritforge.list

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1871F775
apt-get update

On Ubuntu 18.x or alter you need to define a specific source pointing to the GerritForge distribution site with higher security keys and hashing requirements:

echo "deb mirror://mirrorlist.gerritforge.com/bionic gerrit contrib" > /etc/apt/sources.list.d/gerritforge.list

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 55787ed781304950
apt-get update

Once the additional distribution repository has been configured, installing Gerrit 2.10 and all future versions will be just one command away and can be completely automated.

Simpler or more complex than Gerrit init wizard?

The complexity of a native packaging system is all concentrated in the first repository set-up, however it is aligned with any other type of repository additions that System Administrators are very familiar with.

Once the repository set-up phase is finalised, then installing a working version of gerrit is just one command away:

On RedHat / CentOS you simply need to execute:

yum install -y gerrit

On Ubuntu / Debian the command is:

apt-get install gerrit

Additional once configured for production, the configuration files are kept across updates and you can get constantly aligned with the most updated patch-level for your installation.

Gerrit then appears in the list of the installed software alongside with its version number and patch-level.

What is the Gerrit default configuration for native packaging?

Gerrit comes out-of-the-box with a “playground-style” configuration, to allow to have a working instance that can be verified without the need of any extra configuration step:

• H2 Database
• DEVELOPMENT_BECOME_ANY_ACCOUNT authentication
• HTTP (no SSL) and SSH protocols

Once installed, the System Administrators will need to go through the Gerrit documentation and configure the authentication, security protocols and DB of choice. All configuration settings will remain local and will be kept across package upgrades.

Who is hosting Gerrit native packages?

Gerrit native packaging hosting follows the typical strategy of the native distribution sites: a list of mirrors that will be automatically chosen by the Linux installer based on speed and location.

We currently have two mirrors:

• dl.bintray.com – kindly offered by JFrog
• gerritforge.com – kindly offered by GerritForge

The list of sources can be extended as the native packaging systems allow to define a set of mirrors that are automatically selected based on your location and speed.

If anyone is willing to host a mirror of those native packages, please contact GerritForge or post a message on the Gerrit mailing list and we’ll update the official list of mirrors available.

How to tailor Gerrit native packages for your Company?

Gerrit RPM and Deb packages are built using 100% OpenSource tools and scripts published. Just checkout the gerrit-installer project and make the packages again defining your desired version, organisation and distribution URLs.

What’s next?

We are going to publish soon more native packaging formats:

• Docker (coming very soon)
• MacOS Pkg
• Windows MSI

Stay tuned and let us know what do you think.

Dear GerritHub.io users,
thank you for your patience, the service is up and running again.

We are currently working to increase the capacity of the service, based on the increasing audience received. Additionally we are working to increase the security and provide an active failover on multiple geo-localised IPs: once the service will be available you will be notified on GitEnterprise.me and on Twitter @gitenterprise.

GerritForge Support Team

Dear GerritHub.io users,
because of unexpected maintenance activity not dependant on our will, the GerritHub.io service is not accessible at the moment.

Your data is always safe and replicated in real-time to GitHub, including your code under review. Should you need urgently to access your source files you can access them through your GitHub repository associated.

Example:
GerritHub URL => https://review.gerrithub.io/mylogin/myproject.git
GitHub    URL => https://github.com/mylogin/myproject.git

We are  speeding-up the maintenance activity in order to bring the service back on-line as soon as possible: we do apologise for any inconvenience caused by this temporary disruption.

GerritForge Support Team

GitHub is finally back, after 4h of outage because of a DDoS attack: we can all come back to push changes and the Continuous Integration Engine (e.g. Jenkins) will start building again.

The problem is: how much money you have lost in those 4h of outage ? 50 Developers at $500/day would have costed over over $12,000 … can your Business cope with that risk again and associated losses ?

Having another mirror, a spare wheel either on-premises or on the Cloud, would cost nothing and allow you to limit your costs in case of another GitHub outage ! Give a try to http://gerrithub.io or install Gerrit Code Review on your premises and protect your Development Team.

This morning GitHub is down again, not the first time unfortunately !

If you want to keep using GitHub but NOT being blocked when it is down, you can use Gerrit Code Review replication for having an always up-to-date replica. With the GitHub plugin, your accounts and repositories are always in synch and can be used for failover.

Read how to use GitHub and Gerrit Code Review on http://www.packtpub.com/article/using-gerrit-with-github

If you want to use Gerrit with GitHub on the Cloud, register today at http://gerrithub.io and next time that GitHub will be down, you will not be affected.

Someone may correctly ask why do we need another Git hosting solution, while we have such a wide choice around, like github or bitbucket (just to name few). The thing is that an enterprise solution is missing. In our everyday work in a big firm we are experiencing these issues:

• there’s no real security or access control system available out of the box with git, and the level you can achieve is far away too coarse grained to be really useful
• there’s no real way to easily administer a git repository in order to eventually manage anything, from users to privileges
• integration with modern IDE, particularly Eclipse, is really disappointing, so that being productive is really difficult
• there’s no real way go visualize the status of a central repository, which definitely happens when git is used in an enterprise environment
• the freedom of Git sometimes bring your project, and your repository, in a kind of “cowboy” state that is far from acceptable by an enterprise

We appreciate all these issues, and we want to provide a fix for them, so that Git may be adopted widely from enterprises, our personal problems will be solved and, eventually, we will be able to get some money out of this.

Dream? Fact. Development is started and the code is near to be production ready. So please, you guys, that landed here in search for an enterprise solution, stay tuned.