This is a cheat sheet for the Gitea configuration file. It contains all settings that can configured.
This is a cheat sheet for the Gitea configuration file. It contains most settings
that can configured as well as their default values.
Any changes to the Gitea configuration file should be made in `custom/conf/app.ini` or any corresponding location. When installing from a distribution, this will typically be found at `/etc/gitea/conf/app.ini`.
Any changes to the Gitea configuration file should be made in `custom/conf/app.ini`
or any corresponding location. When installing from a distribution, this will
typically be found at `/etc/gitea/conf/app.ini`.
The defaults provided here are best-effort (not built automatically). They are accurately recorded in [app.ini.sample](https://github.com/go-gitea/gitea/blob/master/custom/conf/app.ini.sample) (s/master/<tag|release\>.Anystringintheformat`%(X)s`isafeaturepoweredby [ini](https://github.com/go-ini/ini/#recursive-values),forreadingvaluesrecursively.
The defaults provided here are best-effort (not built automatically). They are
accurately recorded in [app.ini.sample](https://github.com/go-gitea/gitea/blob/master/custom/conf/app.ini.sample)
by [ini](https://github.com/go-ini/ini/#recursive-values), for reading values recursively.
Values containing `#` or `;` must be quoted using `` ` `` or `"""`.
@ -28,22 +34,34 @@ Values containing `#` or `;` must be quoted using `` ` `` or `"""`.
## Overall (`DEFAULT`)
- `APP_NAME`: **Gitea: Git with a cup of tea**: Application name, used in the page title.
- `RUN_USER`: **git**: The user Gitea will run as. This should be a dedicated service (non-user) account. Setting this incorrectly will cause Gitea to not start.
- `RUN_MODE`: **dev**: For performance and other purposes, change this to `prod` when deployed to a production environment. The installation process will set this to `prod` automatically. \[prod, dev, test\]
- `RUN_USER`: **git**: The user Gitea will run as. This should be a dedicated system
(non-user) account. Setting this incorrectly will cause Gitea to not start.
- `RUN_MODE`: **dev**: For performance and other purposes, change this to `prod` when
deployed to a production environment. The installation process will set this to `prod`
automatically. \[prod, dev, test\]
## Repository (`repository`)
- `ROOT`: **~/gitea-repositories/**: Root path for storing all repository data. It must be an absolute path.
- `SCRIPT_TYPE`: **bash**: The script type your server supports, usually this is `bash`, but some users report that only `sh` is available.
- `ROOT`: **~/gitea-repositories/**: Root path for storing all repository data. It must be
an absolute path.
- `SCRIPT_TYPE`: **bash**: The script type this server supports, usually this is `bash`,
but some users report that only `sh` is available.
- `ANSI_CHARSET`: **\<empty\>**: The default charset for an unrecognized charset.
- `FORCE_PRIVATE`: **false**: Force every new repository to be private.
- `DEFAULT_PRIVATE`: **last**: Default private when create a new repository. \[last, private, public\]
- `MAX_CREATION_LIMIT`: **-1**: Global maximum creation limit of repositories per user, `-1` means no limit.
- `PULL_REQUEST_QUEUE_LENGTH`: **1000**: Length of pull request patch test queue, make it as large as possible. Use caution when editing this value.
- `MIRROR_QUEUE_LENGTH`: **1000**: Patch test queue length, increase if pull request patch testing starts hanging.
- `PREFERRED_LICENSES`: **Apache License 2.0,MIT License**: Preferred Licenses to place at the top of the List. Name must match file name in conf/license or custom/conf/license.
- `DISABLE_HTTP_GIT`: **false**: Disable the ability to interact with repositories over the HTTP protocol.
- `USE_COMPAT_SSH_URI`: **false**: Force ssh:// clone url instead of scp-style uri when default SSH port is used.
- `DEFAULT_PRIVATE`: **last**: Default private when creating a new repository.
\[last, private, public\]
- `MAX_CREATION_LIMIT`: **-1**: Global maximum creation limit of repositories per user,
`-1` means no limit.
- `PULL_REQUEST_QUEUE_LENGTH`: **1000**: Length of pull request patch test queue, make it
as large as possible. Use caution when editing this value.
- `MIRROR_QUEUE_LENGTH`: **1000**: Patch test queue length, increase if pull request patch
testing starts hanging.
- `PREFERRED_LICENSES`: **Apache License 2.0,MIT License**: Preferred Licenses to place at
the top of the list. Name must match file name in conf/license or custom/conf/license.
- `DISABLE_HTTP_GIT`: **false**: Disable the ability to interact with repositories over the
HTTP protocol.
- `USE_COMPAT_SSH_URI`: **false**: Force ssh:// clone url instead of scp-style uri when
default SSH port is used.
## UI (`ui`)
@ -60,40 +78,43 @@ Values containing `#` or `;` must be quoted using `` ` `` or `"""`.
## Markdown (`markdown`)
- `ENABLE_HARD_LINE_BREAK`: **false**: Whether or not to enable hard the line break extension.
- `ENABLE_HARD_LINE_BREAK`: **false**: Enable Markdown's hard line break extension.
## Server (`server`)
- `PROTOCOL`: **http**: Either `http`, `https`, `fcgi`, or `unix`.
- `DOMAIN`: **localhost**: Domain name of your server.
- `LFS_CONTENT_PATH`: **./data/lfs**: Where to store lfs files.
- `LFS_CONTENT_PATH`: **./data/lfs**: Where to store LFS files.
- `LFS_JWT_SECRET`: **\<empty\>**: LFS authentication secret, change this a unique string.
- `REDIRECT_OTHER_PORT`: **false**: If true and `PROTOCOL` is https, redirects http requests on another (https) port.
- `REDIRECT_OTHER_PORT`: **false**: If true and `PROTOCOL` is https, redirects http requests
on another (https) port.
- `PORT_TO_REDIRECT`: **80**: Port used when `REDIRECT_OTHER_PORT` is true.
## Database (`database`)
- `DB_TYPE`: **mysql**: The database type you choose, either `mysql`, `postgres`, `mssql` or `sqlite3`.
- `DB_TYPE`: **mysql**: The database type in use \[mysql, postgres, mssql, sqlite3\].
- `HOST`: **127.0.0.1:3306**: Database host address and port.
- `NAME`: **gitea**: Database name.
- `USER`: **root**: Database username.
@ -111,31 +132,41 @@ Values containing `#` or `;` must be quoted using `` ` `` or `"""`.
## Security (`security`)
- `INSTALL_LOCK`: **false**: Disable to allow accessing the install page.
- `SECRET_KEY`: **random at every install**: Global secret key. This should be changed.
- `INSTALL_LOCK`: **false**: Disallow access to the install page.
- `SECRET_KEY`: **\<random at every install\>**: Global secret key. This should be changed.
- `LOGIN_REMEMBER_DAYS`: **7**: Cookie lifetime, in days.
- `COOKIE_USERNAME`: **gitea\_awesome**: Name of the cookie used to store the current username.
- `COOKIE_REMEMBER_NAME`: **gitea\_incredible**: Name of cookie used to store authentication information.
- `REVERSE_PROXY_AUTHENTICATION_USER`: **X-WEBAUTH-USER**: Header name for reverse proxy authentication.
- `DISABLE_GIT_HOOKS`: **false**: Prevent all users (including admin) from creating custom git hooks.
- `COOKIE_REMEMBER_NAME`: **gitea\_incredible**: Name of cookie used to store authentication
information.
- `REVERSE_PROXY_AUTHENTICATION_USER`: **X-WEBAUTH-USER**: Header name for reverse proxy
authentication.
- `DISABLE_GIT_HOOKS`: **false**: Prevent all users (including admin) from creating custom
git hooks.
## OpenID (`openid`)
- `ENABLE_OPENID_SIGNIN`: **false**: Allow authentication in via OpenID.
- `ENABLE_OPENID_SIGNUP`: **! DISABLE\_REGISTRATION**: Allow registering via OpenID.
- `WHITELISTED_URIS`: **\<empty\>**: If non-empty, list of POSIX regex patterns matching OpenID URI's to permit.
- `BLACKLISTED_URIS`: **\<empty\>**: If non-empty, list of POSIX regex patterns matching OpenID URI's to block.
- `WHITELISTED_URIS`: **\<empty\>**: If non-empty, list of POSIX regex patterns matching
OpenID URI's to permit.
- `BLACKLISTED_URIS`: **\<empty\>**: If non-empty, list of POSIX regex patterns matching
OpenID URI's to block.
## Service (`service`)
- `ACTIVE_CODE_LIVE_MINUTES`: **180**: Time limit (min) to confirm account/email registration.
- `RESET_PASSWD_CODE_LIVE_MINUTES`: **180**: Time limit (min) to confirm forgot password reset process.
- `REGISTER_EMAIL_CONFIRM`: **false**: Enable this to ask for mail confirmation of registration. Requires `Mailer` to be enabled.
- `DISABLE_REGISTRATION`: **false**: Disable registration, after which only admin can create accounts for users.
- `RESET_PASSWD_CODE_LIVE_MINUTES`: **180**: Time limit (min) to confirm forgot password reset
process.
- `REGISTER_EMAIL_CONFIRM`: **false**: Enable this to ask for mail confirmation of registration.
Requires `Mailer` to be enabled.
- `DISABLE_REGISTRATION`: **false**: Disable registration, after which only admin can create
accounts for users.
- `REQUIRE_SIGNIN_VIEW`: **false**: Enable this to force users to log in to view any page.
- `ENABLE_NOTIFY_MAIL`: **false**: Enable this to send e-mail to watchers of a repository when something happens, like creating issues. Requires `Mailer` to be enabled.
- `ENABLE_NOTIFY_MAIL`: **false**: Enable this to send e-mail to watchers of a repository when
something happens, like creating issues. Requires `Mailer` to be enabled.
- `ENABLE_REVERSE_PROXY_AUTHENTICATION`: **false**: Enable this to allow reverse proxy authentication.
- `ENABLE_REVERSE_PROXY_AUTO_REGISTRATION`: **false**: Enable this to allow auto-registration for reverse authentication.
- `ENABLE_REVERSE_PROXY_AUTO_REGISTRATION`: **false**: Enable this to allow auto-registration
for reverse authentication.
- `ENABLE_CAPTCHA`: **true**: Enable this to use captcha validation for registration.
## Webhook (`webhook`)
@ -151,43 +182,52 @@ Values containing `#` or `;` must be quoted using `` ` `` or `"""`.
- `HELO_HOSTNAME`: **\<empty\>**: Custom hostname for HELO operation.
- `HOST`: **\<empty\>**: SMTP mail host address and port (example: smtp.gitea.io:587).
- `FROM`: **\<empty\>**: Mail from address, RFC 5322. This can be just an email address, or the "Name" \<email@example.com\> format.
- `FROM`: **\<empty\>**: Mail from address, RFC 5322. This can be just an email address, or
the "Name" \<email@example.com\> format.
- `USER`: **\<empty\>**: Username of mailing user (usually the sender's e-mail address).
- `PASSWD`: **\<empty\>**: Password of mailing user.
- `SKIP_VERIFY`: **\<empty\>**: Do not verify the self-signed certificates.
- **Note:** Gitea only supports SMTP with STARTTLS.
- `USE_SENDMAIL`: **false** Use the operating system's `sendmail` command instead of SMTP. This is common on linux systems.
- Note that enabling sendmail will ignore all other `mailer` settings except `ENABLED`, `FROM` and `SENDMAIL_PATH`.
- `SENDMAIL_PATH`: **sendmail**: The location of sendmail on the operating system. (can be command or full path)
- `USE_SENDMAIL`: **false** Use the operating system's `sendmail` command instead of SMTP.
This is common on linux systems.
- Note that enabling sendmail will ignore all other `mailer` settings except `ENABLED`,
`FROM` and `SENDMAIL_PATH`.
- `SENDMAIL_PATH`: **sendmail**: The location of sendmail on the operating system. (can be
command or full path)
## Cache (`cache`)
- `ADAPTER`: **memory**: Cache engine adapter, either `memory`, `redis`, or `memcache`. If you want to use `redis` or `memcache`, be sure to rebuild everything with build tags `redis` or `memcache`: `go build -tags='redis'`.
- `ADAPTER`: **memory**: Cache engine adapter, either `memory`, `redis`, or `memcache`.
- To use `redis` or `memcache`, be sure to rebuild everything with build tags `redis` or
The main way to customize Gitea is by using the `custom` folder. This is the central place to override and configure features.
Customizing Gitea is typically done using the `custom` folder. This is the central
place to override configuration settings, templates, etc.
If you install Gitea from binary, after the installation process ends, you can find the `custom` folder next to the binary.
Gitea will create the folder for you and prepopulate it with a `conf` folder inside, where Gitea stores all the configuration settings provided through the installation steps (have a look [here](https://docs.gitea.io/en-us/config-cheat-sheet/) for a complete list).
If Gitea is deployed from binary, all default paths will be relative to the gitea
binary. If installed from a distribution, these paths will likely be modified to
the Linux Filesystem Standard. Gitea will create required folders, including `custom/`.
Application settings are configured in `custom/conf/app.ini`. Distributions may
provide a symlink for `custom` using `/etc/gitea/`.
If you can't find the `custom` folder next to the binary, please check the `GITEA_CUSTOM` environment variable, that can be used to override the default path to something else. `GITEA_CUSTOM` might be set for example in your launch script file. Please have a look [here](https://docs.gitea.io/en-us/specific-variables/) for a complete list of environment variables.
**Note** that you have to restart Gitea for it to notice the changes.
If the `custom` folder can't be found next to the binary, check the `GITEA_CUSTOM`
environment variable; this can be used to override the default path to something else.
`GITEA_CUSTOM` might, for example, be set by an init script.
- [List of Environment Variables](https://docs.gitea.io/en-us/specific-variables/)
**Note:** Gitea must perform a full restart to see configuration changes.
## Customizing /robots.txt
To make Gitea serve your own `/robots.txt` (by default, an empty 404 status is served), simply create a file called `robots.txt` in the `custom` folder with the [expected contents](http://www.robotstxt.org/).
To make Gitea serve a custom `/robots.txt` (default: empty 404), create a file called
`robots.txt` in the `custom` folder with [expected contents](http://www.robotstxt.org/).
## Serving custom public files
To make Gitea serve custom public files (like pages and images), use the folder `custom/public/` as the webroot. Symbolic links will be followed.
To make Gitea serve custom public files (like pages and images), use the folder
`custom/public/` as the webroot. Symbolic links will be followed.
For example, a file `image.png` stored in `custom/public`, can be accessed with the url `http://your-gitea-url/image.png`.
For example, a file `image.png` stored in `custom/public/`, can be accessed with
the url `http://gitea.domain.tld/image.png`.
## Changing the default avatar
Place the png image at the following path: `custom/public/img/avatar_default.png`
Place the png image at the following path: `custom/public/img/avatar\_default.png`
## Customizing Gitea pages
The `custom/templates` folder allows you to change every single page of Gitea.
You need to be aware of the template you want to change. All templates can be found in the `templates` folder of the Gitea sources.
When you find the correct .tmpl file, you need to copy it in the `custom/templates` folder of your installation, __respecting__ any subfolder you found in the source template.
The `custom/templates` folder allows changing every single page of Gitea. Templates
to override can be found in the `templates` directory of Gitea source. Override by
making a copy of the file under `custom/templates` using a full path structure
matching source.
You can now customize the template you copied in `custom/templates`, being carefully to not break the Gitea syntax.
Any statement contained inside `{{` and `}}` are Gitea templete's syntax and shouldn't be touch, unless you know what are you doing.
Any statement contained inside `{{` and `}}` are Gitea's templete syntax and
shouldn't be touched without fully understanding these components.
To add in custom HTML to the header or the footer of the page, in the `templates/custom` directory there are `header.tmpl` and `footer.tmpl` that can be modified. This is useful if you want to add in custom CSS files, or additional Javascript.
To add custom HTML to the header or the footer of the page, in the `templates/custom`
directory there is `header.tmpl` and `footer.tmpl` that can be modified. This can be
a useful place to add custom CSS files or additional Javascript.
## Customizing gitignores, labels, licenses, locales, and readmes.
Place your own files in corresponding sub-folder under `custom/options`.
Place custom files in corresponding sub-folder under `custom/options`.
We won't cover the basics of a Golang setup within this guide. If you don't know how to get the environment up and running you should follow the official [install instructions](https://golang.org/doc/install).
Familiarity with the existing [installation instructions](https://golang.org/doc/install)
is required for this section.
If you want to contribute to Gitea you should fork the project and work on the `master` branch. There is a catch though, some internal packages are referenced by their GitHub URL. So you have to trick the Go tool to think that you work on a clone of the official repository. Start by downloading the source code as you normally would:
To contribute to Gitea, fork the project and work on the `master` branch.
Some internal packages are referenced using their respective Github URL. This can
become problematic. To "trick" the Go tool into thinking this is a clone from the
official repository, download the source code using "go get" and follow these instructions.
```
go get -d code.gitea.io/gitea
```
Now it's time to fork the [Gitea repository](https://github.com/go-gitea/gitea) on GitHub, after that you should have to switch to the source directory on the command line:
Fork the [Gitea repository](https://github.com/go-gitea/gitea) on GitHub, it should
then be possible to switch the source directory on the command line.
```
cd $GOPATH/src/code.gitea.io/gitea
```
To be able to create pull requests you should add your forked repository as a remote to the Gitea sources, otherwise you can not apply the changes to our repository because of lacking write permissions:
To be able to create pull requests, the forked repository should be added as a remote
to the Gitea sources, otherwise changes can't be pushed.
You've got a working development environment for Gitea now. Take a look at the `Makefile` to get an overview about the available tasks. The most common tasks should be `make test` which will start our test environment and `make build` which will build a `gitea` binary into your working directory. Writing test cases is not mandatory to contribute, but we will be happy if you do.
This should provide a working development environment for Gitea. Take a look at
the `Makefile` to get an overview about the available tasks. The most common tasks
should be `make test` which will start our test environment and `make build` which
will build a `gitea` binary into the working directory. Writing test cases is not
mandatory to contribute, but it is highly encouraged and helps developers sleep
at night.
That’s it! You are ready to hack on Gitea. Test your changes, push them to your repository and open a pull request.
That's it! You are ready to hack on Gitea. Test changes, push them to the repository,
For `GOPATH`, check [official documentation about GOPATH environment variable](https://golang.org/cmd/go/#hdr-GOPATH_environment_variable).
For others, check [official documentation about variables used when it runs the generator](https://golang.org/cmd/go/#hdr-Generate_Go_files_by_processing_source).
For documentation about each of the variables available, refer to the
[official Go documentation](https://golang.org/cmd/go/#hdr-Environment_variables).
## Gitea files
* `GITEA_WORK_DIR`: Gitea absolute path of work directory.
* `GITEA_CUSTOM`: Gitea uses `GITEA_WORK_DIR`/custom folder by default. Use this variable to change *custom* directory.
* `GITEA_WORK_DIR`: Absolute path of working directory.
* `GITEA_CUSTOM`: Gitea uses `GITEA_WORK_DIR`/custom folder by default. Use this variable
to change *custom* directory.
* `GOGS_WORK_DIR`: Deprecated, use `GITEA_WORK_DIR`
* `GOGS_CUSTOM`: Deprecated, use `GITEA_CUSTOM`
## Operating system specifics
* `USER`: system user that launch Gitea. Useful for repository URL address on Gitea interface
* `USERNAME`: if no USER found, Gitea will try`USERNAME`
* `HOME`: User home directory path (**except if** you're running on Windows, check the following `USERPROFILE` variable)
* `USER`: System user that Gitea will run as. Used for some repository access strings.
* `USERNAME`: if no `USER` found, Gitea will use`USERNAME`
* `HOME`: User home directory path. The `USERPROFILE` environment variable is used in Windows.
### Only on Windows
* `USERPROFILE`: User home directory path. If empty, uses `HOMEDRIVE` + `HOMEPATH`
* `HOMEDRIVE`: Main drive path you will use to get home directory
* `HOMEDRIVE`: Main drive path used to access the home directory (C:)
* `HOMEPATH`: Home relative path in the given home drive path
## Macaron (framework used by Gitea)
* `HOST`: Host Macaron will listen on
* `PORT`: Port Macaron will listen on
* `MACARON_ENV`: global variable to provide special functionality for development environments vs production environments. If MACARON_ENV is set to "" or "development" then templates will be recompiled on every request. For more performance, set the MACARON_ENV environment variable to "production".
* `MACARON_ENV`: global variable to provide special functionality for development environments
vs. production environments. If MACARON_ENV is set to "" or "development" then templates will
be recompiled on every request. For more performance, set the MACARON_ENV environment variable
to "production".
## Miscellaneous
* `SKIP_MINWINSVC`: Do not run as a service on Windows if set to 1
* `SKIP_MINWINSVC`: If set to 1, do not run as a service on Windows.
* `ZOOKEEPER_PATH`: [Zookeeper](http://zookeeper.apache.org/) jar file path
@ -191,15 +197,18 @@ This option allows Gitea to log in to your SMTP host as a Gitea user. To configu
nsIdleTimeout: 0
```
- Import the LDIF (change localhost to an IPA server if needed), you’ll be prompted for your Directory Manager password:
- Import the LDIF (change localhost to an IPA server if needed). A prompt for
Directory Manager password will be presented:
```
ldapmodify -h localhost -p 389 -x -D \
"cn=Directory Manager" -W -f gitea.ldif
```
- Add an IPA group for gitea_users :
- Add an IPA group for gitea\_users :
```
ipa group-add --desc="Gitea Users" gitea_users
```
- Note: If you get an error about IPA credentials, please run `kinit admin` and give your admin account password.
- Note: For errors about IPA credentials, run `kinit admin` and provide the
domain admin account password.
- Now login to the Gitea as an Administrator, click on "Authentication" under Admin Panel. Then click `Add New Source` and fill in the details, changing all where appropriate to your own domain.
- Log in to Gitea as an Administrator and click on "Authentication" under Admin Panel.
Then click `Add New Source` and fill in the details, changing all where appropriate.
Gitea supports web hooks for repository events, you can find it in settings page(`/:username/:reponame/settings/hooks`). All event pushes are POST requests, and we currently support two formats: Gitea and Slack.
Gitea supports web hooks for repository events, this can be found in the settings
page(`/:username/:reponame/settings/hooks`). All event pushes are POST requests.
The two methods currently supported are Gitea and Slack.
### Event information
Following shows an example of event information that will be sent by Gitea to Payload URL:
The following is an example of event information that will be sent by Gitea to
All downloads come with SQLite, MySQL and PostgreSQL support, and are built with embedded assets. Keep in mind that this can be different for older releases. The installation based on our binaries is quite simple, just choose the file matching your platform from the [downloads page](https://dl.gitea.io/gitea), copy the URL and replace the URL within the commands below:
All downloads come with SQLite, MySQL and PostgreSQL support, and are built with
embedded assets. This can be different for older releases. Choose the file matching
the destination platform from the [downloads page](https://dl.gitea.io/gitea), copy
the URL and replace the URL within the commands below:
After following the steps above you will have a `gitea` binary within your working directory, first you can test it if it works like expected and afterwards you can copy it to the destination where you want to store it. When you launch Gitea manually from your CLI you can always kill it by hitting `Ctrl + C`.
After getting a binary, it can be tested with `./gitea web` or moved to a permanent
location. When launched manually, Gitea can be killed using `Ctrl+C`.
```
./gitea web
@ -34,12 +38,16 @@ After following the steps above you will have a `gitea` binary within your worki
### Old glibc versions
Older Linux distributions (such as Debian 7 and CentOS 6) may not be able to load the Gitea binary, usually resulting an error like ```./gitea: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./gitea)```. This is due to the integrated SQLite support in the binaries we provide. In the future, we will provide binaries without the requirement for glibc. As a workaround, you can upgrade your distribution or [install from source]({{< relref "from-source.en-us.md" >}}).
Older Linux distributions (such as Debian 7 and CentOS 6) may not be able to load the
Gitea binary, usually producing an error such as ```./gitea: /lib/x86_64-linux-gnu/libc.so.6:
version `GLIBC\_2.14' not found (required by ./gitea)```. This is due to the integrated
SQLite support in the binaries provided by dl.gitea.io. In this situation, it is usually
possible to [install from source]({{< relref "from-source.en-us.md" >}}) without sqlite
support.
### Running gitea on another port
If getting an error like `702 runWeb()] [E] Failed to start server: listen tcp 0.0.0.0:3000: bind: address already in use` gitea needs to be started on another free port. This is possible using `./gitea web -p $PORT`.
## Anything missing?
Are we missing anything on this page? Then feel free to reach out to us on our [Discord server](https://discord.gg/NsatcWJ), there you will get answers to any question pretty fast.
For errors like `702 runWeb()] [E] Failed to start server: listen tcp 0.0.0.0:3000:
bind: address already in use` gitea needs to be started on another free port. This
is possible using `./gitea web -p $PORT`. It's possible another instance of gitea
We have not published any real package yet, we will update this page directly when we start to publish packages for any Linux distribution, in the meantime you should follow our [installation from binary]({{< relref "from-binary.en-us.md" >}}) guide.
The only distribution that has any "official" package of Gitea is Debian. This is currently
in Debian's [contrib](https://wiki.debian.org/SourcesList). This is (currently) only available
in Debian testing and unstable (but should be installable/functional on stable).
- Edit /etc/apt/sourced.list
- Add "contrib" to "deb http://deb.debian.org/debian unstable main contrib"
- apt-get update
- apt-get install gitea
For other distributions, see the [deployment from binary]({{< relref "from-binary.en-us.md" >}}) guide.
## Windows
We have not published any package for Windows yet, we will update this page directly when we start to publish packages in the form of `MSI` installers or via [Chocolatey](https://chocolatey.org/), in the meantime you should follow our [installation from binary]({{< relref "from-binary.en-us.md" >}}) guide.
There are no published packages for Windows. This page will change when packages are published,
in the form of `MSI` installers or via [Chocolatey](https://chocolatey.org/). In the meantime
the [deployment from binary]({{< relref "from-binary.en-us.md" >}}) guide.
## macOS
Currently we only support the installation via `brew` for macOS. If you are not using [Homebrew](http://brew.sh/) you should follow our [installation from binary]({{< relref "from-binary.en-us.md" >}}) guide. To install Gitea via `brew` you just need to execute the following commands:
Currently, the only supported method of installation on MacOS is [Homebrew](http://brew.sh/).
Following the [deployment from binary]({{< relref "from-binary.en-us.md" >}}) guide may work,
but is not supported. To install Gitea via `brew`:
```
brew tap go-gitea/gitea
@ -34,13 +47,14 @@ brew install gitea
## FreeBSD
A FreeBSD port `www/gitea` is available. You can install a pre-built binary package:
A FreeBSD port `www/gitea` is available. To install the pre-built binary package:
```
pkg install gitea
```
For the most up to date version, or to build the port with custom options, [install it from the port](https://www.freebsd.org/doc/handbook/ports-using.html):
For the most up to date version, or to build the port with custom options,
[install it from the port](https://www.freebsd.org/doc/handbook/ports-using.html):
```
su -
@ -48,10 +62,8 @@ cd /usr/ports/www/gitea
make install clean
```
The port uses the standard FreeBSD file system layout: config files are in `/usr/local/etc/gitea`, bundled templates, options, plugins and themes are in `/usr/local/share/gitea`, and a start script is in `/usr/local/etc/rc.d/gitea`.
To enable Gitea to run as a service, run `sysrc gitea_enable=YES` and start it with `service gitea start`.
## Anything missing?
The port uses the standard FreeBSD file system layout: config files are in `/usr/local/etc/gitea`,
bundled templates, options, plugins and themes are in `/usr/local/share/gitea`, and a start script
is in `/usr/local/etc/rc.d/gitea`.
Are we missing anything on this page? Then feel free to reach out to us on our [Discord server](https://discord.gg/NsatcWJ), there you will get answers to any question pretty fast.
To enable Gitea to run as a service, run `sysrc gitea_enable=YES` and start it with `service gitea start`.
We won't cover the basics of a Golang setup within this guide. If you don't know how to get the environment up and running you should follow the official [install instructions](https://golang.org/doc/install).
This section will not include basic [installation instructions](https://golang.org/doc/install).
**Note**: Go version 1.7 or higher is required
## Download
First of all you have to retrieve the source code, the easiest way is to simply use directly Go for that. Just call the following commands to fetch the source and to switch into the working directory.
First retrieve the source code. The easiest way is to use the Go tool. Use the following
commands to fetch the source and switch into the source directory.
```
go get -d -u code.gitea.io/gitea
cd $GOPATH/src/code.gitea.io/gitea
```
Now it's time to decide which version of Gitea you want to build and install. Currently there are multiple options you can choose from. If you want to build our `master` branch you can directly go ahead to the [build section](#build), this branch represents our current development version and this is not intended for production use.
If you want to build the latest stable version that acts as a development branch for the tagged releases you can see the available branches and how to checkout this branch with these commands:
Decide which version of Gitea to build and install. Currently, there are multiple options
to choose from. The `master` branch represents the current development version. To build
with master, skip to the [build section](#build).
To work with tagged releases, the following commands can be used:
```
git branch -a
git checkout v1.0
```
If you would validate a Pull Request, first your must enable this new branch : (`xyz` is the PR id, for example `2663` for [#2663](https://github.com/go-gitea/gitea/pull/2663))
To validate a Pull Request, first enable the new branch (`xyz` is the PR id; for example
`2663` for [#2663](https://github.com/go-gitea/gitea/pull/2663)):
```
git fetch origin pull/xyz/head:pr-xyz
```
Last but not least you can also directly build our tagged versions like `v1.0.0`, if you want to build Gitea from the source this is the suggested way for that. To use the tags you need to list the available tags and checkout a specific tag with the following commands:
To build Gitea from source at a specific tagged release (like v1.0.0), list the available
tags and check out the specific tag.
List available tags with the following.
```
git tag -l
git checkout v1.0.0
git checkout pr-xyz
git checkout v1.0.0 # or git checkout pr-xyz
```
## Build
Since we already bundle all required libraries to build Gitea you can continue with the build process itself. We provide various [make tasks](https://github.com/go-gitea/gitea/blob/master/Makefile) to keep the build process as simple as possible. <ahref='{{< relref "doc/advanced/make.en-us.md" >}}'>See here how to get Make</a>. Depending on your requirements you possibly want to add various build tags, you can choose between these tags:
Since all required libraries are already bundled in the Gitea source, it's
possible to build Gitea with no additional downloads. Various
[make tasks](https://github.com/go-gitea/gitea/blob/master/Makefile) are
provided to keep the build process as simple as possible.
<ahref='{{< relref "doc/advanced/make.en-us.md" >}}'>See here how to get Make</a>.
Depending on requirements, the following build tags can be included.
* `bindata`: With this tag you can embed all assets required to run an instance of Gitea, this makes a deployment quite easy because you don't need to care about any additional file.
* `sqlite`: With this tag you can enable support for a [SQLite3](https://sqlite.org/) database, this is only suggested for tiny Gitea installations.
* `tidb`: With this tag you can enable support for a [TiDB](https://github.com/pingcap/tidb) database, it's a quite simple file-based database comparable with SQLite.
* `pam`: With this tag you can enable support for PAM (Linux Pluggable Authentication Modules), this is useful if your users should be authenticated via your available system users.
* `bindata`: Build a single monolithic binary, with all assets included.
* `sqlite`: Enable support for a [SQLite3](https://sqlite.org/) database. Suggested only
for tiny installations.
* `tidb`: Enable support for a [TiDB](https://github.com/pingcap/tidb) database.
* `pam`: Enable support for PAM (Linux Pluggable Authentication Modules). Can be used to
authenticate local users or extend authentication to methods available to PAM.
Now it's time to build the binary, we suggest to embed the assets with the `bindata` build tag, to include the assets you also have to execute the `generate` make task, otherwise the assets are not prepared to get embedded:
Bundling assets into the binary using the `bindata` build tag can make development and
testing easier, but is not ideal for a production deployment. To include assets, they
must be built separately using the `generate` make task.
```
TAGS="bindata" make generate build
@ -68,12 +82,10 @@ TAGS="bindata" make generate build
## Test
After following the steps above you will have a `gitea` binary within your working directory, first you can test it if it works like expected and afterwards you can copy it to the destination where you want to store it. When you launch Gitea manually from your CLI you can always kill it by hitting `Ctrl + C`.
After following the steps above a `gitea` binary will be available in the working directory.
It can be tested from this directory or moved to a directory with test data. When Gitea is
launched manually from command line, it can be killed by pressing `Ctrl + C`.
```
./gitea web
```
## Anything missing?
Are we missing anything on this page? Then feel free to reach out to us on our [Discord server](https://discord.gg/NsatcWJ), there you will get answers to any question pretty fast.
Add code to the file from [here](https://github.com/go-gitea/gitea/blob/master/contrib/systemd/gitea.service).
Copy the sample [gitea.service](https://github.com/go-gitea/gitea/blob/master/contrib/systemd/gitea.service).
Uncomment any service need to be enabled like mysql in this case in Unit section.
Uncomment any service that needs to be enabled on this host, such as MySQL.
Change the user(git) accordingly to yours. And /home/git too if your username is different than git. Change the PORT or remove the -p flag if default port is used.
Change the user, home directory, and other required startup values. Change the
PORT or remove the -p flag if default port is used.
Lastly start and enable gitea at boot:
Enable and start gitea at boot:
```
sudo systemctl enable gitea
sudo systemctl start gitea
```
```
sudo systemctl enable gitea
```
#### Using supervisor
#### Using supervisor
Install supervisor by running below command in terminal:
Install supervisor by running below command in terminal:
```
sudo apt install supervisor
```
```
Create a log dir for the supervisor logs(assuming gitea is installed in /home/git/gitea/):
Create a log dir for the supervisor logs:
```
# assuming gitea is installed in /home/git/gitea/
mkdir /home/git/gitea/log/supervisor
```
```
Open supervisor config file in vi/vim/nano etc.
Open supervisor config file in a file editor:
```
sudo vim /etc/supervisor/supervisord.conf
```
```
And append the code at the end of the file from [here](https://github.com/go-gitea/gitea/blob/master/contrib/supervisor/gitea).
Change the user(git) accordingly to yours. And /home/git too if your username is different than git. Change the PORT or remove the -p flag if default port is used.
Change the user(git) and home(/home/git) settings to match the deployment
environment. Change the PORT or remove the -p flag if default port is used.
To register Gitea as a Windows service, first run `cmd` as an Administrator, and then run the following command:
To register Gitea as a Windows service, open a command prompt (cmd) as an Administrator,
then run the following command:
```
sc create gitea start= auto binPath= ""C:\gitea\gitea.exe" web --config "C:\gitea\custom\conf\app.ini""
```
Do not forget to replace `C:\gitea` with your real Gitea folder.
Do not forget to replace `C:\gitea` with the correct Gitea directory.
After, open "Windows Services", search for the service named "gitea", right-click it and click on "Run". If everything is OK you should be able to reach Gitea on `http://localhost:3000` (or the port is was configured, if different than 3000).
Open "Windows Services", search for the service named "gitea", right-click it and click on
"Run". If everything is OK Gitea will be reachable on `http://localhost:3000` (or the port
that was configured).
## Unregister as a service
To unregister Gitea as a service, open `cmd` as an Administrator and run:
To unregister Gitea as a service, open a command prompt (cmd) as an Administrator and run:
We provide automatically updated Docker images within our Docker Hub organization. It is up to you and your deployment to always use the latest stable tag or to use another service that updates the Docker image for you.
Gitea provides automatically updated Docker images within its Docker Hub organization. It is
possible to always use the latest stable tag or to use another service that handles updating
Docker images.
This reference setup guides you through the setup based on `docker-compose`, the installation of `docker-compose` is out of scope of this documentation. To install `docker-compose` follow the official [install instructions](https://docs.docker.com/compose/install/).
This reference setup guides users through the setup based on `docker-compose`, the installation
of `docker-compose` is out of scope of this documentation. To install `docker-compose` follow
the official [install instructions](https://docs.docker.com/compose/install/).
## Basics
The most simple setup just creates a volume and a network and starts the `gitea/gitea:latest` image as a service. Since there is no database available you can start it only with SQLite3. Create a directory like `gitea` and paste the following content into a file named `docker-compose.yml`.
The most simple setup just creates a volume and a network and starts the `gitea/gitea:latest`
image as a service. Since there is no database available one can be initialized using SQLite3.
Create a directory like `gitea` and paste the following content into a file named `docker-compose.yml`.
```yaml
version: "2"
@ -45,7 +51,9 @@ services:
## Custom port
To bind the integrated openSSH daemon and the webserver on a different port, you just need to adjust the port section. It's common to just change the host port and keep the ports within the container like they are.
To bind the integrated openSSH daemon and the webserver on a different port, adjust
the port section. It's common to just change the host port and keep the ports within
the container like they are.
```diff
version: "2"
@ -71,7 +79,8 @@ services:
## MySQL database
To start Gitea in combination with a MySQL database you should apply these changes to the `docker-compose.yml` file created above.
To start Gitea in combination with a MySQL database, apply these changes to the
`docker-compose.yml` file created above.
```diff
version: "2"
@ -110,7 +119,8 @@ services:
## PostgreSQL database
To start Gitea in combination with a PostgreSQL database you should apply these changes to the `docker-compose.yml` file created above.
To start Gitea in combination with a PostgreSQL database, apply these changes to
the `docker-compose.yml` file created above.
```diff
version: "2"
@ -148,7 +158,9 @@ services:
## Named volumes
To use named volumes instead of host volumes you just have to define and use the named volume within the `docker-compose.yml` configuration. This change will automatically create the required volume.
To use named volumes instead of host volumes, define and use the named volume
within the `docker-compose.yml` configuration. This change will automatically
create the required volume.
```diff
version: "2"
@ -175,24 +187,31 @@ services:
- "222:22"
```
If you are using MySQL or PostgreSQL it's up to you to create named volumes for these containers as well.
MySQL or PostgreSQL containers will need to be created separately.
## Start
To start this setup based on `docker-compose` you just have to execute `docker-compose up -d` to launch Gitea in the background. You can see if it started properly via `docker-compose ps`, and you can tail the log output via `docker-compose logs`.
To start this setup based on `docker-compose`, execute `docker-compose up -d`,
to launch Gitea in the background. Using `docker-compose ps` will show if Gitea
started properly. Logs can be viewed with `docker-compose logs`.
If you want to shutdown the setup again just execute `docker-compose down`, this will stop and kill the containers, the volumes will still exist.
To shut down the setup, execute `docker-compose down`. This will stop
and kill the containers. The volumes will still exist.
Notice: if you use a non 3000 port on http, you need change app.ini `LOCAL_ROOT_URL = http://localhost:3000/`.
Notice: if using a non-3000 port on http, change app.ini to match
`LOCAL_ROOT_URL = http://localhost:3000/`.
## Install
After starting the Docker setup via `docker-compose` you should access Gitea with your favorite browser to finalize the installation. Please visit http://server-ip:3000 and follow the installation wizard. If you have started a database with the `docker-compose` setup as documented above please note that you have to use `db` as the database hostname.
After starting the Docker setup via `docker-compose` Gitea should be available using a
favorite browser to finalize the installation. Visit http://server-ip:3000 and follow the
installation wizard. If the database was started with the `docker-compose` setup as
documented above please note that `db` must be used as the database hostname.
# Customization
Customization files described [here](https://docs.gitea.io/en-us/customizing-gitea/) should be placed in `/data/gitea` directory. If you are using host volumes it's quite easy to access these files, for named volumes you have to do it through another container or you should directly access `/var/lib/docker/volumes/gitea_gitea/_data`. The configuration file will be saved at `/data/gitea/conf/app.ini` after the installation.
# Anything missing?
Are we missing anything on this page? Then feel free to reach out to us on our [Discord server](https://discord.gg/NsatcWJ), there you will get answers to any question pretty fast.
Customization files described [here](https://docs.gitea.io/en-us/customizing-gitea/) should
be placed in `/data/gitea` directory. If using host volumes it's quite easy to access these
files; for named volumes this is done through another container or by direct access at
`/var/lib/docker/volumes/gitea_gitea/_data`. The configuration file will be saved at
`/data/gitea/conf/app.ini` after the installation.
Gogs versions up to 0.9.146 (db schema version 15) can be smoothly upgraded to Gitea.
Gogs, version 0.9.146 and older, can be easily migrated to Gitea.
There are some steps to do so below. On Unix run as your Gogs user:
There are some basic steps to follow. On a Linux system run as the Gogs user:
* Create a Gogs backup with `gogs dump`. This creates `gogs-dump-[timestamp].zip` file containing all your Gogs data.
* Download the file matching your platform from the [downloads page](https://dl.gitea.io/gitea).
* Create a Gogs backup with `gogs dump`. This creates `gogs-dump-[timestamp].zip` file
containing all important Gogs data.
* Download the file matching the destination platform from the [downloads page](https://dl.gitea.io/gitea).
* Put the binary at the desired install location.
* Copy `gogs/custom/conf/app.ini` to `gitea/custom/conf/app.ini`.
* If you have custom `templates, public` in `gogs/custom/` copy them to `gitea/custom/`.
* If you have any other custom folders like `gitignore, label, license, locale, readme` in `gogs/custom/conf` copy them to `gitea/custom/options`.
* Copy custom `templates, public` from `gogs/custom/` to `gitea/custom/`.
* For any other custom folders, such as `gitignore, label, license, locale, readme` in
`gogs/custom/conf`, copy them to `gitea/custom/options`.
* Copy `gogs/data/` to `gitea/data/`. It contains issue attachments and avatars.
* Verify by starting Gitea with `gitea web`.
* Enter Gitea admin panel on the UI, run `Rewrite '.ssh/authorized_keys' file`, then run `Rewrite all update hook of repositories` (needed when custom config path is changed).
* Enter Gitea admin panel on the UI, run `Rewrite '.ssh/authorized_keys' file`.
* If custom or config path was changed, run `Rewrite all update hook of repositories`.
### Change gogs specific information:
* Rename `gogs-repositories/` to `gitea-repositories/`
* If you encounter errors relating to custom templates in the `gitea/custom/templates` folder, try moving the templates causing the errors away one by one. They may not be compatible with Gitea.
* If errors are encountered relating to custom templates in the `gitea/custom/templates`
folder, try moving the templates causing the errors away one by one. They may not be
compatible with Gitea or an update.
### Add Gitea to startup on Unix
Update the appropriate file from [gitea/contrib](https://github.com/go-gitea/gitea/tree/master/contrib) with the right environment variables.
Update the appropriate file from [gitea/contrib](https://github.com/go-gitea/gitea/tree/master/contrib)
with the right environment variables.
For distro's with systemd:
For distros with systemd:
* Copy the updated script to `/etc/systemd/system/gitea.service`
* Add the service to the startup with: `sudo systemctl enable gitea`
* Disable old gogs startup script: `sudo systemctl disable gogs`
For distro's with SysVinit:
For distros with SysVinit:
* Copy the updated script to `/etc/init.d/gitea`
* Add the service to the startup with: `sudo rc-update add gitea`
Gitea currently has a `dump` command that will save your installation to a zip file. There will be a `restore` command implemented at some point in the future. You will be able to use this to back up your installation, as well as make migrating servers easier.
Gitea currently has a `dump` command that will save the installation to a zip file. This
file can be unpacked and used to restore an instance.
## Backup Command (`dump`)
First, switch to the user running gitea: `su git` (or whatever user you are using). Run `./gitea dump` in the gitea installation directory. You should see some output similar to this:
Switch to the user running gitea: `su git`. Run `./gitea dump` in the gitea installation
directory. There should be some output similar to the following:
```
2016/12/27 22:32:09 Creating tmp work dir: /tmp/gitea-dump-417443001
@ -30,17 +32,31 @@ First, switch to the user running gitea: `su git` (or whatever user you are usin
2016/12/27 22:32:34 Finish dumping in file gitea-dump-1482906742.zip
```
Inside the `gitea-dump-1482906742.zip` file, you will find the following:
Inside the `gitea-dump-1482906742.zip` file, will be the following:
* `custom/conf/app.ini` - This is your server config.
* `gitea-db.sql` - SQL dump of your database.
* `gitea-repo.zip` - This zip will be a complete copy of your repo folder.
See Config -> repository -> `ROOT` for the location.
* `log/` - this will contain various logs. You don't need these if you are doing
a migration.
* `custom/conf/app.ini` - Server config.
* `gitea-db.sql` - SQL dump of database
* `gitea-repo.zip` - Complete copy of the repository directory.
* `log/` - Various logs. They are not needed for a recovery or migration.
Intermediate backup files are created in a temporary directory specified either with the `--tempdir` command-line parameter or the `TMPDIR` environment variable.
Intermediate backup files are created in a temporary directory specified either with the
`--tempdir` command-line parameter or the `TMPDIR` environment variable.
## Restore Command (`restore`)
WIP: Does not exist yet.
There is currently no support for a recovery command. It is a manual process that mostly
involves moving files to their correct locations and restoring a database dump.
- `gitea web --config /etc/gitea.ini --pid /var/run/gitea.pid`
- Notes:
- Gitea should not be run as root. To bind to a port below 1000, you can use setcap on Linux: `sudo setcap 'cap_net_bind_service=+ep' /path/to/gitea`. This will need to be redone every time you update Gitea.
- Gitea should not be run as root. To bind to a port below 1000, you can use setcap on
Linux: `sudo setcap 'cap_net_bind_service=+ep' /path/to/gitea`. This will need to be
Gitea is a painless self-hosted Git service. It is similar to GitHub, Bitbucket or Gitlab. The initial development have been done on [Gogs](http://gogs.io) but we have forked it and named it Gitea. If you want to read more about the reasons why we have done that please read [this](https://blog.gitea.io/2016/12/welcome-to-gitea/) blog post.
Gitea is a painless self-hosted Git service. It is similar to GitHub, Bitbucket, and Gitlab.
Gitea is a fork of [Gogs](http://gogs.io). See the [Gitea Announcement](https://blog.gitea.io/2016/12/welcome-to-gitea/)
blog post to read about the justification for a fork.
## Purpose
The goal of this project is to make the easiest, fastest, and most painless way of setting up a self-hosted Git service. With Go, this can be done with an independent binary distribution across ALL platforms that Go supports, including Linux, macOS and Windows, even on architectures like ARM or PowerPC.
The goal of this project is to provide the easiest, fastest, and most painless way of setting
up a self-hosted Git service. With Go, this can be done with an independent binary distribution
across all platforms and architectures that Go supports. This support includes Linux, macOS, and
Windows, on architectures like amd64, i386, ARM, PowerPC, and others.
## Features
@ -25,7 +30,7 @@ The goal of this project is to make the easiest, fastest, and most painless way
- Pull requests
- Repository creation
- Searchable repository list
- List of your organizations
- List of organizations
- A list of mirror repositories
- Issues dashboard
- Context switcher (organization or current user)
@ -67,9 +72,9 @@ The goal of this project is to make the easiest, fastest, and most painless way
@ -245,14 +250,14 @@ The goal of this project is to make the easiest, fastest, and most painless way
## System Requirements
- A cheap Raspberry Pi is powerful enough for basic functionality.
- 2 CPU cores and 1GB RAM would be the baseline for teamwork.
- Gitea is supposed to be run with a dedicated non-root user account on UNIX systems, no other mode of operation is supported. (**NOTE**: in case you run it with your own user account and the built-in SSH server disabled, Gitea modifies the `~/.ssh/authorized_keys` file so you will **not** be able to interactively log in.)
- A Raspberry Pi 3 is powerful enough to run Gitea for small workloads.
- 2 CPU cores and 1GB RAM is typically sufficient for small teams/projects.
- Gitea should be run with a dedicated non-root system account on UNIX-type systems.
- Note: Gitea manages the `~/.ssh/authorized_keys` file. Running gitea as a regular user could break that user's ability to log in.
## Browser Support
- Please see [Semantic UI](https://github.com/Semantic-Org/Semantic-UI#browser-support) for specific versions of supported browsers.
- The official support minimal size is **1024*768**, UI may still looks right in smaller size but no promises and fixes.
Michael Lustfield
6 years ago
committed by
Kim "BKC" Carlbäcker