Install plugins on start up.

When calling gerrit init --batch, it is possible to list plugins to be installed with --install-plugin=<plugin_name>. This can be done using the GERRIT_INIT_ARGS environment variable. See Gerrit Documentation for more information.

Extend this image.

Similarly to the Postgres image, if you would like to do additional configuration mid-script, add one or more*.sh or *.nohup scripts under /docker-entrypoint-init.d. This directory is created by default. Scripts in /docker-entrypoint-init.d are run after gerrit has been initialized, but before any of the gerrit config is customized, allowing you to programmatically override environment variables in entrypoint scripts. *.nohup scripts are run into the background with nohup command.

You can also extend the image with a simple Dockerfile. The following example will add some scripts to initialize the container on start up.

Using gitiles instead of gitweb

Setup DEVELOPMENT_BECOME_ANY_ACCOUNT option

DO NOT USE. Only for use in a development environment.When this is the configured authentication method a hyperlink titled "Become" appears in the top right corner of the page, taking the user to a form where they can enter the username of any existing user account, and immediately login as that account, without any authentication taking place. This form of authentication is only useful for the GWT hosted mode shell, where OpenID authentication redirects might be risky to the developer's host computer, and HTTP authentication is not possible.

Override the default startup action

Gerrit is launched using the daemon action of its init script. Thisbrings the server up without forking and sends error log messages to theconsole. An alternative is to start Gerrit using supervise which isvery similar to daemon except that error log messages are persisted to${GERRIT_SITE}/logs/error_log.

Gerrit can be started with a non-default action using theGERRIT_START_ACTION environment variable. For example, Gerrit can bestarted with supervise as follows:

NOTE: Not all init actions make sense for starting Gerrit in a Dockercontainer. Specifically, invoking Gerrit with start forks the serverbefore returning which will cause the container to exit soon after.

Sample operational scripts

An example to demonstrate the way of extending this Gerrit container to integrate with Jenkins are located in openfrontier/gerrit-docker project.

A Jenkins docker image with some sample scripts to integrate with this Gerrit image can be pulled from openfrontier/jenkins.

There's an upper project which privdes sample scripts about how to use this image and a Jenkins image to create a Gerrit-Jenkins integration environment. And there's a compose project to demonstrate how to utilize docker compose to accomplish the same thing.

Sync timezone with the host server.

Automatic reindex detection

The docker container automatically writes the current gerrit version into ${GERRIT_HOME}/review_site/gerrit_version in order to detect whether a full upgrade should be performed. This check can be disabled via the IGNORE_VERSIONCHECK environment variable.

Note that for major version upgrades a full reindex might be necessary. Check the gerrit upgrade notes for details. For large repositories, the full reindex can take 30min or more.